Am 29. Februar 2020 13:10:13 MEZ schrieb Mark Thomas <>:
>On 29/02/2020 11:23, Michael Osipov wrote:
>> Am 2020-02-29 um 12:13 schrieb Mark Thomas:
>>> On 29/02/2020 11:07, Michael Osipov wrote:
>>>> Am 2020-02-29 um 12:05 schrieb Mark Thomas:
>>>>> On 29/02/2020 10:40, Michael Osipov wrote:
>>> <snip/>
>>>>>> Tomcat does not support renegotiation of TLS contexts based
>>>>>> on URLs like HTTPd.
>>>>> Yes it does.
>>>>> If you specify CLIENT-CERT auth for a sub-set of URLs Tomcat will
>>>>> trigger a renegotiation when one of those URLs is requested.
>>>>> You don't have the same fine-grained control you have in httpd but
>>>>> can replicate the typical use cases.
>>>> Really? If I say require client cert auth on the connector, it will
>>>> enforced even on those contexts which do not require
>>> If you required auth on the connector it always applies.
>>> However, if you don't require it at the connector level you can
>>> it for a subset of URLs with security constraints and Tomcat will
>>> trigger any required renegotiations.
>> Mark,
>> this makes me wonder whether Tomcat properly implements RFC 7540,
>> section 9.2.1 and RFC 8740, section 3. From my understanding the
>> configuration you have described MUST fail here.
>Those aspects of those specs are implemented correctly. Authentication
>will fail for both HTTP/2 and TLS 1.3 if a web application level
>security constraint tries to trigger renegotiation.
>For HTTP/2 and/or TLS 1/3 you can only configure client certificate
>authentication on the Connector.


Oh, I didn't know that. Why exactly is that? Becaus of the multiplexing on 
http2 or something in tls1.3, or asked the oth way around, will it fail only 
for http2 && tls1.3 or for http2 || tls1.3

>To unsubscribe, e-mail:
>For additional commands, e-mail:

Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to