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

Tue Oct 27 20:33:00 UTC 2026

Hi Liviu

Thanks; I will upgrade to 3.6.9 and re-test the outbound scenario with 
no certificate configured.

Yes, I am having a similar issue with inbound connections. At this stage 
Microsoft has mitigated in that they have changed to DigiCERT 
certificates which, if I recall, has a 1 year validity, which should 
mean that their client certificates still include the clientAuth EKU and 
will remain valid until around this time 2027. There is also Twilio 
using DigiCert that, for the time being, still has the clientAuth EKU, 
but probably won't after their next certificate renewal cycle. I've also 
got incoming connections from other sources (e.g. ElevenLabs) that are 
using LetsEncrypt certificates that have already renewed and don't 
have clientAuth EKU, so those are already a problem. ElevenLabs comes in 
from a ton of random source IP's, so I cannot match them on source IP; I 
had been matching on $tls_peer_subject_cn, however, that's not set when 
one sets verify_cert to 0.

If we allow clients with empty certificates, this at least allow the 
connections to succeed and $tls_peer_verified would (presumably) be 
false and $tls_peer_subject_cn == null; that is a partial fix. If 
possible, it would be great to be able to tell the SSL library (Wolf or 
OpenSSL) to allow (on inbound connections) the client to be successfully 
verified against a certificate lacking a clientAuth EKU (i.e. one using 
a server certificate used as a client certificate), and to 'forgive' the 
lack of clientAuth EKU (without causing verification to fail). It's not 
that this this scenario is likely to be needed for many years, however, 
it seems to be needed for the next year or two as others adapt to this 
industry-wide change.

Regards
*Gregory Massel*

On 2026-10-27 11:50, Liviu Chircu wrote:
>
> 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
>
> _______________________________________________
> 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/7923072d/attachment.html>