Skip to content
Thirdlane

SIP Encryption (TLS)

Phones and SIP trunks normally send their signaling in the clear: who is calling whom, the credentials they log in with, and the messages that set up and tear down each call. This screen lets them send that signaling over TLS (Transport Layer Security) instead, which is the same encryption a browser uses for HTTPS. It is where you turn encrypted SIP on and where you tell the server which certificate to present.

This screen covers SIP signaling only. The web interface and Thirdlane Connect are served by a separate component using the certificate configured under Domain and SSL Certificate, and nothing here affects them. Encrypting the audio is a third, separate setting: see the Encryption option on Trunks for SRTP. Signaling and media encryption are normally used together.

Why you would want it

Without TLS, anyone able to observe the network between a phone and the server can read the SIP messages. That exposes the extension’s SIP password, which is enough to register a device of their own and place calls on your account, and it exposes the call detail of every call the phone makes. On a local network under your control this may be an acceptable risk; for any phone or softphone that connects across the public Internet it is not.

TLS also gives the phone a way to confirm it is talking to your server rather than to something in between, because the phone checks the certificate the server presents.

How it works

When a phone opens a TLS connection, the server presents a certificate. The phone checks two things: that the certificate was issued by a certificate authority it already trusts, and that the name on the certificate matches the host name the phone was configured to dial. If either check fails the phone refuses to connect. A certificate for pbx.example.com will not satisfy a phone configured to reach sip.example.com, even when both names point at the same server.

A certificate covers its main name plus every name listed on it as an additional name. Names added under Subdomains in Domain and SSL Certificate are included on the certificate, so a phone dialing a subdomain works without a second certificate.

Where the certificate comes from

Almost always the certificate that already serves the web interface covers the name phones dial as well, so there is no reason to obtain or install a second one. Certificate Source therefore offers two choices:

  • Use the domain certificate - the normal choice. The platform copies that certificate into place for encrypted SIP and copies it again every time it changes, whether it was renewed automatically by Let’s Encrypt or replaced by hand. Nothing expires behind your back.
  • Upload a certificate here - for the case where SIP genuinely needs a different certificate from the web interface. This copy is a snapshot: it is never updated for you, and it is your responsibility to replace it before it expires.

When more than one host name is configured under Domain and SSL Certificate, a Certificate From list appears so you can choose which one. Systems with a single host name have nothing to choose and the list is hidden.

Enabling TLS takes two settings on two screens

Turning on Enable SIP TLS here activates the TLS feature and loads the certificate, but it does not by itself open a port. The TLS port is opened per network interface, under Network Topology. Both are needed:

  1. Enable SIP TLS on this screen, with a certificate configured.
  2. TLS enabled on at least one network interface in Network Topology.

If only the first is done, everything on this screen looks correct and no phone can connect, because there is no port listening. The Certificate In Use block on this screen says so explicitly when that is the case, so check it after saving.

What happens when a certificate is renewed

A renewed certificate is written into place and the SIP service is told to re-read it. Calls in progress and registered phones are not disconnected. Connections that are already open keep using the previous certificate until they close and reconnect, which is harmless: Let’s Encrypt renews roughly 30 days before expiry, so the old certificate is still valid while long-lived registrations roll over. If the service cannot re-read the certificate for some reason, it is restarted instead, so the new certificate always takes effect.

Turning Enable SIP TLS on or off is different, and does restart the SIP service, briefly dropping registrations and calls in progress. This is because loading the TLS module and opening the TLS port can only happen when the service starts. Plan that change for a quiet period; a certificate renewal needs no such planning.

How to set it up

  1. Confirm the name your phones will dial is configured under Domain and SSL Certificate, either as the main host name or as a subdomain. For example, if phones are provisioned to reach sip.example.com, that name must be on the certificate.
  2. On this screen, tick Enable SIP TLS.
  3. Leave Certificate Source set to Use the domain certificate. On a system with several host names, pick the right one under Certificate From.
  4. Choose Endpoint TLS Connection Options. Accept only TLSv1.2 Connections is the right answer unless a specific older phone cannot manage it.
  5. Save. The Certificate In Use block now shows the certificate name, any additional names it covers, and its expiry date.
  6. Go to Network Topology and enable TLS on the network interface phones reach the server through, then save. This restarts the SIP service.
  7. Provision a phone for TLS on the SIP TLS port (5061 unless it has been changed on the server) and confirm it registers.

