We are using a third party payment service for our web users to be able to pay for courses. Once payment is completed however, payu attempts to connect to our site and run an IPN. However, they get the following error:

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

Since our certificates are completely correct and up to scratch I can only imagine their services need to have the root CA certificate installed in their java trustore. Is this correct? Or is there something else we are missing?

  • If you have just a normal public CA it should be already in their certificate store. But there might be SNI needed to access your site and older versions of Java do not support it. Please check your site against SSLLabs. – Steffen Ullrich Jan 8 '15 at 10:03
  • Thanks Steffen, even without using SNI we're coming up short. – user1658296 Jan 8 '15 at 10:40
  • It would probably be a good idea if you would tell us the URL which causes the problem, so that we don't need to guess about possible causes. – Steffen Ullrich Jan 8 '15 at 10:48

The trust chain for this site is like this:

[0] /CN=www.vitalityinstitute.co.za
[1] /CN=Entrust Certification Authority - L1K
[2] /CN=Entrust Root Certification Authority - G2
[R] /OU=(c) 2006 Entrust, Inc./CN=Entrust Root Certification Authority

The first 3 certificates are send by your server and the last one should be in the local certificate store as a trusted certificate. But, according to this PDF from 2010 this certificate is not included in the trust store by default. Instead older certificates from Entrust are included.

Thus there are probably two options:

  • add the missing certificate as trusted to Java
  • or add the missing certificate to the chain of the web server. Since this certificate itself is signed by an older certificate from Entrust and this older certificate is probably included in Javas trust store this might just work. Unfortunately, this might cause problems with OpenSSL based clients as described here.
  • I don't know what Java that PDF is, but I've tested most (Sun/Oracle) JDKs since 6u17 circa 2009-10 and all included alias entrustevca, name CN=Entrust Root Certification Authority, OU="(c) 2006 Entrust, Inc.", OU= www.entrust.net/CPS is incorporated by reference, O="Entrust, Inc.", C=US, SHA1 fingerprint beginning B3:1E:B1:B7 which verifies cert [2], and ... – dave_thompson_085 Jan 9 '15 at 2:59
  • 1
    ... since 6u24 circa 2011-02 also alias entrustrootcag2 name Owner: CN=Entrust Root Certification Authority - G2, OU="(c) 2009 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc. ", C=US, SHA1 8C:F4:27:FD, which has the same key as cert [2] and (as then expected) verifies cert [1]. Of course the application at payu could be using a truststore that has been changed from the default, or even an entirely custom trustmanager. – dave_thompson_085 Jan 9 '15 at 3:02
  • @dave_thompson_085 That sounds very likely indeed, as payu is able to run the ipn when we test using their staging services, it is only when using their production services that the SSL exception is thrown, which makes me think their trustore is different between the production and development environments. – user1658296 Jan 9 '15 at 6:29

The typical reason why this type of errors come up is because the server does not provide a full certificate chain during handshake. That usually happen when the intermediate CA isn't installed.

  • According to SSLLabs we have provided a full certificate chain - or is there perhaps more to this? And do we need to install an intermediate CA? – user1658296 Jan 8 '15 at 10:41
  • 1
    You can check the chain with openSSL: connect to your server with openssl s_client -connect <host name or IP>:443 -showcerts – Stephane Jan 8 '15 at 13:42
  • Usually, yes: you need to install the intermediary CA because most client do not have them, they only carry the roots. – Stephane Jan 8 '15 at 13:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.