Certificate verification in case of OpenSSL and WL/Java

Question

I am trying to connect to an application over SSL. When connecting through WL/Java then I get sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification and I understand that this is because I don't have server's certificate installed in my WL/Java's trusted store.

I imported the certificate from browser, installed it using keytool and now everything is working fine.

However, below are few unresolved questions:

• When I used openssl s_client command to connect with same host:port then the SSL handshake was successful. And this was before I added that certificate to my trusted store.

  • Why SSL handshake was successful in case of openssl without adding the certificate in keystore?

• Browser doesn't contain the certificate in its trusted CA store, it only contains the certificates of trusted CA, and then it matches whether the signer CA of the server's certificate is present in its trusted CA store or not. If yes then it authenticates the server.

  • In case of server, why the server was not authenticated even though the server's certificate signer's (EnTrust) certificate was present in my keystore. Why I needed to import the server certificate in my keystore as opposed to browser where it was not required?
• Only the server's certificate's signing CA's certificate need to be present in the keystore or the server's actual certificate should be present?

Answer 1

1. Did openssl verify the cert or merely connect? openssl s_client is designed as a test tool not a real application, and it will continue with a connection even though the certificate does not verify, whereas a real client will abort or at least give a big warning like most browsers. Did you specifically check the Verify return code output just before user data (output or input, depending) or the verify callback log near the beginning?

2. Only the root CA cert used for the server's cert should be needed in the client's truststore. Decades ago you could have just an entity like a server and a single CA that directly signs it. Today there are almost always multiple levels of CA, and the server is supposed to send the intermediate or "chain" certs automatically and/or provide information in extensions that allows them to be fetched. See first autolink Trouble understanding SSL certificate chain verification and canonical https://security.stackexchange.com/questions/20803/how-does-ssl-work/ . There are some exceptions such as a newly-created CA that doesn't yet have its root well distributed.

3. I don't know about WL and it's my understanding that Android may delay getting new version(s). On desktop (Oracle) Java, SunCertPathBuilder was supserseded by PKIXCertPathBuilder several years ago (although the Sun version still exists and works). Desktop Java has several (four) Entrust roots which changed a few times over the past several years, and current Firefox and I don't know which they are using now, or recently, or which your server needs. But if the root cert shown by your browser as the top of the cert chain is in your Java truststore, the Java handshake should work. Note that the "human" names for these multiple certs are similar but not the same; also check the fingerprint/thumbprint to be sure its really the same cert.