What is the problem this feature will solve?
tls.createServer() accepts a requestCert option that can be used to request client certificates. However, this option does not appear to be configurable through a SecureContext, so it cannot be changed dynamically (e.g., based on the hostname in SNICallback).
In TLS 1.2, tlsSocket.renegotiate() can be used to dynamically request a client certificate after the initial handshake.
TLS 1.3, on the other hand, does not allow this renegotiation. With the current API, I don't see a way of dynamically requesting client certificates in TLS 1.3.
What is the feature you are proposing to solve the problem?
I believe there are two viable approaches to dynamic client certificate requests, both of which should ideally be supported.
- The server should be able to dynamically decide whether to request a client certificate based on the
ClientHello message, similar to how the SNICallback allows dynamic selection of the SecureContext.
- Post-handshake authentication can be enabled by the client and allows the server to request a client certificate after the handshake has been completed. This might need APIs on both sides.
I certainly don't want to add much complexity to the TLS module, nor do I want to bloat it with additional functions that are specific to this TLS version. I also don't know how this would tie in with QUIC.
What alternatives have you considered?
It is possible to manually parse the ClientHello message to dynamically decide which TLS server instance to pass the connection to. This is somewhat difficult to implement though.
What is the problem this feature will solve?
tls.createServer()accepts arequestCertoption that can be used to request client certificates. However, this option does not appear to be configurable through aSecureContext, so it cannot be changed dynamically (e.g., based on the hostname inSNICallback).In TLS 1.2,
tlsSocket.renegotiate()can be used to dynamically request a client certificate after the initial handshake.TLS 1.3, on the other hand, does not allow this renegotiation. With the current API, I don't see a way of dynamically requesting client certificates in TLS 1.3.
What is the feature you are proposing to solve the problem?
I believe there are two viable approaches to dynamic client certificate requests, both of which should ideally be supported.
ClientHellomessage, similar to how theSNICallbackallows dynamic selection of theSecureContext.I certainly don't want to add much complexity to the TLS module, nor do I want to bloat it with additional functions that are specific to this TLS version. I also don't know how this would tie in with QUIC.
What alternatives have you considered?
It is possible to manually parse the
ClientHellomessage to dynamically decide which TLS server instance to pass the connection to. This is somewhat difficult to implement though.