Re: Unexpected result of requesting client certificate when requesting locations with different SSLVerifyClient settings

[William A Rowe Jr <wrowe@xxxxxxxxxxxxx>]

On Wed, Apr 10, 2019 at 10:48 AM Du Hao <dwaynedu@xxxxxxxxx> wrote:

I suspect there is a bug involved in the SSL client verification type changing and the re-negotiation flow. While I admit it may be a corner case but the original use case is very crucial to my current user base. I checked the Bug database and there is a similar bug except that is related to TLSv1.3. For browser compatibility, I am currently disabling TLSv1.3, although I am testing with Apache 2.4.38 and OpenSSL 1.1.1b.

I would love to hear any suggestions on an alternative configuration to support my scenario, and thank you very much in advance.

Hello Du Hau,

you probably want to abandon your current approach. With TLSv1.3, which will come to dominate and eliminate earlier TLS protocols, there is no mechanism for renegotiation. The entire site (defined using SNI, server name indication) will need to share a common handshake, the idea of only locking down https://site.example.co/protected/ gets eliminated with this protocol, and with many only TLS's which actively disable renegotiation due to the underlying potential security holes over time.