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.