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