Delayed certificate in TLS 1.3

Question

In ASP.NET Core there are 4 available certificate modes:

        // Summary:
        //     A client certificate is not required and will not be requested from clients.
        NoCertificate,
        
        // Summary:
        //     A client certificate will be requested; however, authentication will not fail
        //     if a certificate is not provided by the client.
        AllowCertificate,
        
        // Summary:
        //     A client certificate will be requested, and the client must provide a valid certificate
        //     for authentication to succeed.
        RequireCertificate,
        
        // Summary:
        //     A client certificate is not required and will not be requested from clients at
        //     the start of the connection. It may be requested by the application later.
        DelayCertificate

I want to use DelayCertificate mode because this shouldn't ask for certificate to user in e.g. web explorer, but still I can require certificate on some endpoints. But I have one consideration: It seems to me that I once read that delayed certificates aren't supported in TLS 1.3. I'm not sure about it, and I can't find the source where I read this. So what's it like with this mode? Will it work with TLS 1.3?

score 2 · Accepted Answer · answered Sep 03 '22 at 09:15

... I once read that delayed certificates aren't supported in TLS 1.3

In TLS 1.2 and lower renegotiation was used to ask for client certificates after the initial TLS handshake was already done. This mechanism does not exist in TLS 1.3 anymore, which means it also cannot be used for delayed client certificates anymore in TLS 1.3.

But, TLS 1.3 introduced a different mechanism for this purpose: Post-Handshake Client Authentication. Thus, delayed client certificates can still work with TLS 1.3, only differently. But it requires that the client supports it and not all might do.

Additionally TLS 1.3 post-handshake client authentication is explicitly forbidden in HTTP/2 - see RFC 8740. But similar to this delaying client certificates in response to access to a protected resource weren't allowed with TLS 1.2 in HTTP/2 either: RFC 7540 explicitly forbids renegotiation after the actual HTTP/2 protocol (inside the TLS) has been started.

Delayed certificate in TLS 1.3

1 Answers1