Situation: Website works with TLS1.2 (and below), not with TLS1.3 Core issue appears to be TLS1.3/HTTP/2's prohibition on renegotiation - now, extending to post_handshake (client) authentication. The httpd documentation still indicates that ths setup should work. Users expect it. The use case seems fairly common: If a user has a certificate, no username/password is required by the applications - and some protected features are enabled based on stronger proof of identity. Casual users don't get a certificate. But only one URL is published. Working with TLS1.2 and below: Global default: SSLVerifyClient none Selected Locations: SSLVerifyClient require (or optional) With TLS1.3: Renegotiation fails. Tried: Global default: SSLVerifyClient optional Selected Locations: require ssl-verify-client Tracing reveals: SSL Library Error: error:14268117:SSL routines:SSL_verify_client_post_handshake:extension not received Firefox and Chrome (at least) claim they can't support it for various reasons: https://bugs.chromium.org/p/chromium/issues/detail?id=911653 https://github.com/httpwg/http-extensions/pull/772 https://tools.ietf.org/html/draft-davidben-http2-tls13-00 As far as I can tell, these postions/proposals mean that 'optional' verification can't work; the applicationi would have to field two different servers (one with 'none' and one with 'required'. And somehow users need to be redirected - e.g. "If you have a certificate, click here" Not appealing to the users. Or to the host - a seoarate host for authentication? Modifying every application's entry page to have such a link and add the logic/state maintenance? With that background: 1) What is the apache/httpd position on this regression? mod_ssl seems to have code to enable post_handshake_auth; OpenSSL as well. But if the clients won't support it... 2) Short of fielding another host and modifying applications, is there anything I can do with current configuration options to make this work? (Sticking with TLS1.2 is not a long-term choice...) Bouncing connections with a redirect from part of the URL space might work - but besides increasing connection times, telling 1/2 the users about this and managing it is not attractive. 3) What can httpd do behind the scenes to make this work without application or (big) configuration changes? Perhaps internally it could generate a redirect to an internal vhost, then pass the connection back after getting a certificate? Configuring a certificate for that purpose would be tolerable. Other possibilities> 4) If the capability really is not salvagable, at a minimum it needs to be formally deprecated, documented, and worked-out alternatives provided -- before TLS 1.2 is outlawed. It would be helpful to understand the roadmap before embarking on "solutions" to this functional regression. Thanks.
If browser vendors are choosing not to make this work by default for HTTP/1.1 as it did for TLS/1.2 that is out of our hands, but I don't think it implies we need to deprecate the functionality in mod_ssl. I agree it is a functional regression which will likely impede adoption of TLS/1.3, and I'm not aware of any workaround other than using a separate vhost for client-cert-auth-protected resources. There is an effort to replace PHA at application layer in HTTP/2 which makes sense technically in the long. But that will require time and effort to implement assume it makes it through standardization and won't benefit HTTP/1.1 users. I assume it will require support from OpenSSL as well - https://tools.ietf.org/html/draft-ietf-httpbis-http2-secondary-certs-03 *** This bug has been marked as a duplicate of bug 62975 ***