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

EnviroFlash · 2011-08-03T18:44:42.000Z

We just started getting the following error. sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target. Did something change on Twitter’s end. We haven’t changed our code in months.

episod · 2011-08-03T19:05:16.000Z

In the past few weeks we changed the SSL certificate used on api.twitter.com. If you hadn’t restarted your servers in awhile, it may explain why you’re only now coming across this issue. See [node:533] for more information.

EnviroFlash · 2011-08-04T02:42:17.000Z

I have verified that the Class 3 Public Primary Certification Authority - G2 certificate is in our Java keystore. Is there anything else that we could be missing?

DJ_flop · 2012-08-17T06:26:32.000Z

Since 04/25/2012, there seem to be some Twitter API servers using a new SSL certificate.

(The old one seems to expire in about three weeks time.)

The new SSL certificate is signed with a VeriSign Class 3 Secure Server CA - G3 root cert.

However, the intermediate cert / root cert provided by these Twitter API servers are the old ones:

VeriSign Class 3 Secure Server CA - G2

Here’s the output from openssl:

openssl s_client -showcerts -connect 199.59.149.232:443 -CAfile PCA-3G3.pem < /dev/null
CONNECTED(00000003)
depth=0 /C=US/ST=California/L=San Francisco/O=Twitter, Inc./OU=Twitter Security/CN=api.twitter.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /C=US/ST=California/L=San Francisco/O=Twitter, Inc./OU=Twitter Security/CN=api.twitter.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 /C=US/ST=California/L=San Francisco/O=Twitter, Inc./OU=Twitter Security/CN=api.twitter.com
verify error:num=21:unable to verify the first certificate

verify return:1

Certificate chain
0 s:/C=US/ST=California/L=San Francisco/O=Twitter, Inc./OU=Twitter Security/CN=api.twitter.com
i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa ©10/CN=VeriSign Class 3 Secure Server CA - G3
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa ©09/CN=VeriSign Class 3 Secure Server CA - G2
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority - G2/OU=© 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network

The SSL chain contains the G3 signed TwitterAPI cert but then the (regular) G2 root cert.

I don’t know if this is a problem for all SSL implementations, but at least on Symbian it doesn’t work this way.

A online SSL verification tool reported a broken intermediate / chain, too.

I’ve read similar reports from Opera users, Chrome users

netik · 2012-08-17T21:41:44.000Z

We’ve checked all of our servers and at this time we do not see any servers reporting the old G3 SSL certificate. If you are able to reproduce this (even inconsistently) could you please reply and let us know?

Including the full output, as you’ve done above, again would be extremely helpful.