> -----Original Message----- > From: Mark Thomas <ma...@apache.org> > Sent: Sunday, August 09, 2020 2:19 PM > To: Tomcat Users List <users@tomcat.apache.org> > Subject: Re: Tomcat 8.5.(x > 5) & SSL Connections > (sun.security.provider.certpath.SunCertPathBuilderException) > > On August 8, 2020 6:59:23 PM UTC, David Filip <dfi...@colornet.com> wrote: > >Hello Everyone! > > > >I spent a large part of yesterday and this morning trying to debug an > >SSL problem on Tomcat 8.5.57 to no avail. I've seen some discussion on > >either this problem or something related back in 2016, but wanted to > >confirm what the "correct" solution might be, because I got lost in the > >threads. > > > >I never had this problem with Tomcat 7.0.x, but it started once I > >upgraded to 8.5.57 (same application code), and it is related to making > >outgoing SSL connections to web services. And this is NOT related to a > >self-signed, but to a commercial (GoDaddy) SSL certificate, albeit on a > >server that I also run in the cloud. > > > >The exception is being thrown when trying to connect to an SSL > >protected web service is: > > > >sun.security.validator.ValidatorException: PKIX path building failed: > >sun.security.provider.certpath.SunCertPathBuilderException: unable to > >find valid certification path to requested target > > > >although the exact same code worked (and still works on other servers) > >reliably under Tomcat 7.0.x for several years. > > > >Now, here is the weird part: after Google'ing around, I thought the > >problem might be that Tomcat 8.5.5 and later -- at least this is the > >gist that I got -- no longer finds the 'default' Java certificate store > >(cacerts), so I added the following to /bin/catalina.sh (running on a > >Mac 10.14 / Mojave): > > > >export > >-Djavax.net.ssl.trustStore=/Library/Java/JavaVirtualMachines/jdk1.8.0_1 > >21.jdk/Contents/Home/jre/lib/security/cacerts > > > >The weird part is that this appeared to fix the problem, so I thought I > >was done. Then, I rebooted, and the problem re-appeared! > > > >I stopped and started Tomcat, and the problem was resolved again. I > >rebooted again, and the problem re-appeared. > > > >Previously, when it worked, I refreshed the page several times, and it > >kept working. When it doesn't work, if I keep refreshing the page, it > >continues to throw the exception. > > > >Does this mean that some "worker threads" can find the certificate > >store, and others can't? Or am I going down the wrong rabbit hole? > > > >So, any idea? The intermittent nature is driving me crazy! > > > >And I have can reproduce the problem on two separate servers (both Mac > >10.14 / Mojave, both Java 1.8.0), one (new server) running 8.5.57 and > >one (slightly older server) running 8.5.35. But again, I have several > >7.0.x instances where I've never seen this problem before. > > > >Also, the generic 'SSLPoke' always connects to the service, and it > >appears that if I run (mostly) the same code from the command line > >outside of Tomcat (javac / java) it always works. And if I paste the > >web service URL into Safari or Chrome, it always works. And if I use > >the web service URL with curl (just for good measure), it always works. > > So it only seems to fall under Tomcat 8.5.x. > > > >Thanks in advance for any guidance, as I'm running out of things to > >Google and try. > > > >Regards, > > > >Dave. > > Tomcat has zero involvement in outgoing TLS connections. > > If the code works in a standalone Java app, it will work in a Servlet assuming > the code is thread safe (I don't see why it wouldn't be but worth double > checking any library being used) and configuration information is accessible. > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org
I agree with Mark. This is probably an issue with the inability to find a CA in your trust store that matches the cert the server is presenting. I would guess the different versions of Tomcat are looking at different trust stores, which are not included with Tomcat. Probably the best thing to do would be to run with -Djavax.net.debug=ssl. This will tell you what trust store is being used and what's in it. It says right near the beginning of the output "trustStore is: /path/to/trust/store." It will also show you the cert that the server is presenting. Look below "ServerHello." It produces a ton of output and is almost unusable if more than one request is going on at one time however, so it's best if you can run it on a "quiet" system. Output will go to catalina.out.
