X509 Cert Config

Question

I have been trying to configure EDT FTP server to test an evaluation copy of FTPnet for use with FTPS as a recommendation to a committee for a library to standardize on. At this point. I understand the FTP Server is Beta and EDTs support of the Beta is very limited. I'm hoping someone can enlighten me.

I discovered that the FTP server doesn't install/run under a Domain account (at least through the UI wrapper). I have even looked at creating Domain Accounts using the "mkpasswd -d >> psswd" which failed with RPC server unavailable. My main concern is getting the FTP server up and running with FTPS.

I have a Win2K CA that I have the CA Root Authority Cert (AcmeCACert.cer), a generated Cert containing both Public/Private keys (AcmeFTPCert.cer) and an export of this Cert containing only the Public Key (AcmeFTPPublicCert.cer).

I have a simple .NET v2005 app which sets the parameters below. I keep getting the error message "The server hello message uses a protocol that was not recognized." At this point I have manually modified the default.conf file to point to my certs as shown below.

I looked at the OpenSSL certs provided compared to my certs and the formats look slightly different. the OpenSSLs have a special Newline character after every section but all sections are placed together on one line. Is this a problem for the FTP Server?

Also I looked at my Public/Private Cert compared with my Public Cert and they both appear to have the same exact data in them (which is odd to me as I exported only the public part of the Cert). I've even tried to export a *.pfx which is completely different format all together (i.e. not the Base64 of the *.cer files).

Any ideas?

TLSEngine on
TLSLog /edtFTPD/var/log/tls.log
TLSProtocol TLSv1
TLSRequired on
TLSRSACertificateFile /edtFTPD/etc/AcmeFTPPublicCert.cer
TLSRSACertificateKeyFile /edtFTPD/etc/AcmeFTPCert.cer
TLSCACertificateFile /edtFTPD/etc/AcmeCACert.cer
TLSVerifyClient off

// setting server address and credentials
ftpConnection.ServerAddress = "192.168.1.10";
ftpConnection.ServerPort = 21;
ftpConnection.UserName = "AcmeTest";
ftpConnection.Password = "Secret";

// select explicit FTPS
ftpConnection.Protocol = FileTransferProtocol.FTPSExplicit;
ftpConnection.Connect();

Answer 1

* What functionality needs to be included in the Server's Certificate (i.e. ability to encrypt, sign, support for SSL, etc.. I'm guessing we need to use the Certificate Template 1.3.6.1.5.5.7.3.1 per the HowTo's but thats if we are using Self Signed Certs as opposed to requesting a Cert from our local CA)?

We regularly use OpenSSL-generated certificates with no special functionality, so I believe that none is required. How are you generating your certificates?

* What certificate store does the Server's Public/Private Cert need to be installed in on the Server? (My assumption is Local Computer -> Personal, but this isn't documented anywhere)

That depends on what type of server you are using. edtFTPD keeps its private key and certificate in a files called server.key.pem and server.cert.pem, respectively; it does not use the Windows certificate stores. FileZilla Server also does not use the Windows stores, but keeps it in a file in the "FileZilla Server" directory.

Anyway, from a client point of view, it doesn't really matter how the server stores its certificates.

* What certificate store does that Server's Root Cert need to be installed in on the Server? (My assumption is Local Computer -> Trusted Root Certification Authorities)

Same as above.

* What certificate store does the Server's Public Cert need to be installed in on the Client? (My assumption is Current User -> Personal for standalone apps and Local Computer -> Personal for Windows Services according to the How To's)

You need to install it in a "Trusted root certification authorities" store. As you know there are several "locations" that have such store. I believe you can install it into any location related to the user that is running the FTP client application, e.g. Local Machine or Current User.

* Usually Certs from a CA have both the public and private keys stored together, then once installed into the Cert Store, the public key can be exported and distributed freely. Where is the documentation on what is exceptable in edtFTP and how it handles the Public, Private and Public/Private key variations?

As far as the server's certificate goes, the client does not require access to the server's private key. If the server uses certificate-based authentication then you will need both the private key and the certificate on the client-side.

So, in short, for certificate-based server validation you only ever need the server's certificate and for certificate-based client authentication you always need both the private key and the certificate.

