Best Practice would be to set these properties within your application and not on the JVM Command line. You are setting these at way too high a level in most cases. Just my .02 worth.
Dream * Excel * Explore * Inspire Jon McAlexander Asst Vice President Middleware Product Engineering Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel 515-988-2508 | Cell 515-988-2508 jonmcalexan...@wellsfargo.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -----Original Message----- From: Beard, Shawn M. <sbe...@wrberkley.com.INVALID> Sent: Monday, April 27, 2020 11:47 AM To: Tomcat Users List <users@tomcat.apache.org> Subject: RE: tomcat and ssl [EXTERNAL] Adding this to the JVM options worked: -Djavax.net.ssl.trustStore=/usr/apache/tomcat/ssl/TomcatTrustStore.p12 -Djavax.net.ssl.trustStorePassword=XXXXXXXX Shawn Beard Sr. Systems Engineer BTS +1-515-564-2528 -----Original Message----- From: Mark Thomas <ma...@apache.org> Sent: Monday, April 27, 2020 11:34 AM To: users@tomcat.apache.org Subject: Re: tomcat and ssl [EXTERNAL] ** CAUTION: External message On 27/04/2020 17:29, Beard, Shawn M. wrote: > This is a 3rd party app so can't do that. We need to configure tomcat to have > apps use a trust store just like any other java container. That isn't the way Java SE, Java EE (now Jakarta EE), JSSE, and web applications work. Tomcat has ZERO role in out-going SSL connections. Any container that claims otherwise is doing nothing more than setting the relevant system properties. It sounds like setting a trust store via system properties is your only option (although personally I'd be raising a bug against that 3rd-party app as relying on system properties for configuration can be fragile). Mark > > > > Shawn Beard > Sr. Systems Engineer > BTS > +1-515-564-2528 > > -----Original Message----- > From: Mark Thomas <ma...@apache.org> > Sent: Monday, April 27, 2020 11:26 AM > To: users@tomcat.apache.org > Subject: Re: tomcat and ssl [EXTERNAL] > > ** CAUTION: External message > > > On 27/04/2020 17:21, Beard, Shawn M. wrote: >> I have an app running in tomcat 9 that makes an ssl call to an >> external webservice. >> >> >> >> It fails with these errors in the logs: >> >> ERROR javax.net.ssl.SSLHandshakeException: PKIX path building failed: >> sun.security.provider.certpath.SunCertPathBuilderException: unable to >> find valid certification path to requested target >> >> >> >> I have this in the connectors in the server.xml. >> >> keystoreFile="/usr/apache/tomcat/ssl/TomcatTrustStore.p12" >> >> truststoreFile="/usr/apache/tomcat/ssl/TomcatTrustStore.p12" >> >> keystorePass="XXXXXXXX" >> >> truststorePass="XXXXXXX" >> >> >> >> >> >> I have the root authority certs importated as trusted certs in this >> p12 file. >> >> >> >> Any ideas? > > Outgoing SSL calls are nothing to do with Tomcat. Configuration in server.xml > will have zero impact on them. You need to code the out going call exactly > the same way as you would in a stand-alone Java program. My recommendation is > you configure the connection programmatically rather than via system > properties although the system properties approach should work. > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > CONFIDENTIALITY NOTICE: This e-mail and the transmitted documents contain > private, privileged and confidential information belonging to the sender. The > information therein is solely for the use of the addressee. If your receipt > of this transmission has occurred as the result of an error, please > immediately notify us so we can arrange for the return of the documents. In > such circumstances, you are advised that you may not disclose, copy, > distribute or take any other action in reliance on the information > transmitted. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org CONFIDENTIALITY NOTICE: This e-mail and the transmitted documents contain private, privileged and confidential information belonging to the sender. The information therein is solely for the use of the addressee. If your receipt of this transmission has occurred as the result of an error, please immediately notify us so we can arrange for the return of the documents. In such circumstances, you are advised that you may not disclose, copy, distribute or take any other action in reliance on the information transmitted. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
