I have changed my original configuration to include the *keystoreFile* and
the *truststoreFile* within the connector. This allows client
authentication to occur correctly even though it was already defined via
the *SSLCACertificateFile* and the *SSLCACertificatePath* keys in the
connector. Mark, you were correct in defining that those additional keys in
the connector would allow the connector to override what was already set
via the system properties *javax.net.ssl.keyStore* and
*javax.net.ssl.trustStore* for the SOAP calls. The changes also allowed us
to key the Encryption of the passwords for all stores and certs.
Remember that this is not an SSLHostConfig configuration in the Connector,
so Tomcat is using its internally created SSLHostConfig.
Thanks for all your help.
Regards,
Timothy
On Wed, Jan 29, 2025 at 4:47 AM Mark Thomas <ma...@apache.org> wrote:
> On 28/01/2025 17:16, Timothy Resh wrote:
> > Chris and Mark,
> >
> > The following properties are set via Introspection and are used by a SOAP
> > call in a hosted Java web app.
> >> System.setProperty("javax.net.ssl.keyStore", keyStorePath);
> >> System.setProperty("javax.net.ssl.keyStorePassword", clearText);
> >> System.setProperty("javax.net.ssl.trustStore", trustStorePath);
> >> System.setProperty("javax.net.ssl.trustStorePassword", clearText);
> >
> > After looking into these system properties, I see they are used by Tomcat
> > in the SSLHostConfig.java
> >
> > private String truststoreFile = System.getProperty("javax.net
> .ssl.trustStore");
> > private String truststorePassword =
> > System.getProperty("javax.net.ssl.trustStorePassword");
> > private String truststoreProvider =
> > System.getProperty("javax.net.ssl.trustStoreProvider");
> > private String truststoreType =
> > System.getProperty("javax.net.ssl.trustStoreType");
>
> Sorry. For reasons I don't understand, Eclipse didn't include those in
> the search results when I went looking. They are documented as the
> defaults in the documentation.
>
> > And for a Default KeyStore File located in the User home directory.
> >
> > static final String DEFAULT_KEYSTORE_PROVIDER =
> > System.getProperty("javax.net.ssl.keyStoreProvider");
> > static final String DEFAULT_KEYSTORE_TYPE =
> > System.getProperty("javax.net.ssl.keyStoreType", "JKS");
> > private static final String DEFAULT_KEYSTORE_FILE =
> > System.getProperty("user.home") + File.separator + ".keystore";
>
> Those were the ones my Eclipse search did find (and again are documented
> as the defaults).
>
> > Could the setting of the javax.new.ssl.* properties impact how you handle
> > the SSLHostConfig and how it determines the _default_?
>
> The defaults will be used unless the Connector explicitly configures a
> value.
>
> > In my current
> > server.xml config we use
> > keystoreType="PKCS12"
> > SSLPassword="${KSENC(6qXemkaMkIOCflnMN4pErQ==; C:\Tomcat
> > Applications\Certificate\Keystore\Tomcat SAMM Vessel.p12)}"
> > SSLCertificateChainFile="C:\Vol1\SMIS_APP\Certificates\CA\
> intermediate.ca"
> > SSLCertificateFile="C:\Tomcat Applications\Certificate\Public
> > Key\WSD-2DNX4M3.EmpriseCorporation.com.cer"
> > SSLCertificateKeyFile="C:\Tomcat Applications\Certificate\Private
> > Key\WSD-2DNX4M3.EmpriseCorporation.com.key"
> > SSLVerifyClient="optional"
> > SSLCACertificateFile="C:\Vol1\SMIS_APP\Certificates\CA\intermediate.ca"
> > SSLCACertificatePath="C:\Vol1\SMIS_APP\Certificates\CA\"
> >
> > I want to ensure I do not get the configuration mismatched when tomcat
> > creates the _default_ SSLHostConfig, as we need those "java.net.ssl.*"
> > properties set for the SOAP call.
>
> Explicitly set everything in the Connector. Don't rely on the system
> properties.
>
> > Is there another way to set that java.net.ssl.* properties per webapp for
> > the SOAP call?
>
> No. System properties are JVM wide - which is why they are such a bad
> choice for TLS configuration. If you have different web applications
> that need different system property values you will need to run them in
> separate Tomcat instances.
>
> Mark
>
>
> >
> >
> >
> > On Wed, Jan 22, 2025 at 12:20 PM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> >> Thomas,
> >>
> >> On 1/21/25 2:08 PM, Timothy Resh wrote:
> >>> In the old configuration we were able to hide the password using the
> >>> following parameter in the config
> >>>
> >>> SSLPassword="${KSENC(6qXemkaMkIOCflnMN4pErQ==;
> >>> C:\\Certificate\Keystore\Tomcat SAMM Vessel.p12)}"
> >>>
> >>> We then used this
> >>>
> >>
> org.apache.tomcat.util.digester.PROPERTY_SOURCE=com.emprisecorp.tomcat.propertysource.MyPropertySource
> >>>
> >>> in the catalina.properties. This class would set the following
> properties
> >>> when it decrypted the KSENC(6qXemkaMkIOCflnMN4pErQ==;
> >>>
> >>> System.setProperty("javax.net.ssl.keyStore", keyStorePath);
> >>> System.setProperty("javax.net.ssl.keyStorePassword", clearText);
> >>> System.setProperty("javax.net.ssl.trustStore", trustStorePath);
> >>> System.setProperty("javax.net.ssl.trustStorePassword", clearText);
> >>
> >> As Mark says in his reply, this won't work since Tomcat doesn't use
> >> those system properties. I would argue that using system properties for
> >> this kind of thing is a terrible idea, which is why they were only used
> >> as defaults, overridable with explicit configuration in server.xml.
> >>
> >> You should have a look at the ServiceBindingPropertySource[1] which may
> >> be able to move the problem to other files. It certainly will get your
> >> secrets out of server.xml. There is also Vault for Tomcat[2], which I
> >> have never used but is at least partially maintained by some Tomcat
> >> committers (but now an ASF project).
> >>
> >> -chris
> >>
> >> [1]
> >>
> >>
> https://tomcat.apache.org/tomcat-9.0-doc/config/systemprops.html#Property_replacements
> >>
> >> [2] https://github.com/web-servers/tomcat-vault/tree/main
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
>
