SSL authentication

Question

Hi All. :D
I'm a newbie using the library. :?
I'm trying to set up a fully validating client, following the code sample you provide along with the library.
As far as I understand, I should have the server's certificate on the client side before the SSL handeshake can successfully be accomplished.

ftp.getRootCertificateStore().importPEMFile(serverCertFilename);

I'm not supposed to own the server's certificate itself, but perhaps only the CA certificate of the trusted CA which signed the server's cert. :roll:

If this is required in order to perform hostname checking, I think the hostname provided in the connect call should be enough in this regard... :?:
... or am I missing something:?: :roll: :roll:

Thanks in advance,
Rgds. :D

Answer 1

You need either the server's certificate or the root cert which contains the cert of the signing CA as you say - this is how server validation is performed in SSL/TLS. The hostname isn't enough, as a server could easily have a false hostname in a self-signed certificate.

Answer 2

Hi Bruce :D
thanks for your quick reply!

trying to load the CA certificate with the FullyValidatingClient sample, I got the following error:

INFO [FullyValidatingClient] 5 Dec 2006 10:29:06.576 : Switching to FTPS (explicit mode)
ERROR [com.enterprisedt.net.puretls.cert.X509Cert] 5 Dec 2006 10:29:11.689 : verify : SHA-1/RSA/PKCS#1: Not an RSA public key
java.security.InvalidKeyException: SHA-1/RSA/PKCS#1: Not an RSA public key
at com.enterprisedt.cryptix.provider.rsa.Any_RSA_PKCS1Signature.engineInitVerify(Unknown Source)

The CA-crt.pem cert I provided as the last argument to the java executable, is a PEM file I produced myself, using openssl.
I created my own certification authority (private/public keys, certificate signing request, self-signed certificate: CA-crt.pem).
I used such a CA to sign several certificate requests: the server's and the client one as well.

So what's the story there :?:

Apologise for being such a dummy :lol: :lol:

thanks again ;)

Answer 3

If you could email your CA cert to us (support at enterprisedt dot com) we'll take a look.

Answer 4

Hi Cesare

Analysis of your error message has shown that the exception that is being thrown is not directly a result of the certificate that you are loading. It is in fact related to the certificate that the server is sending to the client, which may be different from the one that you are loading into the certificate store.

The basic procedure of server validation is that the server sends its certificate (see note below) to the client. The client (i.e. our software) parses the certificate and then tries to validate it by matching it to the certificates in its certificate store.

It fails during the validation due to a problem with the RSA public key that is included in the certificate. It appears that you are not using the latest version of the library since the latest version has a more informative error message.

Can you please download the latest version and try it (use the download details that were e-mailed to you). You might in fact find that it fixes the problem since there was some work done on this code in the past few months. If it doesn't then could you please post the full exception and stack-trace to this forum.

Also, you should find that the exception that you are catching is an SSLFTPCertificateException. This exception has 3 printCertificates() methods which give you access to the certificate that the server sent. Please use this method to export the certificate to a file (you can cut-and-paste it from your log into a text-file), and then use OpenSSL to view the certificate.

If possible, please also e-mail this certificate to support so that we can view it.

- Hans (EDT)


(Note: If the certificate is not a self-signed certificate then it will also send the certificate of the issuer, and that of its issuer, and so on up to the root certificate.)

Answer 5

Hi All.
I think there is a misunderstanding here... :roll:

I know the certificate I'm getting from the server is not the one I sent you!
I sent you the CA's certificate; not the server's one.
The server cert has indeed been signed by the CA I have sent you the cert of.

Our aim was not to be forced using the server's certificate on the client side.
We wish we used the CA cert only, storing it (how???) among the trusted CAs, being therefore able to trust the incoming server's certificate has not been tampered with.
Hope it helps a bit clarifying the scenario.

Anyway, I'm going to download the latest version of the lib and I'll keep you posted about the exception stacktrace we'll get ;)

Thanks a lot for your help! :D

Answer 6

I did understand you initially, but then got a bit side-tracked while I was writing my reply. In any case, it doesn't change anything since my reply is valid whether the problem is with the root certificate or the server certificate.

- Hans (EDT)

Answer 7

Hi guys :D

Latest version of the lib fixes it! 8)

Thank you so much for your precious help! :wink: