<!DOCTYPE html>
<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <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]: 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)</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>
  </body>
</html>