Mark,
Am 2020-04-15 um 13:44 schrieb Mark Thomas:
> On 15/04/2020 12:06, Osipov, Michael wrote:
>> Folks,
>>
>> is there any way to access the server certififace from a valve which has
>> been used to establish the TLS context? I haven't found an easy way. I
>> don't want to traverse request.getConnector().findSslHostConfigs()
>> because it would make it more complex than necessary or even unreliable,
>> especially when SANs are used.
>>
>> I'd like to evaluate RFC 5929 for the paranoid.
>
> This is fairly easy with a small patch to Tomcat.
>
> The non-specification compliant request attribute
> javax.servlet.request.ssl_session_mgr gives you an instance of
> org.apache.tomcat.util.net.SSLSupport
This sounds promising! I wonder why it uses the javax namespace although
not being part of the Servlet Spec. The commect says that this is an
extension, I'd expect to be in Tomcat namespace.
> If you add a method to that interface. I suggest:
> java.security.cert.Certificate [] getLocalCertificates();
> That is then trivial to implement in JSSESupport.
>
> It is a little more work for AprSLSupport but SSL_INFO_SERVER_CERT
> should get you what you want.
* Why not X509Certificate[] like with #getPeerCertificateChain()?
* Why an array? I don't see SSL_INFO_SERVER_CERT_CHAIN.
* If this is an array, how am I supposed to know which one has been used?
Please don't forget SSL_SERVER_CERT in SSLValve if Tomcat is behind a
proxy. Likely the AJP connector needs to be changed too. (I use
mod_proxy_http only).
I am a bit confused why AjpProcessor still refers to JkCoyoteHandler.
This is likely a leftover.
org.apache.coyote.AbstractProcessor.populateSslRequestAttributes() does
the attributes magic, maybe we can introduce a new attribute to avoid
working with SSLSupport instances directly.
I will file a Bugzilla issue to track this.
Thank you,
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
