Let’s Encrypt removed TLS Client Authentication from its default certificates on 2026-02-11. On 2026-07-08 it retired the temporary tlsclient profile and stopped issuing that usage. A phone that sends no client certificate keeps registering. A carrier that inspects the certificate your switch presents can refuse the trunk. Ask that carrier before you renew.
On MOR, the Class 5 softswitch, the certificate is one file on the proxy. Every TLS destination sees that file, and the path from the proxy to Asterisk stays on UDP. On M4, the Class 4 softswitch, the certificate is the Kamailio pair, and you turn TLS on per origination point and per termination point. TCP port 5061 encrypts the SIP messages. The audio stays on its own SRTP setting.
The expiry email stopped on 2025-06-04. On 2027-02-10 a Let’s Encrypt certificate lasts 64 days, and on 2028-02-16 it lasts 45. The dates are on Let’s Encrypt’s upcoming-features page, updated 2026-07-22. An operator who sells encrypted signaling to a business buyer checks the switch they run, MOR or M4. Class 4 and Class 5 are different jobs.
TLS covers the signaling
SIP TLS encrypts the SIP messages on TCP port 5061. The voice is a second stream. That stream is RTP, and SRTP is the setting that encrypts it. With TLS on and SRTP off, the INVITE is encrypted and the audio is still RTP.
On MOR, a phone that registers to the OpenSIPS proxy uses TLS on 5061. The proxy hands the call to Asterisk over UDP. The Transport line on the device form belongs to the Asterisk channel. Changing that line leaves the proxy listener as it was.
A phone that registers to Asterisk, not to the proxy, uses the Asterisk TLS listener. That listener defaults to 5061, and you can bind another port. The example contains tlsclientmethod=tlsv1. Leave that line out. It locks the handshake to TLS 1.0, and current phones refuse TLS 1.0.
The certificate change
A new Let’s Encrypt certificate from the default profile does not list TLS Client Authentication. After 2026-07-08 there is no tlsclient profile left to request. Let’s Encrypt no longer issues a certificate that contains that extended key usage.
A registering phone and a carrier trunk use your certificate in different ways.
The phone checks the certificate your server presents. It sends no client certificate, so keep tls_verify_client, tls_require_client_certificate, and tls_verify_server at 0. Dropping TLS Client Authentication from that server certificate does not change the phone’s check. The phone has to accept the hostname it registers to, and the CA that signed the file.
On a carrier trunk, your switch opens TLS and presents your certificate. Some far ends on a mutual-TLS trunk look for TLS Client Authentication on that file. Let’s Encrypt will not add that usage to a new certificate. Check with your carrier before you renew.
A Teams Direct Routing certificate raises the same question, and Microsoft’s own page says two different things. On 2026-06-09 an operator asked Let’s Encrypt for the old profile and wrote that inbound PSTN-to-Teams calls had stopped. The replies point at Microsoft’s Direct Routing page. One section on that page says Microsoft SIP endpoints trust SBC certificates that do not include Client Authentication, and that Microsoft will announce a change in advance. An older section, dated 2025-12-12, says Microsoft will require Client Authentication on SBC certificates in the future, and that the Teams SIP interface accepts certificates without it until then. Confirm the rule with Microsoft, or with the carrier who delivers the trunk, before you treat your certificate as accepted.
Microsoft also replaced the certificates on its own SIP interface. The same page says the new CA was in production at the end of July 2026, and that the February 2026 test host is discontinued. Your switch has to accept the certificate Microsoft presents. That trust-store update is separate from the extended key usage on the certificate you send.
Let’s Encrypt stopped expiration emails on 2025-06-04 and deleted the addresses stored on ACME accounts. Put the expiry date on your own calendar.
OpenSIPS TLS on the MOR proxy
The proxy reads three PEM files:
/usr/local/etc/opensips/tls/user/cert.pemis the certificate/usr/local/etc/opensips/tls/user/privkey.pemis the private key/usr/local/etc/opensips/tls/user/calist.pemis the CA chain
The certificate and the private key have to be a pair. An RSA key works. An elliptic-curve key works.
For a certificate you already hold:
/usr/local/sbin/opensips_cert.sh install --cert FILE --key FILE --ca FILE
For Let’s Encrypt, the SIP hostname has to point at this proxy. Port 80 has to be free. If another service holds port 80, add --webroot DIR:
/usr/local/sbin/opensips_cert.sh letsencrypt --domain SIP-HOSTNAME --email ADDRESS
opensips_cert.sh copies the files into the three paths. TLS stays off until you run opensips_tls.sh enable. Pass --restart after that listener is enabled, not before. A later renewal copies the new files and, with TLS already on, restarts OpenSIPS. Choose the hour for that restart.
Turn the listener on:
/usr/local/sbin/opensips_tls.sh enable
opensips_tls.sh enable saves a timestamped copy of the config. It turns on a TLS listener on port 5061 for each address that already listens for UDP, and it opens TLS toward providers whose Transport is tls. You restart OpenSIPS yourself after you open TCP port 5061 on the firewall.
Read the diff against the backup. Open TCP port 5061 on the firewall, then restart:
service opensips restart
To turn the listener off, and to send those providers over UDP again:
/usr/local/sbin/opensips_tls.sh disable
A carrier link on TLS
Asterisk sends that call to the proxy over UDP. After the listener is on, the proxy opens TLS toward a provider whose Transport is tls. While the listener is off, that provider stays on UDP.
Open SETTINGS → Billing → Providers. Set Transport to tls. Set the port to the port the carrier gave you. The usual TLS port is 5061. A port of 0 means the proxy uses 5061.
A provider left on udp stays on UDP. If two providers share a host, the proxy uses the one whose port matches the call, so a UDP provider on that port stays on UDP.
The MOR proxy uses that one certificate for every TLS destination. The file the phones trust is the file the carrier sees. If the carrier requires TLS Client Authentication, a new Let’s Encrypt certificate does not have it, and a second carrier does not get a second file. Ask the carrier what they check. If they require that usage, order the certificate from a CA that still issues it, then confirm the phones will accept the same file.
Place a test call through that provider. Signaling from the proxy to the provider uses TLS. The audio stays on its own SRTP setting.
M4 Kamailio
M4 encrypts SIP on Kamailio. The default port is 5061. The private key and the certificate are one pair for the server. You then allow TLS on each origination point and each termination point that should use it.
The lab commands create a self-signed pair. On the Kamailio server:
cd /usr/src/kamailio/src/modules/tls
make install-tls-cert
That writes /usr/local/etc/kamailio/kamailio-selfsigned.key and /usr/local/etc/kamailio/kamailio-selfsigned.pem. Replace both files when the buyer asked for a public CA.
The settings live in /etc/m2/system.conf. Add the block if it is missing:
kamailio_tls_enabled = 1
kamailio_tls_private_key = /path/to/private.key
kamailio_tls_certificate = /path/to/certificate.crt
kamailio_tls_method = TLSv1.2+
1 turns TLS on in Kamailio and 0 leaves it off. The example sets TLSv1.2+, which accepts TLS 1.2 and anything newer. TLSv1.2 accepts 1.2 alone. TLSv1.3+ accepts TLS 1.3 and anything newer. TLSv1.3 accepts 1.3 alone.
Run the configure script, then restart Kamailio:
/usr/src/m4/kamailio/kamailio_cfg_update.sh
systemctl restart kamailio
On the origination point, enable TLS under advanced authentication settings. On the termination point, set TLS in the signaling settings. A point you leave on UDP stays on UDP.
If that pair comes from Let’s Encrypt, the same dates apply. These two paths are the pair Kamailio loads. Ask each carrier on a TLS termination point whether they look for client authentication.
The check and the renewal date
Run the OpenSIPS check. It prints OpenSIPS TLS is OFF or OpenSIPS TLS is ON. The check does not change the server.
With TLS on, the check reads the listen line, the certificate files, the provider relay, the return path to a TLS phone, and TCP port 5061. Each problem is followed by a FIX line you can run yourself.
Then place the calls. Register a phone to the proxy hostname on port 5061 with transport TLS. Call from the phone, then call back to the phone. The proxy reaches a phone behind NAT on the TLS connection the phone opened when it registered. The Asterisk leg stays on UDP. For a carrier, call out through the provider whose Transport is tls, and take a call in the other direction when that carrier sends you traffic.
On M4, call from the origination point you set to TLS, and call through the termination point you set to TLS. Kamailio has no ON/OFF line in this procedure, so those two calls are the check.
Write the dates on a calendar.
| Date | Change |
|---|---|
| 2025-06-04 | Expiration emails stopped, and the stored ACME addresses were deleted |
| 2026-02-11 | TLS Client Authentication left the default profile |
| 2026-07-08 | The tlsclient profile was retired |
| 2027-02-10 | Lifetime becomes 64 days |
| 2028-02-16 | Lifetime becomes 45 days |
On the OpenSIPS proxy, a Let’s Encrypt renewal copies the new files and restarts OpenSIPS when TLS is already on. Choose the hour for that restart. From 2027-02-10 the certificate lasts 64 days, and from 2028-02-16 it lasts 45.
FAQ
Does a SIP TLS certificate encrypt the audio?
SIP TLS encrypts the SIP messages on port 5061. The audio stays RTP until you enable SRTP. On MOR, the leg from the proxy to Asterisk stays on UDP either way.
Do desk phones fail when client authentication leaves the certificate?
A phone that sends no client certificate has nothing to present. It has to trust the CA and the hostname on the certificate your server presents. If the carrier inspects the certificate you present, ask that carrier.
When do Let’s Encrypt lifetimes get shorter?
64 days on 2027-02-10. 45 days on 2028-02-16. Source: the Let’s Encrypt upcoming-features page, updated 2026-07-22.
Can each carrier have its own certificate?
On the MOR proxy, one certificate goes to every TLS destination. On M4, /etc/m2/system.conf holds one private key and one certificate. You switch TLS on per origination point and per termination point, on that same pair.
Run the check before the lifetime shrinks
Run the OpenSIPS check, or place the M4 test calls, and put 2027-02-10 and 2028-02-16 on a calendar. If a business customer is asking for encrypted signaling and you want that path checked on the server you run, contact Kolmisoft and name MOR or M4.
Check the certificate before 2027
Run the OpenSIPS check or the M4 test calls, and write 2027-02-10 and 2028-02-16 on a calendar. If a business customer wants encrypted signaling, contact Kolmisoft and name MOR or M4.