Using FtpWebRequest in Powershell to access Filezilla server with certificate - powershell

I am trying to access a Filezilla Server using FtpWebRequest in Powershell, like this:
$ftprequest = [System.Net.FtpWebRequest]::Create($sourceuri)
$ftprequest.Method = ([System.Net.WebRequestMethods+Ftp]::ListDirectoryDetails + " -a")
$ftprequest.Credentials = New-Object System.Net.NetworkCredential($username,$password)
$ftprequest.EnableSsl = $true
In Filezilla Server there is a "Generate New Certificate" which is what I used to create the certificate. This created a .crt file that Filezilla is pointing to for both the private key and certificate file.
The server is also configured with the options "Enable FTPS" and "Allow explicit FTP over TLS".
I am able to happily access the server using the Filezilla Client (although it warns that the server's certificate is unknown).
To access the server from a Powershell client, without getting complaints about the certificate, my understanding is the best thing to do is import the certificate on the client machine. I managed to do this by downloading the .crt file, manually stripping out the private key portion using Notepad, and then running:
Import-Certificate -FilePath .\filezillaCertificate.crt -CertStoreLocation cert:\CurrentUser\My
However, trying to connect using FtpWebRequest I still receive the error "The remote certificate is invalid according to the validation procedure."
Can anyone point me in the right direction?

This is not a PoSH issue. It is a pure PKI 101 (cert implementation) issue.
Self-signed certificates will always be considered untrusted in most cases, because there is no way to validate it, no public registered body for it and no public CRL (Certificate Revocation List / Authority) associated with it.
You cannot create a PKI cert for a remote location on your local machine. You must create the cert on the remote location, or buy a public cert and install it on the remote location certificate store. The public and private key must reside on the remote server / site. For any server / site, the certificate must be registered / issued to that server then manually assigned to a site (FTP/s, HTTP/s).
Then, you download the public cert from the destination and install that on your local machine. Normally installed to the local machine store. If you cannot download that public certificate and certificate chain using a browser, by clicking on the lock, after visiting the site, then you must request that the destination server/site owner send you the public cert for you to install locally. Again, normally installed to the local machine store.
I know your post is about a Filezilla server (Full Disclosure: I've never seen on used one), but the approach as shown in the articles below on setting up FTP over SSL on IIS should be similar.
FTP over SSL
The element specifies the FTP over Secure Sockets Layer (SSL)
settings for the FTP service; FTP over SSL was first introduced for
IIS 7 in FTP 7.0.
Unlike using HTTP over SSL, which requires a separate port and
connection for secure (HTTPS) communication, secure FTP communication
occurs on the same port as non-secure communication. FTP 7 supports
two different forms of FTP over SSL:
https://learn.microsoft.com/en-us/iis/configuration/system.applicationhost/sites/site/ftpserver/security/ssl
https://learn.microsoft.com/en-us/iis/publish/using-the-ftp-service/using-ftp-over-ssl-in-iis-7
Update to find the FileZilla SSL guidance
Install a SSL certificate on FileZilla FTP Server
https://www.tbs-certificates.co.uk/FAQ/en/FileZilla_FTP_Server.html
Installing a certificate on an OpenSSL-based server is really similar
than doing so on Apache: Install an Apache certificate, except that
the instructions indicating the path to th files are not the same!
for FTP FileZilla server, via the interface: FileZilla Server
Option -> SSL/TLS settings:
•import the private key (.key file generated along with the CSR) in
"Private key file".
•import the certificate and the certification chain in the same file:
1) on your certificate status page, download the "file.cer" file and
the certification chain "chain-xxx.txt" 2) concatenate those two
files into one 3) import the file in "Certificate file"
How to connect FTP over SSL/TLS in FileZilla?
Create Site
Go to File >> Site Manager >> New Site.
Following are the required details to fill up.
• Host: Enter Hostname(i.e. ftp.yourdomain.com) or IP address which we
have sent in Welcome e-mail. • Port: 21 (Default FTP port is 21, you
can also keep it blank). • Protocol: FTP - File Transfer Protocol. •
Encryption: Select Required explicit FTP over TLS from dropdown list.
• Logon Type: Select Normal from the dropdown list. • User: Your FTP
username. • Password: Your FTP Password.
https://manage.accuwebhosting.com/knowledgebase/761/How-to-connect-FTP-over-SSLorTLS-in-FileZilla.html
The FileZilla wiki also talks to how to do the SSL implementation.

Related

How to Set SSL to a localhost server which is supported by all the browsers?

