SSL handshake exception: unable to find valid certification path to requested target

  • 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: PKIX     path building failed: 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.

    Thanks Steffen, even without using SNI we're coming up short.

    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.

  • The trust chain for this site is like this:

    [0] /
    [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= is incorporated by reference, O="Entrust, Inc.", C=US`, SHA1 fingerprint beginning `B3:1E:B1:B7` which verifies cert [2], and ...

    ... 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, 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 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.

  • 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?

    You can check the chain with openSSL: connect to your server with `openssl s_client -connect :443 -showcerts`

    Usually, yes: you need to install the intermediary CA because most client do not have them, they only carry the roots.

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM