|Summary:||Expose TLS Certificate and Trusted Authority details through the Manager TLS|
|Product:||Tomcat 9||Reporter:||Nick Burch <apache>|
|Component:||Manager||Assignee:||Tomcat Developers Mailing List <dev>|
Description Nick Burch 2017-09-26 15:41:56 UTC
The Tomcat Manager has a page to display all the configured TLS ciphers It would be nice if it could also show: * What certificate is active for a connector * What certificate authorities, if any, are trusted for a connector At the very least, it'd be good to report the fingerprint and expiry date. Even better would be to show nearly as much as "openssl x509 text" would show, and/or allow downloading of the pem-encoded certificate (The downloading is especially handy for sysadmins used to pem certificates / openssl / gnutls style certificates and tools, fighting with a java keystore. You can get the certificate via openssl s_client or similar, the trusted CAs you can't easily get externally) TBD - If you're in the middle of a graceful deployment of a new certificate for a connector (via JMX or via #61565), should it show details of both certs, or just the latest one? (I don't have a strong feeling either way)
Comment 1 Mark Thomas 2017-10-19 14:33:06 UTC
This doesn't look as if it will be as easy as I'd hoped. While the information is fairly easy to get at for NIO and NIO2, it isn't for APR/native. Additional methods would need to be added to the JNI API and I'm not 100% sure the required information is accessible via the OpenSSL API. Given that it is possible the APR/native connector will be removed in Tomcat 10, just providing this information for NIO and NIO2 could be considered.
Comment 2 Christopher Schultz 2017-10-31 15:40:25 UTC
(In reply to Mark Thomas from comment #1) > Given that it is possible the APR/native connector will be removed in Tomcat > 10, just providing this information for NIO and NIO2 could be considered. +1 Even if the APR connector remains, exposing this information for Java-based connectors is worthwhile. If we get desperate, we can re-read the configuration from the <Connector> and re-load the certificates from the cert store. It won't always be 100% accurate (because you'll be reading the config and not the active cert from memory) but it will get the job done much of the time.
Comment 3 Mark Thomas 2017-12-13 11:35:01 UTC
This has been implemented for connectors that use either the JSSE or OpenSSL implementation that are configured with key stores. Providing the information for OpenSSL style configuration would require changes to Tomcat Native and, as previously stated, I'm not sure OpenSSL exposes the information.
Comment 4 Christopher Schultz 2017-12-13 22:18:06 UTC
(In reply to Mark Thomas from comment #3) > This has been implemented for connectors that use either the JSSE or OpenSSL > implementation that are configured with key stores. > > Providing the information for OpenSSL style configuration would require > changes to Tomcat Native and, as previously stated, I'm not sure OpenSSL > exposes the information. Can you please clarify this? I think the issue is whether the certificate information is available to the Java components instead of coming from native/APR right? So the information should be available to any Java-based connector (NIO, NIO2) regardless of the "configuration style" that is being used, and the APR connector won't report this information (at least, not yet).
Comment 5 Mark Thomas 2017-12-14 11:13:38 UTC
For the feature to work, all of the following must be true: - HTTP connector - NIO or NIO2 implementation - JSSE style TLS configuration (key stores) used It does not work for the HTTP APR/native connector. It does not work if OpenSSL style configuration is used. Whether or not it works is independent of the TLS implementation (JSSE or OpenSSL) used. It does not apply to AJP connectors. The TLS information is extracted during the configuration phase. Hence the configuration style is important. When the OpenSSL configuration style is used, the same information isn't available in the same form at the same point. Rather than extracting it in the right form from OpenSSL (which would require JNI changes) it should be possible to derive it from the configuration files and cache it.