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

Tue Oct 27 09:50:25 UTC 2026

Hi Gregory,

See related below commit on 3.6.5+ and above, fixing GitHub#3798 
<https://github.com/OpenSIPS/opensips/issues/3798>:

commit 93680756b826f9dd69c55c9cba25d98154696204
Author: Ross Henderson <rossmck at mac.com>
Date:   Thu Feb 12 17:01:53 2026 +0000

     tls_mgm: Don't require certificate for TLS clients

     (cherry picked from commit bf9f69f97a7629a078a01d9d14a26f100077daf8)

So this takes a step forward in mitigating the clientAuth EKU sunset on 
the *outbound* side.

However, you seem to be having a similar issue with *inbound* Teams 
connections which also do not include a clientAuth EKU anymore, so the 
tls_wolfssl rejects the TLS Accept.  Did I understand the issue right?

If so, we should definitely make sure our TLS servers (OpenSSL, Wolf) 
are compliant with this new and optional TLS 1.3 client behavior of 
responding to CertificateRequest with an "empty certificate" :-) which 
is fully compliant, of course.  The sooner we add this, the better.

Best regards,

Liviu Chircu
www.opensips-solutions.com |www.siphub.com

On 27/10/2026 11:21, Gregory Massel via Users wrote:
>
> 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.
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20261027/f76446d8/attachment.html>