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 <[email protected]>
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
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
