On 21/01/2025 19:08, Timothy Resh wrote:
Good afternoon,
If I use this configuration, then the prompts for the client auth work,
where the intermediate.p12 file has all the intermediates from DOD ID CAx
imported. I do not see where the caCertificatePath can be used in this
configuration.
<Connector URIEncoding="UTF-8"
port="8443"
address="192.168.1.151"
connectionTimeout="60000"
maxThreads="300"
maxConnections="300"
protocol="org.apache.coyote.http11.Http11AprProtocol"
enableLookups="false"
scheme="https"
secure="true"
SSLEnabled="true"
keystoreFile="C:\\Certificate\\Keystore\\Tomcat SAMM Vessel.p12"
keystorePass="MyPassword"
keystoreType="PKCS12"
SSLProtocol="TLSv1.2"
SSLCipherSuite="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA"
truststoreFile="C:\\Certificates\\CA\\intermediate.P12"
truststorePass="MyPassword"
truststoreType="PKCS12"
SSLVerifyClient="optional"
/>
OK. That configuration is using the APR/native connector with OpenSSL
providing the TLS implementation and Tomcat's APR/Native connector
providing the I/O.
This must be Tomcat 9 since that is the only currently supported major
version of Tomcat that supports the APR/native connector.
This must be Tomcat Native 1.3 (hopefully 1.3.1) since support for the
APR/Native connector was removed on Tomcat Native 2.x onwards.
The TLS configuration is using JSSE keystores and Tomcat is
automatically converting the data from the JSSE keystore to the format
expected by OpenSSL.
Tomcat allows JSSE or OPenSSL style configuration to be used
independently of whether JSSE or OPenSSL is providing the TLS
implementation. The reason is that it allows users to switch quickly
from one implementation to another without having to convert their
configuration.
There are limits to what can be supported by this conversion as it
depends on Java having implementations of all of the necessary
algorithms. Most (all?) common formats should work. Some of the more
unusual formats may not. If a format doesn't work, the best way to get a
fix (if one is possible) is to open a bug report with a sample key that
doesn't work (obviously, use a test key/cert not a production one).
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
What that does is obfuscate the passwords. I'd argue it isn't any more
secure than storing the passwords in the clear in the configuration
files but it is nice looking security theater that seems to please some
auditors that should know better.
On a practical level, what that does is it intercepts the processing of
the configuration file and replaces the obfuscated value with the clear
value. It will work with any attribute value in server.xml
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);
Tomcat doesn't use those system properties for TLS configuration. The
only system properties Tomcat uses for TLS configuration are
javax.net.ssl.keyStoreProvider
javax.net.ssl.keyStoreType
which provide defaults for certificateKeystoreType and
certificateKeystoreProvider respectively if they aren't set explicitly.
I do not see in the Tomcat 9 documentation that these properties are used
for trustStorePass and keyStorePass. I believe these are aliases for the
above keys.
That is not correct. Older versions (e.g. Tomcat 6) used system
properties for a few more defaults including the trust store and
associated password.
If I use com.emprisecorp.tomcat.propertysource.MyPropertySource
and it sets these keys. Will this force me to JSSE and not OpenSSL,
From a Tomcat perspective, no. You are using OpenSSL already. If you
want to use the OpenSSL configuration style for TLS then you should be
able to switch to that and still use the same process to obfuscate
attribute values in server.xml.
and how does this impact using caCertificatePath?
That an OpenSSL style configuration attribute. You would need to switch
from using JSSE configuration attributes to OpenSSL configuration
attributes for your TLS configuration.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
