Java + OS problems: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

[dfilip]

Unfortunately, I am having problems with SOME Java JREs, which seem to be related more to the OS than to the version of Java, due to a problem verifying the certificate chain. I am using recently (yesterday) created Let's Encrypt certificates via Certbot, and using an Apache (2.4.37) server (front-ending a Tomcat java server). The domain is not currently accessible externally (it is currently behind a firewall), which is why I am not listing it here. The Java error is:

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

So if the Java client connecting to the Apache server with a Let's Encrypt certificate is JDK 8 or JDK 11 on MacOS, it works correctly; if it is JDK 8 or JDK 11 on Linux (CentOS 8), I get that error.

Browser (Safari or Chrome on Mac) work correctly (certificate is valid), and curl (command line) on Mac works correctly, but fails on Linux (CentOS 8) with the error:

"curl: (60) SSL certificate problem: self signed certificate in certificate chain"

"curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above."

So like Java, with curl seems to depend on the OS. I tried importing w/trust the cert.pem file, as well as importing the chain.pem file into the Java cacerts file, but that does not seem to fix the problem. On Linux (CentOS 8) I have tried different JDK flavors (Oracle, OpenJDK, and Azul / Zulu) and regardless of JDK 8 or 11, it seems to work (Java + curl) on MacOS (10 and 11), and not on Linux, either CentOS 8 or Raspbian (Debian port to Raspberry Pi).

Not sure what additional information is relevant, and I care less about curl than Java, but as the problem seems related more to the OS than the JRE/JDK version, I think that might be relevant. My JRE/JDK version 8 is update >200, which should work according to the Let's Encrypt compatibility page.

So does anyone have this working correctly from (client) JDK / JRE running on Linux connecting correctly to (server) Apache 2.4 with a Let's Encrypt certificate?

Of course, I should mention that my Java client code also works correctly as-is (and has fr many years) from Linux JRE/JDK 8 connecting to an Apache 2.4 server with a GoDaddy SSL certificate. I am migrating from an old server w/GoDaddy SSL certificate to a new server with Let's Encrypt SSL certificate, which is why I am now having this problem.

Please advise, and let me know what other relevant information I can provide.

Regards,

Dave Filip
dfilip@colornetlabs.com

[orangepizza]

let's try openssl s_client -connect (your server):port . to see what chain your webserver gives to client

[dfilip]

Thanks for suggesting that! It led me to the right solution, which turned out NOT to be a Let's Encrypt problem, per se, but a DNS problem. Turns out I fell so far down the rabbit hole that I was chasing the wrong root cause!

As part of migrating to new SSL protected web servers with Let's Encrypt, I'm also implementing new DNS servers, and the systems that didn't work -- which happened to be all Linux -- were pointing to the old server with the new server name.

I realized this when I connected with openssl and saw the wrong SSL certificate from Linux systems and the right one from Mac systems, so after a hard slap to the head and a verbal 'Duh!', I understood that I had a split-DNS configuration problem.

So thanks for suggesting the command that led me to understand what I had done!