[OpenSIPS-Users] TLS and ending of Client Authentication EKU

[Gregory Massel]

Good day

Most Certificate Authorities have either ceased, or, alternatively, will 
soon be ceasing the inclusion of the Client Authentication EKU in TLS 
server certificates.

e.g. https://letsencrypt.org/2025/05/14/ending-tls-client-authentication

This is creating some challenges for OpenSIPS where mutual TLS is used.

Particularly examples include the use of OpenSIPS to mediate between 
Microsoft PSTNhub (Teams Direct Routing) and regular SIP over UDP 
infrastructure.

While there is the possibility to disable peer certificate verification 
entirely, e.g.

modparam("tls_mgm", "verify_cert", "[dom0]0")
modparam("tls_mgm", "require_cert", "[dom0]0")

This is really not ideal with entities like Microsoft, Twilio, etc. that 
tend to originate connections from a vast number of source IP addresses 
and which don't support Digest Authentication.

I've tried setting require_cert to 0 and verify_cert to 1 for selective 
authentication of some sources via TLS certificate CN and others via 
Digest Auth, however, this doesn't work because WolfSSL drops the TLS 
connection immediately once the certificate fails to verify fully (which 
it won't because of the lack of a Client Authentication EKU) rather then 
accepting the connection and merely setting $tls_peer_verified to false. 
In essence, it's operating almost as if require_cert were set to 1. 
Example logs include:

2026-10-27T10:01:57.087933+02:00 msteams /usr/sbin/opensips[2580517]: ERROR:tls_wolfssl:_wolfssl_tls_accept: New TLS connection from 34.134.27.40:38342 failed to accept
2026-10-27T10:01:57.088018+02:00 msteams /usr/sbin/opensips[2580517]: ERROR:tls_wolfssl:_wolfssl_tls_accept: TLS accept error: -386, Ext Key Use server/client auth not set Error
2026-10-27T10:01:57.088078+02:00 msteams /usr/sbin/opensips[2580517]: ERROR:proto_tls:tls_read_req: failed to do pre-tls handshake!
2026-10-27T10:01:57.088364+02:00 msteams /usr/sbin/opensips[2580531]: ERROR:core:handle_tcp_worker: TCP_DBG - main: received conn 0x7da565c86778 / 1131326017 as faulty (state -1, rfcnt=1)

This raises two questions:

1. Would it be possible to fix this scenario such that, 
where require_cert==0 and verify_cert==1, it accepts the connection but 
sets $tls_peer_verified to false?

2. Would it be possible to implement a configuration in terms of which 
one could tell the TLS library to IGNORE the lack of a Client 
Authentication EKU?

The latter appears to be what Microsoft is doing:

https://learn.microsoft.com/en-us/microsoftteams/direct-routing-whats-new#clarification-on-client-authentication-extended-key-usage-eku


        Clarification on Client Authentication Extended Key Usage (EKU)

    Microsoft SIP endpoints currently trust SBC certificates that don't
    include the Client Authentication Extended Key Usage (EKU). This
    behavior is expected to continue for the foreseeable future. If this
    requirement changes in the future, Microsoft will communicate it in
    advance.

It would be useful if OpenSIPS could support similar behavior, i.e. 
performing Mutual TLS and verifying the peer certificate but 
disregarding the lack of the EKU while performing the verification.


It's also interesting that, when initiating connections to Microsoft, if 
one disables the presentation of a certificate completely (disabling 
Mutual TLS), they reject the connection, yet, if one presents a valid 
signed server certificate that is lacking the Client Authentication EKU, 
they accept that.

This is likely to become a growing problem as the remaining Certificate 
Authorities all end support for the Client Authentication EKU within 
server certificates. Microsoft seem to have only temporarily worked 
around this by switching to DigiCERT CA certificates and renewing in 
October (DigiCert stop this in March 2027) which will give them an extra 
year of validity. Twilio also seem to have a similar approach.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20261027/01c2cce7/attachment.html>