Troubleshooting Teams Direct Routing SIP TLS Handshake Failures and Certificate Trust Chain Errors
Problem
TLS Handshake Failure Overview
Inbound and outbound voice calls between the on-premises Session Border Controller (SBC) and Microsoft Teams Direct Routing fail during the SIP TLS 1.2/1.3 renegotiation or initial transport establishment.
Traffic Flow Impact
The SBC receives TLS alert level: fatal, description: unknown CA or bad certificate from Microsoft SIP proxies (sip.pstnhub.microsoft.com), preventing any SIP INVITE or OPTIONS messages from being processed successfully.

Symptoms
- SIP OPTIONS pings fail with TLS handshake timeouts or immediate TCP RST packets from Microsoft proxies.
- SBC trace logs show TLS errors such as SSL_connect failed: certificate verify failed or fatal alert 48 (unknown CA).
- Teams Admin Center displays the SBC status as Inactive or connection status as Warning/TLS Failed.
- Outbound calls from Teams users fail immediately with SIP 503 Service Unavailable or SIP 504 Server Timeout.
Root cause
Missing or Untrusted Root Certificates
The SBC lacks the required intermediate or root Certification Authority (CA) certificates in its local trust store, making it impossible to validate the remote certificate presented by sip.pstnhub.microsoft.com.
FQDN and SAN Attribute Mismatch
The public certificate installed on the SBC does not contain a valid Subject Alternative Name (SAN) matching the SBC FQDN registered in the Microsoft 365 domain tenant, or the domain has not been fully verified.
Cipher Suite Incompatibility
The SBC TLS profile relies on deprecated cipher suites or lacks forced support for required ECDHE ciphers mandated by Microsoft's Direct Routing TLS posture.
Resolution steps
- step #1
Verifying Domain Registration
Ensure the SBC FQDN (for example,
sbc1.example.com) is registered as a custom domain in the Microsoft 365 Admin Center and verified via DNS TXT records.Checking SBC Assignment
Confirm that the FQDN is added under Teams Admin Center > Voice > Direct Routing and that at least one licensed user in the tenant shares this domain suffix in their User Principal Name (UPN).
powershell# Verify SBC Configuration in Teams Online PowerShell Module Get-CsOnlinePSTNGateway -Identity "sbc1.example.com" | Select-Identity, Enabled, SipSignalingPort, TLSClientCertificateSubjectName - step #2
Certificate SAN Validation
Verify that the SBC public certificate is issued by an approved Microsoft Public CA (such as DigiCert, Sectigo, or Let's Encrypt) and includes the exact SBC FQDN in the Subject Alternative Name (SAN) attribute.
Key Usage Requirements
Inspect the certificate attributes to confirm that Key Usage includes
Digital Signature, Key Enciphermentand Extended Key Usage (EKU) includes bothServer AuthenticationandClient Authentication.bash# Inspect local certificate attributes using OpenSSL openssl x509 -in /etc/ssl/certs/sbc_cert.pem -text -noout | grep -A 2 "Subject Alternative Name" - step #3
Certificate Chain Import
Download the complete issuer chain for Microsoft's SIP proxies and import all root and intermediate CA certificates into the SBC Trusted Root Certificate Store.
Required Microsoft Root CAs
Ensure the SBC trust store contains the following CA certificates:
- DigiCert Global Root G2
- DigiCert Global Root CA
- Baltimore CyberTrust Root
bash# Combine root and intermediate certs into a single trust bundle if required by SBC cat DigiCertGlobalRootG2.crt DigiCertGlobalRootCA.crt BaltimoreCyberTrustRoot.crt > /etc/ssl/certs/teams_trust_chain.pem - step #4
Cipher Suite Configuration
Configure the SBC TLS profile to strictly enforce TLS 1.2 or TLS 1.3 and enable required ECDHE cipher suites.
Mandatory Ciphers
Ensure the SBC TLS crypto profile permits the following suites:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
text# Example AudioCodes Mediant SBC CLI Command configure voip tls-context Default supported-tls-versions tls1.2 cipher-suite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 activate exit - step #5
OpenSSL Handshake Verification
Run an explicit OpenSSL handshake test from the SBC shell or an adjacent network interface to test certificate validation against Microsoft Direct Routing.
Verification Output
Verify that the output displays
Verify return code: 0 (ok)at the end of the handshake sequence.bashopenssl s_client -connect sip.pstnhub.microsoft.com:5061 \ -CAfile /etc/ssl/certs/teams_trust_chain.pem \ -cert /etc/ssl/certs/sbc_cert.pem \ -key /etc/ssl/certs/sbc_private.key \ -tls1_2 -showcerts - step #6
Monitoring SIP OPTIONS Engine
Monitor the SBC SIP engine logs to ensure outgoing
OPTIONSpings sent tosip.pstnhub.microsoft.com:5061receive200 OKresponses.Health Check Validation
Check the Teams Admin Center Direct Routing status page to confirm that the SBC status updates to Active and TLS connectivity turns green.
bash# Example Ribbons/Sonus SBC Log Search Command for TLS/SIP Status show table signaling-group SIP_SG_TEAMS status
Verification evidence
Packet Capture Analysis
A network packet capture on port 5061 shows the SBC sending a Client Hello, followed by Microsoft's Server Hello and Certificate exchange, ending immediately with a TLS Alert (Fatal, Unknown CA) issued by either endpoint.
OpenSSL CLI Diagnostics
Running the openssl s_client diagnostic command towards Microsoft's SIP proxy demonstrates validation failure with Verify return code: 20 (unable to get local issuer certificate).
