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
