<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Liviu</p>
<p>Thanks; I will upgrade to 3.6.9 and re-test the outbound scenario
with no certificate configured.</p>
<p>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.</p>
<p>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.</p>
<div class="moz-signature"><span
style="font-size:11.0pt;font-family:Assistant;color:black">Regards<br>
</span><span
style="font-size:11pt;font-family:Assistant;color:#44546A"><b>Gregory
Massel</b></span></div>
<div class="moz-signature"><br>
</div>
<div class="moz-signature">On 2026-10-27 11:50, Liviu Chircu wrote:<br>
</div>
<blockquote type="cite"
cite="mid:4c0a0aa5-afa4-4b1c-9373-16d849dd51ca@opensips.org">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p><font face="monospace">Hi Gregory,</font></p>
<p><font face="monospace">See related below commit on 3.6.5+ and
above, fixing <a moz-do-not-send="true"
href="https://github.com/OpenSIPS/opensips/issues/3798">GitHub#3798</a>:</font></p>
<p><font face="monospace">commit
93680756b826f9dd69c55c9cba25d98154696204<br>
Author: Ross Henderson <a class="moz-txt-link-rfc2396E"
href="mailto:rossmck@mac.com" moz-do-not-send="true"><rossmck@mac.com></a><br>
Date: Thu Feb 12 17:01:53 2026 +0000<br>
<br>
tls_mgm: Don't require certificate for TLS clients<br>
<br>
(cherry picked from commit
bf9f69f97a7629a078a01d9d14a26f100077daf8)</font></p>
<p><font face="monospace">So this takes a step forward in
mitigating the clientAuth EKU sunset on the <b>outbound</b> side.</font></p>
<p><font face="monospace">However, you seem to be having a similar
issue with <b>inbound</b> 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?</font></p>
<p><font face="monospace">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.</font></p>
<p><font face="monospace">Best regards,</font></p>
<pre class="moz-signature" cols="72">Liviu Chircu
<a class="moz-txt-link-abbreviated"
href="http://www.opensips-solutions.com" moz-do-not-send="true">www.opensips-solutions.com</a> | <a
class="moz-txt-link-abbreviated" href="http://www.siphub.com"
moz-do-not-send="true">www.siphub.com</a></pre>
<div class="moz-cite-prefix">On 27/10/2026 11:21, Gregory Massel
via Users wrote:<br>
</div>
<blockquote type="cite"
cite="mid:60429156-0b94-485b-9b29-cfc227794422@switchtel.co.za">
<meta http-equiv="content-type"
content="text/html; charset=UTF-8">
<p>Good day</p>
<p>Most Certificate Authorities have either ceased, or,
alternatively, will soon be ceasing the inclusion of the
Client Authentication EKU in TLS server certificates.</p>
<p>e.g. <a moz-do-not-send="true"
href="https://letsencrypt.org/2025/05/14/ending-tls-client-authentication"
class="moz-txt-link-freetext">https://letsencrypt.org/2025/05/14/ending-tls-client-authentication</a></p>
<p>This is creating some challenges for OpenSIPS where mutual
TLS is used.</p>
<p>Particularly examples include the use of OpenSIPS to mediate
between Microsoft PSTNhub (Teams Direct Routing) and regular
SIP over UDP infrastructure.</p>
<p>While there is the possibility to disable peer certificate
verification entirely, e.g.</p>
<p>modparam("tls_mgm", "verify_cert", "[dom0]0")<br>
modparam("tls_mgm", "require_cert", "[dom0]0")</p>
<p>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.</p>
<p>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:</p>
<pre>2026-10-27T10:01:57.087933+02:00 msteams /usr/sbin/opensips[2580517]: <a
class="moz-txt-link-freetext"
href="ERROR:tls_wolfssl:_wolfssl_tls_accept"
moz-do-not-send="true">ERROR:tls_wolfssl:_wolfssl_tls_accept</a>: 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]: <a
class="moz-txt-link-freetext"
href="ERROR:tls_wolfssl:_wolfssl_tls_accept"
moz-do-not-send="true">ERROR:tls_wolfssl:_wolfssl_tls_accept</a>: 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]: <a
class="moz-txt-link-freetext"
href="ERROR:proto_tls:tls_read_req" moz-do-not-send="true">ERROR:proto_tls:tls_read_req</a>: failed to do pre-tls handshake!
2026-10-27T10:01:57.088364+02:00 msteams /usr/sbin/opensips[2580531]: <a
class="moz-txt-link-freetext"
href="ERROR:core:handle_tcp_worker" moz-do-not-send="true">ERROR:core:handle_tcp_worker</a>: TCP_DBG - main: received conn 0x7da565c86778 / 1131326017 as faulty (state -1, rfcnt=1)</pre>
<p>This raises two questions:</p>
<p>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?</p>
<p>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?</p>
<p>The latter appears to be what Microsoft is doing:</p>
<p><a moz-do-not-send="true"
href="https://learn.microsoft.com/en-us/microsoftteams/direct-routing-whats-new#clarification-on-client-authentication-extended-key-usage-eku"
class="moz-txt-link-freetext">https://learn.microsoft.com/en-us/microsoftteams/direct-routing-whats-new#clarification-on-client-authentication-extended-key-usage-eku</a></p>
<blockquote>
<div class="heading-wrapper" data-heading-level="h2">
<h2
id="clarification-on-client-authentication-extended-key-usage-eku"
class="heading-anchor">Clarification on Client
Authentication Extended Key Usage (EKU)</h2>
</div>
<p>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.</p>
</blockquote>
<p>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.</p>
<p><br>
</p>
<p>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.</p>
<p>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.</p>
<p><br>
</p>
<p><br>
</p>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre wrap="" class="moz-quote-pre">_______________________________________________
Users mailing list
<a class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:Users@lists.opensips.org" moz-do-not-send="true">Users@lists.opensips.org</a>
<a class="moz-txt-link-freetext"
href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users"
moz-do-not-send="true">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
</pre>
</blockquote>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre wrap="" class="moz-quote-pre">_______________________________________________
Users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
</pre>
</blockquote>
</body>
</html>