Hi David, when debugging SSL problems, it is important to know, which certs are the troublemakers. Are those errors reported when tomcat is used as a client as a server?
Try to get more information about the cert that is making problems. I always try to get the cert with an openssl command like </dev/null openssl s_client -connect <server>:<port> | openssl x509 -text It will print out a lot of information about the cert of the target you want to access (I assume, that you use tomcat as a client, that is your app code is the client). Problems with a cert could arise from an old hashing algorithm, a signing CA, that your trust store doesn't trust, a signature algorithm, ... If you want to debug yourself a bit further, you could switch on the debugging of certs/ssl stuff by setting the JVM system property javax.net.debug=all (or a bit less). As a tip, I would add properties via $CATALINA_BASE/bin/setenv.sh instead of editing catalina.sh. Cert problems depend on the trust store you are using and each JVM brings there own set of trusted ca certs, so be sure to have a look at the used JVMs. Which worked, which doesn't? Hope this will help you debugging the problem further. Felix Am 09.08.20 um 00:16 schrieb David Filip: > Well, it is not consistent ... sometimes when I stop and start it from the > command line it works, and other times it doesn't, but every time it is > getting the -Djavax.net <http://djavax.net/>.ssl.trustStore parameter ... > which I check by doing a: > > $ ps -aef | grep java | tr ' ' '\n' > > which lists each parameter on a separate line. So I wish it were that > simple, but it does not appear to be so. But specifically to answer your > question, I use this script to toggle tomcat on and off: > > # tomcat > # > # Start / Stop Tomcat Application Server > # > # - If tomcat is running, stop it > # - if tomcat is not running, start it > # > # 24-Apr-2010 - DEF, original coding > # > > found=`ps -aef | grep /Library/Tomcat/bin/bootstrap.jar | grep -v grep | wc > -l` > > if [ $found -eq 0 ] > then > echo Starting Tomcat Application Server ... > sudo launchctl load /Library/LaunchDaemons/org.apache.tomcat.plist > else > echo Stopping Tomcat Application Server ... > sudo launchctl unload /Library/LaunchDaemons/org.apache.tomcat.plist > fi > > And the org.apache.tomcat.plist contains: > > <?xml version="1.0" encoding="UTF-8"?> > <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" > "http://www.apple.com/DTDs/PropertyList-1.0.dtd";> > <plist version="1.0"> > <dict> > <key>Label</key> > <string>org.apache.tomcat</string> > <key>RunAtLoad</key> > <true/> > <key>ProgramArguments</key> > <array> > <string>/Library/Tomcat/bin/catalina.sh</string> > <string>run</string> > </array> > <key>StandardOutPath</key> > <string>/tmp/Tomcat.log</string> > <key>UserName</key> > <string>tomcat</string> > </dict> > </plist> > > so it is using catalina.sh. But right now, I just ran this command: > > $ ps -aef | grep java | tr ' ' '\n' | grep -- '-D' > -Djava.util.logging.config.file=/Library/Tomcat/conf/logging.properties > -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager > -Dbis.home=/home/infodesk > -Dbis.download=/tmp > -Dinfodoc.home=/home/infodesk > -Dinfodoc.download=/tmp > -Djavax.net.ssl.trustStore=/Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/jre/lib/security/cacerts > -Djdk.tls.ephemeralDHKeySize=2048 > -Djava.protocol.handler.pkgs=org.apache.catalina.webresources > -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 > -Djava.endorsed.dirs=/Library/Tomcat/endorsed > -Dcatalina.base=/Library/Tomcat > -Dcatalina.home=/Library/Tomcat > -Djava.io.tmpdir=/Library/Tomcat/temp > > and that file exists: > > $ ls -l > /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/jre/lib/security/cacerts > -rw-rw-r-- 1 root wheel 115588 Dec 1 2019 > /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/jre/lib/security/cacerts > > but I am getting the error: > > sun.security.validator.ValidatorException: PKIX path building failed: > sun.security.provider.certpath.SunCertPathBuilderException: unable to find > valid certification path to requested target > > However, I may have previously misspoken, as I *thought* it was related to > Apache 8.5.x, because I saw it on the new server with 8.5.57 but not an older > server running 7.0.x, and when I upgraded the old 7.0.x server to 8.5.57 it > immediately began to exhibit the problem. So cause and effect, right? But I > just downgraded the old server back to 7.0.x, and I am still seeing the > problem! Ugh! > > So I tried running the same app on an 8.5.37 server running on AWS Linux 2 > (similar to CentOS 7), and it works fine there, even after stopping and > starting the Tomcat server 6 (!) times -- just because I don't trust anything > right now. > > My original thought -- which I did not previously share because I convinced > myself it was crazy -- was that I first noticed the problem after I applied > the latest macOS security patch. However, once I saw that the Tomcat 7.0.x > server with the same macOS security patch did not exhibit the problem, I > ASSUMED it was related to the Tomcat version ... but as I said, now that I > have downgraded that server back to 7.0.x, I am not still -- sometimes -- > seeing the problem. Ugh. > > So I am now taking the "new" server and restoring from a backup taken a week > ago -- before I applied the macOS security patch -- to see if that makes a > difference. > > Given all of that, I can assure you that I am not drinking -- at least not > while in front of a computer -- and I am not taking any drugs, and as far as > I know, I am not clinically insane. But I still can't explain all of the > inconsistencies I am seeing, and the one thing that I always hate most when > debugging a problem is lack of a consistent reproducibility. > >> On Aug 8, 2020, at 5:17 PM, calder <calder....@gmail.com> wrote: >> >> On Sat, Aug 8, 2020, 13:59 David Filip <dfi...@colornet.com >> <mailto: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_121.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. >>> >> >> >> When you "stopped and started Tomcat", how did restart it? At the command >> line using one of the Tomcat shell scripts? >> >> My thought is, "whatever" fires up Tomcat after an iOS system reboot - that >> startup process does not call catalina.sh. >> >> But when you start Tomcat manually, using catalina.sh or startup.sh (which >> calls catalina.sh), it works because the Java option is being set. >> >> >> >> 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. > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
