Java SSLHandshakeException in VeriSign signed certificate

Question

In a Java desktop application I need to connect to a SSL URL. When I try it, I get the exception:

SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

To solve it, I go to the address with my browser, download the certificate in .cert file and import in my java cacerts keystore using keytool command. After this, the application works fine.

My question is: why java don't recognize the certificate if this is signed with VeriSign? VeriSign certificate is not installed in cacerts keystore by default? Maybe I don't understand how SSL works. What's the difference between browser and java desktop behavior? I can connect to this URL with my browser without installing nothing.

Thanks

Answer 1

When we access a secure site which uses SSL for providing identity and encryption, it provides a certificates which was verified by a trusted third party sites like verisign, godaddy or thwate.

By using certificates browser or java clients knows that they talking to the correct site (who it claims to be) and not on redirected proxy site. this step is pretty transparent if you access websites using browser because if certificate is not on browser's trusted store it will ask you to add that certificate and it will be subsequently added.

But when you access a secure site using Java program, this step of certificate hand shaking is not transparent to user and certificates are verified form JRE's trustStore.

Read more: http://javarevisited.blogspot.com/2012/03/add-list-certficates-java-keystore.html#ixzz32v1wL3Gl

Answer 2

You did not say which certificate you imported into the keystore. Usually there are several certificates involved in the verification:

• the trusted root certificate, which is stored in the keystore or browser (Java does not share the keystore with the browser)
• the leaf certificate which identifies the site
• and most times also intermediate certificates, which provide a signed way from the leaf certificate to the trusted root and thus establish a trusted path

If any of the intermediate certificates is missing, the verification fails. So the server has to send not only the leaf certificate, but all intermediate certificates too. And this is where lots of sites fail, eg they don't provide the full certificate chain.

But why does this work in the browser? Because enough sites fail to provide the intermediate certificates and because the browser wants to provide the best experience, they will cache the intermediate certificates. Thus, if you go to one site signed by verisign which provides the trusted chain, and then go to another site signed with the same certificate, but which does not provide the chain, then it will still work, because the chain certificates are cached from the other side.

But, if you use a fresh system (or simply a new browser profile with firefox) and visit the misconfigured site first, it will complain there too, as much as the Java application did. And if you just import the relevant intermediate certificate into the keystore and thus trust it it will work too, because it does not need the rest of the chain to get a path to a trusted certificate.