spring-projects
Tomcat connector logging provide incorrect information about the file path of keystore in SSL info
Spring Boot: 3.5.7
When using Spring Boot's embedded Tomcat with SSL enabled, the SSL certificate keystore file path is logged during startup and hot reload. However, the logged keystore path does not reflect the actual file path configured by Spring Boot.
By default, embedded Tomcat initializes the SSL keystore file path to ${user.home}/.keystore, and although Spring Boot’s SslConnectorCustomizer correctly configures the SSLHostConfigCertificate from the SSLHostConfig, the method SslConnectorCustomizer#applySslBundle still does not configure certificateKeystoreFile property.
This leads to misleading log output like:
Connector [https-jsse-nio-8990], TLS virtual host [_default_], certificate type [UNDEFINED] configured from keystore [/home/app/.keystore] using alias [tomcat] with trust store [/home/app/cacerts]
even when the actual keystore is loaded from class path (e.g. classpath:server.jks) or file location (e.g. file:server.jks).
Expected Behavior
The logged keystore file path should reflect the actual resolved path (or resource location) used to load the certificate. If the keystore is loaded from the classpath or a configured absolute/relative path, that should be reflected accurately in the logs.
Impact
This issue does not affect functionality — SSL works correctly when configured. However, it causes confusion during troubleshooting and monitoring because the logged information is inaccurate.
The Tomcat logging is in https://github.com/apache/tomcat/blob/45192db77a33283b53ff03d715c2a6ffa527ac75/java/org/apache/tomcat/util/net/AbstractEndpoint.java#L436-L448.
I don't think we can set certificateKeystoreFile directly because then Tomcat will try to load it. I wonder if we can null it out or override the log message somehow.
Hopefully, this could be improved in Tomcat.
SSLHostConfigCertificate will only use certificateKeystoreFile if certificateKeystore is null. Ideally, the certificateInfo that's logged by org.apache.tomcat.util.net.AbstractEndpoint.logCertificate(SSLHostConfigCertificate) would reflect this and not even mention a file when the certificate has been directly configured with a KeyStore and hasn't used a file.
WDYT, @markt-asf?
From the December releases Tomcat will report that the KeyStore was set directly and the location is unknown. That should address the issue of misleading information.
What it doesn't provide (which the OP asked for) is the path / resource location where the KeyStore is located since Tomcat has no visibility of that. That would require configuring the KeyStore via certificateKeystoreFile which in turn may require a custom ConfigurationSource depending on where the KeyStore is located.
Thanks, @markt-asf. I believe I'm right in thinking that the alias is always used, irrespective of whether the KeyStore came from a file or direct configuration. If so, looking at the change, accurate information about the alias has been lost. Could that still be included?
The alias logging hasn't been changed. At least it shouldn't have been. What am I missing?
Sorry, I misread the diff. I wrongly thought that the new message was a replacement for the old rather than being part of it.
If we want to log some more information about where the KeyStore's actually come from, we'll need to tackle https://github.com/spring-projects/spring-boot/issues/39057 first. At the moment, the SslBundle doesn't have that information.
Thanks for the offer, @ravxz, but #39057 is pending some design work which means that we won't accept patches for it at this time.
I have a working implementation ready that adds getKeyStoreLocation() and getTrustStoreLocation() methods to SslStoreBundle interface and implements them in JksSslStoreBundle.
However, I understand from the conversation that this is blocked by design work on #39057. I'm happy to wait for the design decisions and then submit a PR, or I can share my implementation for reference if it would be helpful for the design discussion.
My implementation:
- Adds default methods to
SslStoreBundle(backward compatible) - Stores and returns locations in
JksSslStoreBundle - Updates
SslConnectorCustomizerto use the location for Tomcat logging
Let me know if/when you'd like me to proceed with a PR.
With the forthcoming changes in Tomcat, I wonder if we should close this in favor of #39057? I'm not sure that there's much more we can do at the moment.