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
