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");
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";
Could the setting of the javax.new.ssl.* properties impact how you handle
the SSLHostConfig and how it determines the _default_? 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.
Is there another way to set that java.net.ssl.* properties per webapp for
the SOAP call?
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
>
>
