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