Settings

Enable SIP TLS. Accepts encrypted SIP signaling on the TLS port. Changing this restarts the SIP service.

Endpoint TLS Connection Options. Which TLS versions the server will accept. TLS 1.0 and 1.1 have known weaknesses and are offered only for legacy devices:

  • Accept only TLSv1.2 Connections
  • Accept TLSv1.1 or Newer Connections
  • Accept only TLSv1.1 Connections
  • Accept TLSv1.0 or Newer Connections
  • Accept only TLSv1 (TLSv1.0) Connections

Certificate Source. Whether to reuse the domain certificate or upload one specifically for SIP.

Certificate From. Which configured host name’s certificate to reuse. Shown only when more than one host name exists.

Certificate In Use. Read-only. The certificate the server is currently presenting on the TLS port, the additional names it covers, when it expires, where it came from, and a warning if no TLS port is open.

Certificate, Private Key, Root Certificate. Shown only when Certificate Source is set to upload. Paste the certificate the server should present, the private key that matches it, and the certificate authority chain that signed it. Keep the private key secret - anyone holding it can impersonate your server.

Require Certificate. Refuses a TLS connection from a phone or trunk that does not present a certificate of its own. This is mutual TLS, and it only works if every device that connects has been issued a client certificate; otherwise devices that were working stop connecting. Leave it off unless you have provisioned client certificates deliberately.

Verify Certificate. Checks the certificate a connecting phone or trunk presents against the Root Certificate and rejects it if it does not match. This requires a root certificate to check against - with none available, every TLS connection is refused. The screen will not let you save this combination.

Operating it

Checking what is being served. The Certificate In Use block reports the certificate the server actually has loaded, read from the file the SIP service uses, not from the configuration you saved. If a reused certificate could not be copied for some reason, the block shows the certificate still in place rather than the one you intended, and saving reports the reason.

Renewals. Nothing to do. A renewed certificate reaches encrypted SIP within the same run that updates the web interface.

Replacing a commercial certificate. Replace it once, under Domain and SSL Certificate. The copy used for encrypted SIP is updated at the same time. This is worth knowing because a commercial certificate is typically replaced once a year, and before this was automatic it was easy to update the web certificate and leave encrypted SIP presenting last year’s.

Deleting a host name. A host name whose certificate is in use for encrypted SIP cannot be deleted under Domain and SSL Certificate. Change Certificate Source here first.

Phones that will not connect over TLS. Check in this order: that a TLS port is open (the Certificate In Use block says if it is not), that the name the phone dials appears among the names the certificate covers, and that the phone trusts the issuing authority. The third is the one that catches older desk phones: their built-in list of trusted authorities may predate the current Let’s Encrypt roots, and a firmware update or a manually loaded root certificate is the fix. Because Let’s Encrypt certificates rotate every 90 days, a phone with a stale trust list tends to reveal itself sooner than it would with a certificate that lasts a year.

Microsoft Teams uses a different certificate

Microsoft Teams Direct Routing has its own screen and its own certificate, and it does not read anything from this one. It cannot reuse the domain certificate, and it cannot use a Let’s Encrypt certificate at all: Teams requires the SBC to present a client certificate to Microsoft, which needs a specific capability (the Client Authentication extended key usage) that Let’s Encrypt stopped issuing in 2026. A Teams SBC certificate must be purchased from a commercial certificate authority and pasted in on the Microsoft Teams screen.

Best practices

  • Choose TLS 1.2 or newer. Enable the older options only for a device that has been shown to need them, and replace that device when you can.
  • Reuse the domain certificate unless you have a specific reason not to. It removes the annual replacement task and the class of outage that comes from forgetting it.
  • Encrypt the media too. TLS protects the signaling; without SRTP the conversation itself still travels in the clear. See the Encryption option on Trunks.
  • Test one phone before reprovisioning the fleet. Most first attempts uncover something, usually a name that is not on the certificate or a phone that does not trust the issuing authority.
  • Leave Require Certificate and Verify Certificate off unless you are deliberately running mutual TLS with client certificates issued to every device.