* Since the Public/Private combined Key is installed in the Certificate Store (and both keys Public/Private combo and Public can't be installed into the same Cert store at the same time), what is the reasoning behind setting up the separate public TLSRSACertificateFile and TLSRSACertificateKeyFile parameters in the FTP Server?

In the default configuration of edtFTPD, the key and certificate are in separate files. I suppose you could probably store them in a single file and set both TLSRSACertificateFile and TLSRSACertificateKeyFile to point to this file, but I haven't tried it so I'm not sure. I guess the reasoning is that the server administrator might want to put them in separate file so they should have the option.

- Hans (EDT)

Answer 2

Apparently I'm not explaining myself well enough. I will try again. We are using a Windows 2003 Server Certificate Authority that can be configured through the OS. We are not using any Open SSL Certificates at this time. The reason for this is to simulate actual testing in a production environment where a Certificate has been issued by an Actual CA like Verisign or Thawte which most enterprises trust (and thus they trust the certificate chain based on who issued the certificate which is the whole purpose of X509 Certs). OpenSSL does not have that chain of trust where the certificates can be validated against an industry standard trusted third party. When using a Certificate Authority, there are many reasons that a Certificate can be issued, Validate of a User, Encryption, Code Signing, etc... From what I can gather, OpenSSL creates only one type of certificate and that is used for Encryption. Each certificate has it's own Template which is used by the Certificate Engine to create the desired type(s) of certificate(s) being requested. As for edtFTPD's certificates, since it uses the underlying FTPD Pro code, these values can be changed in the default.conf file (and should be by each enterprise wishing to have and use it's own Secure Certificate). The problem arises in that the default server.key.pem and server.cert.pem certificates were created in the PEM format. Certificates can be generated in about 8 different formats that I know of right off. My problem was I have been unable to find any documentation which says the certificate must be in PEM format so I was using the default format that Win2K3's CA created the *.cer file in (which is a Base64 encoding, which by the way was the only thing I found in documentation - that the cert needed to be in Base64 encoding). I realized the initial design of FTPD Pro was to run on *NIX plateforms, but Windows OSes use Certificate Stores to securely store these certificates (which stores them in the registry which is under the control of OS Security Policies) instead of leaving them sitting on a Server where anyone could get access to them. I will need to validate that the certs do not need to be stored in the CertStore as I believe once I installed them in the CertStore some of my issues went away.

Your response for where to store the Server's Public Cert does not make sense to me, please explain further. The Server's Public Cert is not a Root Certificate so it does not belong in a Trusted Root Cert Store. The Server's Public Cert pertains to a trusted entity, but can not issue Certificates itself so Root is not the proper location. The Server's Public Cert should go in the Local Machine's Personal Store and the CA who issued the Server's Cert should go in the Local Machine or Current User's "Trusted Root Certificate Authority" (which if using an industry standard CA like Verisign or Thawte should already be there). The Local Machine vs Current User store depends on if the client is running code as a Service or a User application.

I believe you also must understood me about the public/private Server's Certificate. I would never release the whole public/private certificate to the client, as that would defeat the purpose of public/private key encryption because the client would have both parts of the cert. What I was saying is on the FTP Server, it appears that the private key of your cert in the PEM format was broken out from the public key of your cert. When a Win2K3 CA issues a cert it issues the public and the private key together in one file. There was no documentation explaining how to break out just the private key from the combo key, or if the FTP Server had the ability to read the combo key and parse out just the private key and use it. I was looking for the HOW, which I have now found using the tool mentioned earlier.

Answer 3

Your response for where to store the Server's Public Cert does not make sense to me, please explain further. The Server's Public Cert is not a Root Certificate so it does not belong in a Trusted Root Cert Store. The Server's Public Cert pertains to a trusted entity, but can not issue Certificates itself so Root is not the proper location. The Server's Public Cert should go in the Local Machine's Personal Store and the CA who issued the Server's Cert should go in the Local Machine or Current User's "Trusted Root Certificate Authority" (which if using an industry standard CA like Verisign or Thawte should already be there). The Local Machine vs Current User store depends on if the client is running code as a Service or a User application.

Hi, if the CA who issued the server's cert is in the trusted root cert store then there should be no problem. If it is a self-signed cert, the server cert itself will need to be there.