[FEATURE] TLS client_domain without certificate

[rsmck]

Is your feature request related to a problem? Please describe.

We currently use the same certificate for Client Auth and Server Auth (commonly done) however given impending changes to TLS certificates most publicly trusted certificates will lose their clientAuth EKU soon (see https://keytalk.com/news/client-authentication-eku-phased-out)

OpenSIPS requires a certificate when configuring a client_domain, even if mTLS is not required. As a result it's easiest to use the server certificate. However, this means that OpenSIPS will send this certificate (without a clientAuth EKU) if the server requests a client certificate.

Describe the solution you'd like

It should be possible to establish the connection without the Client Certificate (see RFC 8446 4.4.2.4 and RFC 5426 7.4.6 ("If no suitable certificate is available, the client MUST send a certificate message containing no certificates. That is, the certificate_list structure has a length of zero")

I would suggest that it should be valid to set certificate and private_key to NULL in tls_mgm where type = 2 (client) and that this should sent a certificate message as described above.

Implementation

• Component: proto_tls or tls_mgm?
• Type: Change to existing behaviour
• Name: Allow null certificate and private_key in client domains

Describe alternatives you've considered

Generating publicly-trusted TLS certificates with the clientAuth EKU will be impossible soon, as any public CA must not include this in issued certificate due to changes to to the Browser Root Program https://www.rsaconference.com/library/blog/sunsetting-the-clientauth-eku-what-why-and-how-to-prepare-for-the-change

Using self-signed certificates (or private CA) is an option, but requires the other party to accept this CA. In testing, this causes problems with some providers.

Additional context

The correct behaviour is not to send a client certificate if one is not required. Some SIP servers do request the client certificate even if they do not require them for authentication, if OpenSIPS then sends a certificate containing only a serverAuth EKU then the session will likely be rejected.

(I appreciate that whilst RFC 5280 Requires that If EKU is present and excludes clientAuth, the certificate MUST NOT be used for TLS client authentication, there doesn't seem to be anything in RFC 5246 or 8446 that I can see to preclude requiring the client to enforce EKU when selecting a certificate to send, so technically it's valid to send a certificate that has only a serverAuth EKU but it will likely be rejected in some cases)

[github-actions]

Any updates here? No progress has been made in the last 15 days, marking as stale. Will close this issue if no further updates are made in the next 30 days.