I have a windows desktop application which need to be communicated with our web page.So I've created a local server which runs on a port.I'm creating a socket from my webpage to the desktop application and the communication happens though that socket.
As my webpage runs on HTTPS, I need to create a secure socket ('wss'). SO I generated a self signed certificate for Ip 127.0.0.1 using openssl and I imported the certificate to windows trusted cerificate store.Now google chrome accepts it as a trusted certificate but the firefox rejects that certificate with the error Error code: SEC_ERROR_UNKNOWN_ISSUER .
We cant buy a SSL certificate for localhost domain from a CA. Is there any solution to overcome this problem? Is there any way to skip SSL check for socket creation?
How can I create a certificate which will be accepted by all the browsers as a trusted certificate?
Firefox can use the desktop store by setting this key to TRUE : security.enterprise_roots.enabled
To change this, open about:config with your Firefox and look for this key.
If you want to change this automatically for several desktops, have a look at this tutorial which is well done.
The other answer from Eugène Adell is good, but if you are on Linux, a policy file is required to trust the OS certificate authority.
Create a file "policies.json" in the "distribution" directory of the Firefox install location, and point it to the certificate file:
{
"policies": {
"Certificates": {
"ImportEnterpriseRoots": true,
"Install": ["localhost.crt","/path/to/cert/file"]
}
}
}
https://support.mozilla.org/en-US/kb/setting-certificate-authorities-firefox
https://github.com/mozilla/policy-templates/blob/master/README.md#certificates--install
This Q&A on a similar question may have some more information:
https://stackoverflow.com/a/74802552/2657515

Npgsql 3.0.3 error with Power BI Desktop

I'm receiving the following error when connecting to an AWS Postgres database that requires SSL. I recently upgraded from npgsql 2.3.2 (which was buggy) to 3.0.3 which won't connect. Any suggestions would be appreciated.
DataSource.Error: TlsClientStream.ClientAlertException:
CertificateUnknown: Server certificate was not accepted. Chain status:
A certificate chain could not be built to a trusted root authority. .
at TlsClientStream.TlsClientStream.ParseCertificateMessage(Byte[] buf,
Int32& pos) at
TlsClientStream.TlsClientStream.TraverseHandshakeMessages() at
TlsClientStream.TlsClientStream.GetInitialHandshakeMessages(Boolean
allowApplicationData) at
TlsClientStream.TlsClientStream.PerformInitialHandshake(String
hostName, X509CertificateCollection clientCertificates,
RemoteCertificateValidationCallback
remoteCertificateValidationCallback, Boolean
checkCertificateRevocation) Details:
DataSourceKind=PostgreSQL
I was able to fix the issue by installing the Amazon RDS public certificate on my machine. Once I did this, I was able to connect.
Steps I followed:
Download the AWS RDS public certificate 1
Create a .crt file from the .pem file downloaded. Sample instructions
here 2
Install the certificate (.crt file) on the machine. 3
Connect!
The docs from npgsql give the solution as changing the default trust server certificate of 'false' to 'true' in the connection string.
Unfortunately, neither Excel (AFAIK) nor Power BI will allow you to edit the connection string. So if you are unable to get the SSL certificate from the DB admin (as suggested in another answer), or the SSL cert has a different server name to the name you connect to (in my case an IP address), there is not much that can be done.
I can see two ways of fixing this. Either Shay & co from npgsql (who are doing an excellent job btw) provide some way for users to change the default settings for the connection string parameters. Or Microsoft allows users to send keywords in the connection dialog of Power BI (and Excel).
Npgsql 2.x didn’t perform validation on the server’s certificate by default, so self-signed certificate were accepted. The new default is to perform validation, which is probably why your connection is failing. Specify the Trust Server Certificate connection string parameter to get back previous behavior.
You can read more on the Npgsql security doc page, note also that this change is mentioned in our migration notes.
I had the same issue connecting PowerBI to a locally hosted PostgreSQL server and it turned out to be easy to solve if you can get the right information. Recent Npgsql versions will only connect over SSL if it trusts the certificate of the server. As a Windows application PowerBI uses the windows certificate store to decide what to trust. If you can get the SSL cert for the PostgreSQL server (or the CA cert used to sign that one) then tell Windows to trust that certificate, PowerBI will trust it too.
In the configuration folder for the PostgreSQL server there is a postgresql.conf file, search it for ssl settings, there is one with the location of the ssl cert. Note NOT the key file which contains the private key, only the cert file which contains the public key. copy it or its content to the machine running PowerBI and import using Run | mmc | Add Plugin... Certificates (Google it)
Look at the server name once you imported the cert and connect from PowerBI using the same server name (so the cert matches the connection). That solved the problem for me. If PostgreSQL is configured to insist on a SSL connection you might have to do the same for a ODBC connection too.
Its not best way but worked for me since if u dont need encryption for security reason.
Go to Postgres config file on your DB server and go from
ssl = true
to
ssl = false
Then open your power bi desktop File-> Options and settings -> Data source settings -> then in global you will have saved your connection press Edit Permissions and uncheck "ENCRYPT CONNECTIONS"
Then it will work
WARNING: THIS IS NOT RECOMMENDED IF YOUR DB IS OPEN TO PUBLIC.
Regards,
Davlik

