Hi, we have a Java web app hosted on an Ubuntu server. We are accessing a https API in our web app. Did not have any problems until the API server switched to a Lets Encrypt ssl certificate. I have installed the signed root certificate like suggested in some help forums I found. (https://letsencrypt.org/certs/isrgrootx1.pem.txt)
However this did not fix the problem. Please help. Any ideas or suggestions are welcome. Thanks!
Here is a part of the Java exception we are getting:
I/O error on GET request for “https://api.xxxx.com”:sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target; nested exception is 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
org.springframework.web.client.ResourceAccessException: I/O error on GET request for “https://api.xxxx.com”:sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target; nested exception is 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
Very few sites are currently using the ISRG root for their suggested certificate chain. Instead, they generally use the IdenTrust (“DST”) root. As of now, the ISRG root is only trusted by a minority of clients and hence not relied upon by most servers.
If you want the root that is assumed by almost all sites using LE certs today, you should follow the link there to “DST Root CA X3” instead of “ISRG Root X1 (self-signed)”.
which one exactyl are you talking about? the one titled “Let’s Encrypt Authority X3 (IdenTrust cross-signed)” or “Let’s Encrypt Authority X3 (Signed by ISRG Root X1)”? or another one?
Looks like they have everything… here are the results:
Server Key and Certificate #1
Subject api.bulutfon.com
Fingerprint SHA1: 37d52e22e2d76dd156274fcc137a97e4c4cd0897
Pin SHA256: O8n4t8n7pChS5gcrLNEllTTNK4hyHYH7PumnX9pLafs=
Common names api.bulutfon.com
Alternative names api.bulutfon.com
Valid from Sat, 04 Mar 2017 10:35:00 UTC
Valid until Fri, 02 Jun 2017 10:35:00 UTC (expires in 1 month and 26 days)
Key RSA 2048 bits (e 65537)
Weak key (Debian) No
Issuer Let’s Encrypt Authority X3
AIA: http://cert.int-x3.letsencrypt.org/
Signature algorithm SHA256withRSA
Extended Validation No
Certificate Transparency No
OCSP Must Staple No
Revocation information OCSP
OCSP: http://ocsp.int-x3.letsencrypt.org/
Revocation status Good (not revoked)
DNS CAA No (more info)
Trusted Yes
Additional Certificates (if supplied)
Certificates provided 2 (2462 bytes)
Chain issues None #2
Subject Let’s Encrypt Authority X3
Fingerprint SHA1: e6a3b45b062d509b3382282d196efe97d5956ccb
Pin SHA256: YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=
Valid until Wed, 17 Mar 2021 16:40:46 UTC (expires in 3 years and 11 months)
Key RSA 2048 bits (e 65537)
Issuer DST Root CA X3
Signature algorithm SHA256withRSA
Hide Certification Paths Certification Paths
Path #1: Trusted
1 Sent by server api.bulutfon.com
Fingerprint SHA1: 37d52e22e2d76dd156274fcc137a97e4c4cd0897
Pin SHA256: O8n4t8n7pChS5gcrLNEllTTNK4hyHYH7PumnX9pLafs=
RSA 2048 bits (e 65537) / SHA256withRSA
2 Sent by server Let’s Encrypt Authority X3
Fingerprint SHA1: e6a3b45b062d509b3382282d196efe97d5956ccb
Pin SHA256: YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=
RSA 2048 bits (e 65537) / SHA256withRSA
3 In trust store DST Root CA X3 Self-signed
Fingerprint SHA1: dac9024f54d8f6df94935fb1732638ca6ad77c13
Pin SHA256: Vjs8r4z+80wjNcr1YKepWQboSIRi63WsWXhIMN+eWys=
RSA 2048 bits (e 65537) / SHA1withRSA
Weak or insecure signature, but no impact on root certificate
can help you somehow (although they’re describing it there as more likely to be a problem with client certificates, which I’m assuming you’re not using at all).
Thanks again. However this did not help either
I have some new information though. I got it working on our test server, but applying the same procedure did not fix it on our prod server. The only difference between the 2 is our prod server uses SSL. Can this error have something to do with our SSL is what Im thinking now What do you think?
Btw I also did connection tests on our prod server using openssl s_connect and a 3rd party app called SSLping and looks like the connection was successful…
Oh, I see. Well, it might be helpful to keep trying on StackOverflow a bit because you might find more people familiar with the Java implementation, or maybe some of the debugging ideas in the thread I linked to above.
Finally got it fixed! the problem was because the JAVA_HOME var on our production server was pointing to the wrong Java version, so the key was being added to the wrong JRE. Thanks a lot for your help efforts!
What do you think?
the problem was because the JAVA_HOME var on our production server was pointing to the wrong Java version, so the key was being added to the wrong JRE. Thanks a lot for your help efforts!