“PKIX path building failed” despite valid Verisign

Question

I'm having a similar problem as described here:

The Webserver I talk to updated its SSL cert and now my app can't talk to it

"PKIX path building failed" exception despite having a valid Verisign certificate.

What I don't understand is why the server works fine when I hit the same URL in a web browser.

The server is sending the whole certificate chain and I can see it in my web browser:

   (Verisign root)
     -> (VeriSign Class 3 Secure Server CA - G3) 
       -> (my server) 

But for some reason, Java and OpenSSL command line tools aren't seeing it.

wget fails, and openssl s_connect only sees the intermediate "G3" certificate.

Yet IE and Chrome - no problems.

What's going on here?

Answer 1

Seems that G3 is not considered trusted by Java and openssl

Answer 2

What you see in the browser isn't necessarily the chain sent by the server, but it's rather the chain reconstructed by the browser. It's possible that Windows has the G3 intermediate CA as a trusted anchor, whereas the other clients don't.

To check the actual chain sent by the server, use -showcerts with s_connect:

openssl s_client -showcerts -connect your.host.name:443

Make sure the chain is sent in the correct order: server certificate first, followed by intermediate certificates, if required.

Certificate chain
 0 s:/.../CN=your.host.name
   i:/.../CN=VeriSign Class 3 Secure Server CA - G3
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:/.../CN=VeriSign Class 3 Secure Server CA - G3
   i:/.../CN=Verisign root
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

(Just in case, check that you're getting the correct certs, just in case you're using SNI, but using versions of Java or OpenSSL that don't support it.)

A good tool to check this is the Qualys SSL labs test.

In addition, depending on how wget or openssl were installed, they often don't have a default list of trusted anchors, so you would have to give them a path to a bundle of CA certificates explicitly.

Answer 3

This can happen because the root certificate must reside locally (on the client) in order to be trusted. If the verisign root certificate in question is not trusted locally, then it doesn't matter if it's included in the chain sent by the server - it's not trusted by the client.