Skip to content
Thirdlane

Domain and SSL Certificate

This screen is where you register the public hostname users reach the platform by, and install the SSL/TLS certificate that secures those connections. A valid certificate is what makes browsers and apps trust the server and encrypt traffic to it - which is why a domain and matching certificate are required for Thirdlane Connect: Connect uses WebRTC, and browsers refuse to grant microphone and camera access (or open a WebRTC session) over an unsecured connection.

The hostname you set here (for example pbx.example.com) is the name phones, Connect, messaging webhooks, and provisioning use. Other screens fill it in automatically when there is only one.

Why this matters

The domain name and certificate work together. The domain is the hostname users connect to; the certificate cryptographically proves that hostname really is your server and lets clients set up an encrypted channel. If the certificate does not match the hostname users dial, or is expired or untrusted, browsers show security warnings and Connect will not work. The same certificate can also be used to secure SIP signaling over TLS.

A certificate is proof for a specific name. When a browser or phone connects to pbx.example.com, it checks that the certificate is for that name. If you also need HTTPS to work for another name - turn.example.com under a wildcard, pbx1.example.com for a specific machine, or an old name during a rename - that extra name must appear on the certificate. That is what Subdomains is for. Those names make HTTPS succeed when someone types them; they are not a second public identity for the PBX.

Getting a certificate

You can supply your own certificate (from any commercial or internal certificate authority) or have the platform obtain a free one automatically:

  • Bring your own certificate. A CA typically delivers the certificate in one of a few shapes - as separate certificate and private-key files, as a single combined file, or as a certificate chain. Pick the matching Certificate origin option so you paste the parts into the right fields.
  • Request and Install Let’s Encrypt Certificate. If you don’t have a certificate, the platform can request a free one from Let’s Encrypt. Let’s Encrypt certificates are issued and renewed automatically before they expire.

Let’s Encrypt firewall requirements: you must allow outbound TCP 443 to Let’s Encrypt’s servers and have inbound TCP 80 open so Let’s Encrypt can validate the domain. If automatic renewal ever fails, the certificate can be renewed manually.

Create/Edit Domain

Domain. The fully qualified domain name users connect to (for example pbx.example.com). This is the public hostname of the server.

Subdomains. Extra hostnames this certificate covers. For a wildcard certificate, list at least one concrete name (for example turn.example.com) so TURN can use TLS. You can also list an old hostname during a rename, or a machine name such as pbx1.example.com so HTTPS to that box still works.

Certificate origin option. Tells the form how your certificate was provided so it can show the right input fields:

  • Certificate and Private Key in one file - paste one combined file.
  • Certificate and Private Key in separate files - paste the certificate and the private key separately.
  • Certificate Chain - paste the root certificate, intermediate certificate(s), and the server certificate.
  • Request and Install Let’s Encrypt Certificate - obtain a certificate automatically (no pasting required).

Whichever origin option you choose, the platform normalizes your input into the “separate files” format after the domain is saved.

Root Certificate / Intermediate Certificate. The CA chain that vouches for your certificate (shown for the Certificate Chain option), so clients can build a complete trust path.

Certificate. Paste the content of your SSL certificate.

Private Key. Paste the content of the matching private key. Keep this secret - anyone with the private key can impersonate your server.

Private Key Secret. The passphrase protecting the private key, if your key is encrypted. Leave blank for an unencrypted key.

More than one domain row

When the system has one hostname, this screen is the form for that name, its certificate, and Subdomains. The list appears only if more than one domain row already exists, each with its own certificate. That is for the uncommon case where two hostnames cannot share a certificate. New installs do not create a second row; extra names go in Subdomains on the existing domain.

Deleting a hostname removes its certificate and HTTPS vhost, so browsers and providers stop reaching that name. Delete is refused while a messaging gateway, WhatsApp account, click-to-call widget, Provisioning Settings, or SIP Encryption (TLS) still uses that hostname. Point those at the hostname you are keeping, copy the new webhook URL into the provider (Meta, Twilio, and similar), confirm inbound arrives, then delete. Widget HTML already pasted onto a website still contains the old hostname until that snippet is replaced.

Best practices

  • Match the certificate to the exact hostname users dial. A name mismatch causes browser warnings and breaks Connect and TLS SIP registration.
  • Put extra names in Subdomains, on the same certificate, rather than creating a second domain.
  • Include the full chain. Omitting intermediate certificates is a common cause of “untrusted certificate” errors on some clients even when the certificate itself is valid.
  • Prefer Let’s Encrypt for hands-off renewal unless your organization requires a specific commercial CA - automatic renewal removes the risk of a forgotten expiry taking Connect offline.
  • Reuse this certificate for SIP TLS. Once the domain certificate is in place, you can enable SIP Encryption (TLS) so SIP signaling is encrypted with the same trusted name.