Session Border ControllersCommunity-Reported-UnverifiedMicrosoft Teams ยท Direct Routing

Troubleshooting Teams Direct Routing SIP TLS Handshake Failures and Certificate Trust Chain Errors

by Provider Adminlast verified 2026-08-19

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.

Illustration for Troubleshooting Teams Direct Routing SIP TLS Handshake Failures and Certificate Trust Chain Errors

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

  1. 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
  2. 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 Encipherment and Extended Key Usage (EKU) includes both Server Authentication and Client 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"
  3. 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
  4. 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_SHA384
    • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    • TLS_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
  5. 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.

    bash
    openssl 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
  6. step #6

    Monitoring SIP OPTIONS Engine

    Monitor the SBC SIP engine logs to ensure outgoing OPTIONS pings sent to sip.pstnhub.microsoft.com:5061 receive 200 OK responses.

    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).