Trusted CA certificates on the SIP FE/SBC's for TLS

Telephony
1

I’m trying to better understand which trusted Certificate Authority (CA) certificates are installed on the SIP FE/SBC (LiveKit).

Currently, I’m encountering an issue with SIP REFER requests when using transport=tls on the proxy address. These requests are failing with a 408 Request Timeout. My assumption is that the timeout occurs because the SIP FE/SBC is unable to establish a TLS session, likely due to failing certificate validation against an untrusted CA.

The certificates I’m testing with are issued by Let’s Encrypt and include the ISRG root in the chain. When I switch the transport back to UDP, the SIP REFER requests complete successfully, but of course this removes encryption in transit.

Thinking about this some more, I will also collect a tcpdump on the ingress interface and look for a SSL ClientHello message from your SIP FE/SBC too and check for traffic too.

Could you provide guidance on where I can find the list of trusted CA certificates used by your SBCs? I haven’t been able to locate any documentation on this.

I also noticed that your SBCs appear to use certificates issued by ZeroSSL. As part of troubleshooting, I’m considering switching to ZeroSSL-issued certificates for my internal testing to see if that resolves the issue.

Thanks in advance.

2

LiveKit Cloud’s SIP SBC uses a standard, publicly trusted root CA bundle for TLS validation. There isn’t a published static list of individual trusted CAs, but certificates issued by widely trusted public authorities (such as Let’s Encrypt) are supported, provided the full chain is presented and the certificate is valid for the FQDN being used.

For TLS transport and SRTP requirements, see Secure trunking.

A 408 on SIP REFER over TLS typically indicates the TLS handshake or TCP connection is not completing (for example, failed certificate validation, SNI mismatch, or firewall issues). When you run tcpdump, do you see a TCP 3‑way handshake followed by a ClientHello from the LiveKit SBC, or does the connection fail before TLS negotiation begins?