TLSv1.3 client certificate authentication with renegotiation unsupported in browsers

Bug #1834671 reported by Andreas Hasenack on 2019-06-28
This bug affects 1 person
Affects Status Importance Assigned to Milestone
apache2 (Ubuntu)
Status tracked in Eoan

Bug Description

This is mostly a place holder bug, as more information becomes available.

What is known so far is that a certain configuration of client certificate authentication using TLSv1.3 is not working with most (all at this point?) browsers, resulting in the server returning this error message:


You don't have permission to access / on this server.
Reason: Cannot perform Post-Handshake Authentication.
Apache/2.4.38 (Ubuntu) Server at disco-apache-client-cert.lxd Port 443

It also logs it to error.log:
[Fri Jun 28 16:59:24.596425 2019] [ssl:error] [pid 1391:tid 139642783385344] [client] AH10129: verify client post handshake
[Fri Jun 28 16:59:24.596493 2019] [ssl:error] [pid 1391:tid 139642783385344] [client] AH10158: cannot perform post-handshake authentication
[Fri Jun 28 16:59:24.596513 2019] [ssl:error] [pid 1391:tid 139642783385344] SSL Library Error: error:14268117:SSL routines:SSL_verify_client_post_handshake:extension not received

These are upstream bugs about it:
Apache2 (invalid):

One server workaround is to disable TLSv1.3. Something like this:

SSLProtocol all -SSLv3 -TLSv1.3

("-TLSv1.3" is what was added to that default config)

Sample server config to show the problem (minus the SSL certificate parameters):
<Location />
    SSLVerifyClient require
    Require ssl-verify-client

Another workaround is to move the SSLVerifyClient config to the vhost level. It it applied to the whole vhost, and there are no exceptions in specific blocks, then a re-negotiation isn't triggered and the problem doesn't happen.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers