Teams Direct Routing TLS handshake failure: Ribbon Edge cipher suite mismatch

SBC integration errorsMANUAL FIX INSIDEFREE — NO SIGNUP
Quick answer. Microsoft Teams Direct Routing requires TLS 1.2 with modern ECDHE cipher suites (AES-GCM); if the SBC's TLS profile was configured in a CBC-only or TLS 1.0-era default, the handshake dies immediately. The alert you see (handshake_failure, alert 40) is the SBC and Microsoft failing to agree on a cipher — a configuration mismatch, not a network or certificate problem, which is why the same SBC works fine for older SIP peers. The fix is to enable TLS 1.2 with ECDHE-RSA-AES256-GCM-SHA384 and ECDHE-RSA-AES128-GCM-SHA256 on the Teams-facing TLS profile and verify with openssl before touching anything else.

The raw code check

Run this before you change anything — it confirms the root cause in one pass:

openssl — CBC-only profile failsFAIL
$ openssl s_client -connect sip.pstnhub.microsoft.com:5061 -tls1_2 \
-cipher AES256-SHA
alert handshake_failure (40)
no shared cipher between Ribbon TLS profile and MS edge
openssl — ECDHE-GCM profile succeedsOK
$ openssl s_client -connect sip.pstnhub.microsoft.com:5061 -tls1_2 \
-cipher ECDHE-RSA-AES256-GCM-SHA384
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Verify return code: 0 (ok)

The manual fix — 3 steps

  1. Confirm the failure is the cipher, not the cert. From a machine on the SBC's network, run the two openssl s_client checks above. If the ECDHE-GCM attempt succeeds while the CBC attempt fails, the network path and certificate chain are fine and the TLS profile on the Ribbon Edge is the problem.
  2. Enable TLS 1.2 + ECDHE-GCM suites on the Teams-facing profile. In the Ribbon Edge TLS profile used for Direct Routing, enable TLS 1.2 and add ECDHE-RSA-AES256-GCM-SHA384 and ECDHE-RSA-AES128-GCM-SHA256 to the cipher list. You can leave the CBC suites enabled for legacy peers — the point is that the GCM suites must be offered, not that the old ones must go.
  3. Restart the TLS listener and verify. Restart the TLS listener so the profile reloads, then re-run the successful openssl check from step 1 and watch the Ribbon register to Direct Routing. The handshake_failure alert should be gone on the next capture — drag that capture through a ladder diagram and both legs should show green.

The automated alternative

If you'd rather never do this again: VoipFlow runs this whole class of maintenance as software — certificate issue-and-bind in about 12 seconds, signaling on port 5062 so SIP ALG rewriting never engages, per-tenant isolation, flat $399/mo. The 14-day sandbox is free, no credit card, and no sales follow-up unless you ask for one.

Deploy Free 14-Day Sandbox — No Credit Card Required

Related