<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<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"><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">www.opensips-solutions.com</a> | <a class="moz-txt-link-abbreviated" href="http://www.siphub.com">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">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">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">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">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" 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>