Trusted Root Certificate Automatically disappear on client SSL connection

I have this weirdest problem. First off: I'm VERY new to this certificate thingy. I've done a fair amount of searches and reading up though.
The CA Cert that I install into the Trusted Root Certificate
Authorities store in my server automatically get removed/disappeared
as soon as a client web-browser try to connect to a web-site using an
SSL cert created with that CA cert.
DETAILS:
Windows Server 2008 R2 (development server).
I've created my own Certificate Authority Cert; which I use it to generate an SSL server cert (to install on my IIS 7 Server) and a client cert (for use at my local PC to connect to the WCF Webservice on the development server which is set to Require SSL and Require Client Cert).
I installed the CA Cert into the Trusted Root on both Server and local PC.
Installed the SSL server cert into the IIS7 for that particular site and did the https binding to port 443.
As soon as I launch my browser to access that site with HTTPS, the CA
cert in automatically removed on the server (from the Trusted Root
Certificate Authorities store). and my local PC browser will report
an error 403.
This is driving me nuts... anyone knows what is happening?
Apparently, after a lot of running around, it is due to too many of the same certs in many stores.
I open the MMC.exe > Add/Remove SnapIns > Certificates
Notice there are 3 types there (My User Account, Service Account & Computer Account).
Open up My User and Computer Account, go through all the stores for each one and DELETE all of the CA cert with the same name. Then add the CA cert in either My User Account or Computer Account, depending on how you access the certs (in the event of the cert being used programatically, install it in the Computer Account, [Trusted Root Certificate Authorities].
Just 1 place, then the problem will dissappear.

REST Service - SSL Implementation (HTTP Error 403.7 - Forbidden)

In order to secure my Rest Services, I have enabled SSL in IIS and Created a Self-Signed Certificate and assigned it to the HTTPS binding in IIS. I exported the same as pfx file and added the same in IE also but when I try to access the Services, I get the following error on Windows 7, Enterprise edition
HTTP Error 403.7 - Forbidden
The page you are attempting to access requires your browser to have a Secure Sockets Layer (SSL) client certificate that the Web server recognizes.
And on Windows Server 2003, this is
HTTP Error 403.7 - Forbidden: SSL client certificate is required.
Internet Information Services (IIS)
I am not sure what shall I do except adding the certificate in IE under “Personal” and “Trusted Root Certification Authorities”? Could you please suggest me some step, in order to make this work.
Note: I have tried with “Self-Signed Certificates” as well as with Certificates generated from Microsoft “Certificate Services” also.
Any help is greatly appreciated.
SSL is used to verify the identity of the server, not the identity of the client. The error suggests (http://support.microsoft.com/kb/199215, "This is used for authenticating you as a valid user of the resource. ") the server wants to identify the client. Which of the two are you trying to do?
Edit: SSL requires the public part of the SSL certificate to be available to the client. Adding it to the trusted root certificates seems to me to be the only way to make the public part of a self-signed certificate available to the browser.

SSL connect to mail server. Trusted ssl certificate rejected by mail client

I've godaddy's 2048bit certificate for domain and 4 subdomains.
[www.site.com, mail.site.com, e.t.c.]
Standard Multiple Domain (UCC) SSL Up to 5 Domains - 1 year (annual)
That certificate works fine in Apache, ssl web checker says OK and browser shows green line in address string.
I've added this certificate to mail daemon, it has been accepted by Exim too.
When some client tries to send mail with SSL/TLS connection through mail server, mail program says "Certificate is BAD" though shows correct trusted info.
Client connects to hostname: mail.server.com, server's hostname is: ns1.server.com (not added to certificate), mail server says: 220 ns1.site.com ESMTP Exim 4.73
Mail clients tested: iPAD mail client, Mozilla Thunderbird, Mac mail client
Please help.
UPDATE:
Godaddy's ssl checker says: SSL Chain of Trust is Broken!
Here are a couple of things to check:
Is the hostname that the mail client uses in the TCP connect, listed in the server certificate as the Common Name (CN) of the subject distinguished name?
If not, is it listed using type "DNS:" in the Subject Alternative Name X509 v3 certificate extension?
If neither of the above, you might be getting "Remote Certificate Name Mismatch" (or similarly named error.)
If it is listed, then look for the Issuer of the certificate, and Issuer of the Issuer, etc., all the way to the root certificate of the chain. The root certificate should be installed on the client machine, in the "Trusted Root" certificate store for whatever client you are using (Windows, Mozilla, Java keystore, etc.)
If the root certificate is installed, then look at the intermediate certificates, if there are any in the chain (between root and server certificates). They have to either be installed locally, or arrive from the server alongside the server certificate -- either the server sends them each time or you've got the intermediate certificates already installed on the client end. Either way, they have got to be in hand to accept the server certificate.
Do the clients which reject the certificate have the appropriate root certificates in their cert store?