SIP TLS handshake failures on trunks
Verified 2026-09-25 · 60 sources · tier 1–2 · 5 disputed · 1 superseded
Session Initiation Protocol (SIP) trunks secured by Transport Layer Security (TLS) rely on mutual validation of certificates, ciphers, and protocol versions 2750. Handshake failures immediately terminate the connection and halt SIP signaling before application-layer transactions such as SIP OPTIONS or call setup can begin 31.
Handshake Mechanics and Protocol Rules
During trunk setup, the Session Border Controller (SBC) initiates the TLS connection to the SIP proxy Fully Qualified Domain Name (FQDN) on port 5061 and presents its certificate 3132. If the proxy judges the request invalid, it closes the TLS connection without receiving SIP OPTIONS from the SBC 31. SIP signaling traffic from the proxy to the SBC uses whichever port is configured on the SBC 32.
RFC 8996 (BCP 195) says TLS 1.0 and TLS 1.1 must not be used or negotiated, and it updates RFC 3261 so SIP's minimum becomes TLS 1.2 52. For Teams Direct Routing, Microsoft's troubleshooting guidance specifies that if the connection closes immediately and no SIP OPTIONS arrive from the SBC, the SBC should be configured for TLS 1.2 or higher 23. Azure Communication Services (ACS) direct routing supports only TLS 1.2 for SBC signaling 3. Webex Calling supports both TLS 1.2 and TLS 1.3 for secure SIP, using port 5061 discovered via a _sips._tcp DNS SRV lookup 6058.
TLS alert codes identify the specific point of failure:
- Alert 40 (
handshake_failure) indicates that the sender could not negotiate an acceptable set of security parameters from the offered options 50. - Alert 42 (
bad_certificate), 43 (unsupported_certificate), 44 (certificate_revoked), 45 (certificate_expired, also sent for not-yet-valid certificates), 46 (certificate_unknown), and 48 (unknown_ca, for chains that cannot anchor to a trusted CA) indicate specific certificate verification issues 48. - Alert 70 (
protocol_version) signals an unsupported version, alert 71 (insufficient_security) indicates weak parameters, and alert 116 (certificate_required) is sent in TLS 1.3 when a server requires a client certificate but receives none 51.
Certificate Validation and Domain Identity
RFC 5922 establishes domain identity rules for SIP by taking identity from the certificate's subjectAltName (SAN)—either a URI with a sip scheme and no userinfo, or a DNS name—and permits inspecting the Common Name (CN) only if no SAN is present 47. RFC 5922 strictly forbids SIP implementations from matching any form of wildcard in a domain certificate 46. WarmTransfer's reading of the sources is that a wildcard SBC certificate accepted under RFC 2818 rules by Teams Direct Routing may still be rejected by a SIP peer validating strictly under RFC 5922, meaning success toward Microsoft provides no assurance of interoperability on a carrier or PBX trunk 3854.
Within Microsoft Teams Direct Routing, wildcard certificates comply with RFC 2818 but cover only a single label: *.contoso.com matches sbc1.contoso.com but not customer10.sbc1.contoso.com 3738. Direct Routing rejects self-signed certificates outright; certificates must be issued by a CA in the Microsoft Trusted Root Program, carry the SBC FQDN in the CN or SAN, belong to a Microsoft 365 tenant domain, and include the Server Authentication Extended Key Usage (EKU) 3418.
Microsoft SIP endpoints do not require the Client Authentication EKU and accept certificates without it, expecting to maintain this policy for the foreseeable future with advance notice of changes 22. However, Microsoft warns that certain SBCs and TLS libraries refuse to establish outbound connections using a client certificate missing the Client Authentication EKU 21. Sources disagree on the timeline and scope of external policy deprecating combined EKUs: Microsoft reports that Google Chrome Root Program Policy v1.6 (February 2025) deprecates the Client Authentication EKU on server certificates and mandates Server Authentication only from June 2026 44, whereas Cisco reports that Google Chrome policy prohibits public roots from issuing certificates combining Server and Client Authentication EKUs from 1 February 2027, with enforcement from 15 March 2027 13.
Platform Trust and Trunk Implementations
Microsoft Teams and Azure Communication Services
Microsoft states that TLS between its SIP endpoints and customer or partner SBCs for Direct Routing and Operator Connect is mutual TLS (mTLS), with Microsoft presenting a client certificate 27. When mutual TLS is enabled, the SBC must install every required Microsoft Trusted Root certificate 28. Microsoft Teams SIP interface certificates chain to one of 7 roots: DigiCert Global Root CA, DigiCert Global Root G2, DigiCert Global Root G3, DigiCert TLS ECC P384 Root G5, DigiCert TLS RSA 4096 Root G5, Microsoft ECC Root CA 2017, and Microsoft RSA Root CA 2017 35. SBCs must trust all 7 roots 35.
Certificates from Microsoft's new CA went into production at the end of July 2026, and the dedicated pre-change test endpoint (sip.g1.pstnhub.microsoft.com on port 5061, designated solely for SIP OPTIONS pings) was discontinued 2936. During the staged validation test on 30 June 2026, failures to establish outbound TLS connections or rejections of inbound ones indicated trust problems with the new certificate 17. WarmTransfer's reading of the sources is that an SBC that began failing TLS toward Teams Direct Routing around the July 2026 CA rollout, with the failures showing as an unknown_ca or certificate-validation error on the SBC side, most plausibly lacks one of the 7 listed roots in the trust store tied to the Teams TLS context 53.
Sources disagree on trust store recommendations for unrooted proxies: Microsoft's Teams Direct Routing troubleshooting documentation instructs an SBC that does not trust the SIP proxy certificate to install the Baltimore CyberTrust root 16, while ACS documentation directs administrators to install both the Baltimore CyberTrust root and DigiCert Global Root G2 1.
For ACS direct routing SIP signaling, the SBC must be able to negotiate one of 4 cipher 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, or TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 2.
Cisco Unified Border Element and Webex Calling
On Cisco IOS XE Local Gateways for Webex Calling, the Cisco root CA bundle is imported using crypto pki trustpool import clean url https://www.cisco.com/security/pki/trs/ios_core.p7b, which supplies the IdenTrust Commercial Root CA 1 certificate 43. Under sip-ua, the gateway sets transport tcp tls v1.2 and timers connection establish tls 5 (a 5-second minimum) 42. Configuring crypto signaling default trustpoint EmptyTP cn-san-validate server restricts connections to those where the host name configured in tenant 200 matches the peer certificate's CN or SAN 40.
For certificate-based trunks to Webex Calling, the gateway's certificate must be issued by a public CA, must use only lowercase letters to avoid registration failure caused by case mismatches with Control Hub, and its subject CN or a SAN must match the FQDN or SRV name configured in Control Hub 3941. Webex Calling peer certificates must chain through unexpired, unrevoked roots and intermediates from its approved CA list, carry the Control Hub FQDN, and need only the Server Authentication EKU 5759.
For Webex Calling Dedicated Instance, renewed certificates from 1 June 2026 are signed under IdenTrust Public Sector Root CA 1 instead of IdenTrust Commercial Root CA 1 15. Cisco states that third-party systems connecting via TLS or mTLS (such as SIP trunks to Cisco Unified Communications Manager or Unity Connection) must install IdenTrust Public Sector Root CA 1 or fail 14.
When CUBE establishes an inbound TLS session with CN-SAN verification, it skips the trusted IP address check 5. When configuring CUCM-to-CUBE trunks, the root and intermediate CA certificates are imported into the CUBE trustpoint before enrolling the identity certificate 8. The X.509 subject name configured in the CUCM SIP trunk security profile must match the peer certificate's subject name, and the trunk destination port changes from 5060 to 5061 12.
Diagnostic Procedures
When an SBC certificate is missing or intermediate certificates are omitted from the SBC's TLS handshake message, Microsoft notes that only a packet capture may expose that the certificate was never transmitted 26. Furthermore, if the root or intermediate certificate installed on the SBC does not match the actual issuer chain, the Teams service resets the connection, causing intermittent inactivity 19. In TLS 1.3, every message following ServerHello is encrypted, including Certificate messages 49. WarmTransfer's reading of the sources is that packet captures cannot expose missing intermediates in TLS 1.3 sessions without a key log or device-level debugging, rendering Microsoft's packet capture check directly applicable only to TLS 1.2 4.
Wireshark can decrypt TLS traffic using the server's RSA private key only when the session uses SSLv3 through TLS 1.2, does not use ephemeral Diffie-Hellman ((EC)DHE), and is not resumed; TLS 1.3 cannot be decrypted via RSA private keys 56. Conversely, an SSLKEYLOGFILE-style key log file serves as a universal mechanism enabling decryption across sessions using Diffie-Hellman key exchanges 55.
On CUBE, active TLS connections are verified with show sip-ua connections tcp tls detail, which outputs the negotiated TLS version, cipher, key type, and curve, while clear sip-ua tcp tls connection terminates a connection by target or ID 10. Cisco TAC lists debug crypto pki api, callbacks, messages and transactions, debug ssl openssl errors, msg and states, and debug ip tcp transactions for troubleshooting TLS 7.
In the Teams admin center, the Direct Routing Health Dashboard displays expired or revoked SBC certificates 24. Following a certificate renewal on the SBC, existing TLS sessions established with the old certificate must be terminated and re-established (such as by restarting the SBC during a maintenance window); failing to do so causes the Teams admin center to continue generating certificate expiry warnings 33. If certificates and settings are verified but the TLS session still drops, Microsoft attributes the interruption to intermediate firewalls or routers terminating the connection 25. If the TLS handshake completes successfully but the SBC receives no 200 OK to its SIP OPTIONS, the issue stems from SIP-layer mismatches: domain validation issues, a Contact header carrying an IP address, or discrepancies between the configured Teams FQDN and the Contact or Record-Route headers 30.
See also
See also Troubleshooting Teams Direct Routing. See also Troubleshooting a Webex Calling Local Gateway. See also CUBE troubleshooting commands. See also TLS certificates and secure SIP failures. See also Certificate lifecycle management for voice.
Applicability
Dedicated Instance trust store changes apply to certificate renewals from 1 June 2026 onward 15. Microsoft Teams Direct Routing certificate root transitions took effect in production at the end of July 2026 2935.
What remains uncertain
Sources disagree on whether the Baltimore CyberTrust root alone or both the Baltimore CyberTrust root and DigiCert Global Root G2 are required when an SBC does not trust the Microsoft SIP proxy certificate 161.
Sources disagree on the enforcement dates for Google Chrome Root Program Policy regarding the deprecation and elimination of combined Server and Client Authentication EKUs 4413.
Cipher suite requirements for Microsoft Teams Direct Routing trunks are not covered by the sources below.
See also
Related to
- CUBE troubleshooting commands — CUBE show; clear and debug commands for SIP TLS. Proposed; not previously recorded.
- Troubleshooting Teams Direct Routing — The Direct Routing SBC TLS; certificate and root CA material here is a subset of Direct Routing troubleshooting. Proposed; not previously recorded.
- Troubleshooting a Webex Calling Local Gateway — Local Gateway trustpool; cn-san-validate and certificate-based trunk certificate rules. Proposed; not previously recorded.
Referenced by
- Troubleshooting Genesys Cloud BYOC trunks — BYOC Cloud TLS requirements (TLS 1.2 on 5061; public-CA certificate matched by host name; no MTLS; per-platform ECDHE curves) are a vendor-specific case of generic SIP TLS handshake failures.
- Troubleshooting Teams Direct Routing — Proposed; not previously recorded. Direct Routing TLS and certificate failures are a platform-specific case of SIP TLS handshake failure. The topic id comes from the repository's queued topic list; its research content was not read.
- Troubleshooting Zoom Phone — Zoom BYOC-P/BYOP-P trunks are TLS-only on TCP/5061; so SBC TLS handshake failures present as BYOC trunk-down issues.
- Troubleshooting a Webex Calling Local Gateway — Proposed by this run; not previously recorded. Certificate-based Local Gateway trunk errors in Control Hub are mostly TLS certificate-chain failures (invalid CA; expired; revoked; CN/SAN mismatch).
Sources
- 1The Azure Communication Services direct routing troubleshooting article tells an SBC that does not trust the SIP proxy certificate to install both the Baltimore CyberTrust root and DigiCert Global Root G2.disputedTroubleshoot Azure Communication Services direct routing TLS certificate and SIP OPTIONS issues · TLS connection issues > SBC doesn't trust SIP proxy certificate · Checked 2026-09-25
- 2For ACS direct routing SIP signaling the SBC must be able to negotiate one of four cipher 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 or TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256.Azure direct routing infrastructure requirements - Azure Communication Services · SBC certificates and domain names, Important box · Checked 2026-09-25
- 3Azure Communication Services direct routing supports only TLS 1.2 for SBC signaling.Azure direct routing infrastructure requirements - Azure Communication Services · SBC certificates and domain names, Important box · Checked 2026-09-25
- 4Because TLS 1.3 encrypts the Certificate messages, a plain packet capture of a TLS 1.3 SIP trunk cannot show whether the SBC sent its intermediates; Microsoft's capture-based check for a missing chain works directly only on TLS 1.2 sessions, and TLS 1.3 needs a key log or device-side debugs.inferredRFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 · Section 1.2, read with Microsoft 'SBC certificate or intermediary certificates are missing' section and Wireshark TLS wiki decryption section · Checked 2026-09-25
- 5When CUBE establishes an inbound TLS session with CN-SAN verification, it skips the trusted IP address check.Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - SIP TLS Support · Configure SIP TLS, note on inbound CN-SAN verification · Checked 2026-09-25
- 6CUBE's cn-san-validate option takes server (validate the identity of the outbound peer), client (validate the identity of the inbound peer) or bidirectional (both), and CN/SAN validation is not on by default.Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - SIP TLS Support · Configure SIP TLS, cn-san-validate keyword description · Checked 2026-09-25
- 7Cisco TAC's CUBE SIP TLS technote lists debug crypto pki api, callbacks, messages and transactions, debug ssl openssl errors, msg and states, and debug ip tcp transactions for troubleshooting TLS.Configure SIP TLS Between CUCM-CUBE/CUBE-SBC With CA Signed Certificates · Troubleshoot section, debug command list · Checked 2026-09-25
- 8The Cisco technote imports the root and intermediate CA certificates into the CUBE trustpoint before importing the signed CUBE identity certificate.Configure SIP TLS Between CUCM-CUBE/CUBE-SBC With CA Signed Certificates · Configure section, CUBE certificate enrollment steps · Checked 2026-09-25
- 9From Cisco IOS XE 26.1.1, CUBE's default configuration no longer supports TLS 1.0 and 1.1 or their associated ciphers; using them requires 'system mode insecure'.Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - SIP TLS Support · Configure SIP TLS, transport tcp tls keyword description and 26.1.1 note · Checked 2026-09-25
- 10On CUBE, 'show sip-ua connections tcp tls detail' shows each SIP TLS connection's negotiated TLS version, cipher, key type and curve, and 'clear sip-ua tcp tls connection' takes an id or target to tear one down.Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - SIP TLS Support · Verify SIP TLS Configuration · Checked 2026-09-25
- 11CUBE's sip-ua transport command accepts 'transport tcp tls' followed by v1.0, v1.1, v1.2 (optionally with 'minimum') or v1.3 to pin or set a floor for the TLS version.Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - SIP TLS Support · Configure SIP TLS, transport command syntax · Checked 2026-09-25
- 12For a CUCM-to-CUBE SIP TLS trunk, the X.509 subject name in the CUCM SIP trunk security profile must match the peer certificate's subject name, and the trunk destination port changes from 5060 to 5061.Configure SIP TLS Between CUCM-CUBE/CUBE-SBC With CA Signed Certificates · Configure section, CUCM SIP trunk security profile and SIP trunk destination steps · Checked 2026-09-25
- 13Cisco gives 1 February 2027 as the date from which Google Chrome policy prohibits public roots from issuing certificates that combine Server and Client Authentication EKUs, with enforcement from 15 March 2027.disputedPublic CA certificate changes impacting Dedicated Instance · Reason for change section · Checked 2026-09-25
- 14Cisco says third-party systems that make TLS or mTLS connections to Dedicated Instance UC applications, such as SIP trunks to Unity Connection or Unified CM, must have IdenTrust Public Sector Root CA 1 in their trust store or those connections will fail.Public CA certificate changes impacting Dedicated Instance · Who is affected; Required actions · Checked 2026-09-25
- 15From 1 June 2026, renewed certificates for Webex Calling Dedicated Instance UC applications are signed under IdenTrust Public Sector Root CA 1 instead of IdenTrust Commercial Root CA 1.Public CA certificate changes impacting Dedicated Instance · Root CA change section · Checked 2026-09-25
- 16Microsoft's Teams Direct Routing troubleshooting article says an SBC that does not trust the SIP proxy certificate should install the Baltimore CyberTrust root.disputedSBC connectivity issues · TLS connection issues > SBC doesn't trust SIP proxy certificate · Checked 2026-09-25
- 17Microsoft said that during its 30 June 2026 staged CA validation test, an SBC failing to establish outbound TLS connections or rejecting inbound ones indicated trust problems with the new certificate.What's New Direct Routing · Validation test that switches Microsoft Teams Direct Routing SIP endpoints to certificates issued by a new CA (June 30, 2026), third bullet · Checked 2026-09-25
- 18Microsoft's Direct Routing planning guidance says the SBC certificate should carry the SBC FQDN in the CN or SAN, be signed by a CA in the Microsoft Trusted Root Program, and include the Server Authentication EKU.Plan Direct Routing · Public trusted certificate for the SBC, bullet list · Checked 2026-09-25
- 19If the root or intermediate installed on the SBC is not the actual issuer chain of the SBC certificate, the Teams service cannot validate the chain and resets the connection; Microsoft lists this as a cause of an SBC that is intermittently inactive.SBC connectivity issues · SIP options issues > SBC status is intermittently inactive, second bullet · Checked 2026-09-25
- 20Microsoft's 12 December 2025 Direct Routing update said that at some future point Microsoft would require all SBC certificates to include the Client Authentication EKU.disputedWhat's New Direct Routing · Update on upcoming certificate changes (December 12, 2025) > Summary, second bullet · Checked 2026-09-25
- 21Microsoft warns that some TLS libraries and SBCs may refuse outbound connections using a client certificate that lacks the Client Authentication EKU, even though the Teams SIP interface accepts such certificates.What's New Direct Routing · Update on upcoming certificate changes (December 12, 2025) > Summary, second bullet, last sentence · Checked 2026-09-25
- 22Microsoft SIP endpoints currently accept SBC certificates that lack the Client Authentication EKU, and Microsoft expects this to continue for the foreseeable future with advance notice of any change.What's New Direct Routing · Clarification on Client Authentication Extended Key Usage (EKU) · Checked 2026-09-25
- 23Microsoft's Direct Routing troubleshooting guidance says that if the TLS connection closes right away and no SIP OPTIONS arrive from the SBC, the TLS version may be the cause, and the SBC should be configured for TLS 1.2 or higher.SBC connectivity issues · TLS connection issues, introductory paragraph · Checked 2026-09-25
- 24The Direct Routing Health Dashboard in the Teams admin center can show that an SBC certificate is expired or revoked; the fix is to renew it from a trusted CA and install it on the SBC.SBC connectivity issues · TLS connection issues > SBC certificate is invalid, first paragraph · Checked 2026-09-25
- 25When certificates and SBC settings are correct but the TLS connection is still interrupted, Microsoft points to intermediary devices such as firewalls or routers between the SBC and Microsoft closing the connection.SBC connectivity issues · TLS connection issues > SBC connection is interrupted · Checked 2026-09-25
- 26Microsoft lists a missing SBC certificate or missing intermediate certificates in the SBC's TLS handshake as a failure cause, and notes that only a packet capture may show that the certificate was never sent even when the configuration looks correct.SBC connectivity issues · TLS connection issues > SBC certificate or intermediary certificates are missing in the SBC TLS "Hello" message · Checked 2026-09-25
- 27Microsoft states that TLS between its SIP endpoints and customer or partner SBCs for Direct Routing and Operator Connect is mutual TLS, with the Microsoft side presenting a client certificate.What's New Direct Routing · Update on upcoming certificate changes (December 12, 2025) > Background · Checked 2026-09-25
- 28If mutual TLS is enabled on the SBC for Direct Routing, the SBC needs every required Microsoft Trusted Root certificate installed.Plan Direct Routing · Public trusted certificate for the SBC, final sentence · Checked 2026-09-25
- 29Certificates from Microsoft's new CA for the Teams Direct Routing SIP endpoints went into production at the end of July 2026, and the pre-change testing endpoint was discontinued.What's New Direct Routing · Testing endpoint for upcoming certificate changes (February 16, 2026), Warning box · Checked 2026-09-25
- 30If TLS is established but the SBC gets no 200 OK to its OPTIONS, Microsoft points to SIP-layer causes: the Record-Route or Contact FQDN differs from the Teams configuration, the Contact carries an IP address, or the domain is not fully validated.SBC connectivity issues · SIP options issues > SBC doesn't receive a "200 OK" response from SIP proxy · Checked 2026-09-25
- 31In Teams Direct Routing the SBC opens the TLS connection to the SIP proxy FQDN and presents its certificate; if the SIP proxy judges the request invalid it closes the TLS connection and never receives SIP OPTIONS from the SBC.SBC connectivity issues · Overview of the SIP options process, bullets 1-2 · Checked 2026-09-25
- 32Direct Routing SIP/TLS from the SBC to the Microsoft SIP proxy uses destination port 5061; traffic from the proxy to the SBC uses whatever port is configured on the SBC.Plan Direct Routing · SIP signaling ports, table · Checked 2026-09-25
- 33After an SBC certificate is renewed, TLS connections set up with the old certificate must be torn down and re-established, for example by restarting the SBC in a maintenance window; otherwise the Teams admin center keeps raising certificate expiry warnings.SBC connectivity issues · TLS connection issues > SBC certificate is invalid, second paragraph · Checked 2026-09-25
- 34Teams Direct Routing treats a self-signed SBC certificate as invalid; the certificate must come from a trusted CA and contain at least one FQDN that belongs to a Microsoft 365 tenant.SBC connectivity issues · TLS connection issues > SBC certificate is self-signed or not from a trusted CA · Checked 2026-09-25
- 35Microsoft Teams SIP interface client and server certificates chain to one of seven roots (DigiCert Global Root CA, DigiCert Global Root G2, DigiCert Global Root G3, DigiCert TLS ECC P384 Root G5, DigiCert TLS RSA 4096 Root G5, Microsoft ECC Root CA 2017 and Microsoft RSA Root CA 2017), and SBCs must trust all of them.What's New Direct Routing · Update on upcoming certificate changes (December 12, 2025) > Changes and call to action; Summary · Checked 2026-09-25
- 36The discontinued pre-change test endpoint for the new Direct Routing CA was sip.g1.pstnhub.microsoft.com on port 5061, meant only for SIP OPTIONS pings and never for voice traffic.What's New Direct Routing · Testing endpoint for upcoming certificate changes (February 16, 2026) · Checked 2026-09-25
- 37A Direct Routing wildcard certificate covers only one label: *.contoso.com matches sbc1.contoso.com but not customer10.sbc1.contoso.com, and an FQDN that does not match the CN or SAN needs a new certificate.SBC connectivity issues · SIP options issues > FQDN doesn't match the contents of CN or SAN in the provided certificate · Checked 2026-09-25
- 38Teams Direct Routing accepts wildcard SBC certificates when they comply with RFC 2818.Plan Direct Routing · Public trusted certificate for the SBC, paragraph after the bullet list · Checked 2026-09-25
- 39For a Webex Calling certificate-based trunk, the Local Gateway certificate must be signed by a public CA, and its subject CN or one SAN must equal the FQDN (or the SRV name, when SRV is used) configured in Control Hub.Configure Local Gateway on Cisco IOS XE for Webex Calling · Certificate-based trunk requirements, certificate prerequisites and examples · Checked 2026-09-25
- 40On a registration-based Local Gateway, 'crypto signaling default trustpoint EmptyTP cn-san-validate server' under sip-ua makes the gateway permit the connection only if the host name configured in tenant 200 appears in the peer certificate's CN or SAN.Configure Local Gateway on Cisco IOS XE for Webex Calling · Registration-based trunk configuration, sip-ua block explanation · Checked 2026-09-25
- 41Cisco says the Local Gateway certificate should use only lowercase letters, because a case mismatch with the Control Hub FQDN will prevent trunk registration.Configure Local Gateway on Cisco IOS XE for Webex Calling · Certificate-based trunk requirements, case-sensitivity note · Checked 2026-09-25
- 42The Local Gateway sip-ua block sets 'transport tcp tls v1.2' and 'timers connection establish tls 5' (a minimum of 5 seconds, to be tuned to network conditions) for the TLS connection to Webex Calling.Configure Local Gateway on Cisco IOS XE for Webex Calling · Registration-based trunk configuration, sip-ua block · Checked 2026-09-25
- 43Cisco's Local Gateway guide installs the Cisco root CA bundle with 'crypto pki trustpool import clean url https://www.cisco.com/security/pki/trs/ios_core.p7b'; the bundle includes the IdenTrust Commercial Root CA 1 certificate used by Webex Calling.Configure Local Gateway on Cisco IOS XE for Webex Calling · Registration-based trunk configuration, root CA bundle step (crypto pki trustpool import) · Checked 2026-09-25
- 44Microsoft reports that Google's Chrome Root Program Policy v1.6 (February 2025) deprecates the Client Authentication EKU in TLS server certificates, and that from June 2026 certificates must include only the Server Authentication EKU to stay trusted by major browsers.disputedWhat's New Direct Routing · Update on upcoming certificate changes (December 12, 2025) > Background · Checked 2026-09-25
- 45Under RFC 5630 a SIPS URI requires TLS on every hop through to the remote UAS, deprecating RFC 3261's last-hop exception, while a SIP URI sent over TLS is only best-effort protection.RFC 5630: The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP) · Overview of SIPS semantics and last-hop exception text (section numbers not captured) · Checked 2026-09-25
- 46RFC 5922 forbids SIP implementations from matching any form of wildcard in a domain certificate.RFC 5922: Domain Certificates in the Session Initiation Protocol (SIP) · Section 7.2 · Checked 2026-09-25
- 47RFC 5922 takes a SIP domain identity from the certificate's subjectAltName, either a URI of scheme sip with no userinfo or a DNS name, and permits examining the CN only if no subjectAltName is present.RFC 5922: Domain Certificates in the Session Initiation Protocol (SIP) · Section 7.1 · Checked 2026-09-25
- 48TLS defines distinct certificate alerts: bad_certificate (42), unsupported_certificate (43), certificate_revoked (44), certificate_expired (45, also sent for not-yet-valid certificates), certificate_unknown (46) and unknown_ca (48, for a chain that cannot be anchored in a trusted CA).RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 · Section 6.2 · Checked 2026-09-25
- 49In TLS 1.3 every handshake message after ServerHello is encrypted, including the Certificate messages.RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 · Section 1.2 · Checked 2026-09-25
- 50The TLS handshake_failure alert (40) means the sender could not negotiate an acceptable set of security parameters from the options offered.RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 · Section 6.2, handshake_failure · Checked 2026-09-25
- 51TLS signals an unsupported protocol version with protocol_version (70) and parameters judged too weak with insufficient_security (71); in TLS 1.3 a server that requires a client certificate and gets none sends certificate_required (116).RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 · Section 6.2 · Checked 2026-09-25
- 52RFC 8996 (BCP 195) says TLS 1.0 and TLS 1.1 must not be used or negotiated, and it updates RFC 3261 so SIP's minimum becomes TLS 1.2.RFC 8996: Deprecating TLS 1.0 and TLS 1.1 · Sections 1.1, 4 and 5 · Checked 2026-09-25
- 53An SBC that began failing TLS toward Teams Direct Routing around the July 2026 CA rollout, with the failures showing as an unknown_ca or certificate-validation error on the SBC side, most plausibly lacks one of the seven listed roots in the trust store tied to the Teams TLS context.inferredWhat's New Direct Routing · Testing endpoint (February 16, 2026) Warning box; Update on upcoming certificate changes (December 12, 2025) > Summary; read with RFC 8446 section 6.2 unknown_ca · Checked 2026-09-25
- 54A wildcard SBC certificate that Teams Direct Routing accepts under RFC 2818 rules may still be rejected by a SIP peer that validates strictly under RFC 5922, so a wildcard that works toward Microsoft is no evidence it will work on a carrier or PBX trunk.inferredRFC 5922: Domain Certificates in the Session Initiation Protocol (SIP) · Section 7.2, read against Plan Direct Routing > Public trusted certificate for the SBC · Checked 2026-09-25
- 55The Wireshark wiki describes a key log file (SSLKEYLOGFILE-style per-session secrets) as a universal mechanism that enables decryption even when a Diffie-Hellman key exchange is used.TLS - Wireshark Wiki · TLS Decryption > Key log file · Checked 2026-09-25
- 56Wireshark can decrypt TLS with the server's RSA private key only when the negotiated cipher suite does not use (EC)DHE, the version is SSLv3 to TLS 1.2, and the session is not resumed; it cannot decrypt TLS 1.3 this way.TLS - Wireshark Wiki · TLS Decryption > Using the (Pre)-Master-Secret / RSA private key section · Checked 2026-09-25
- 57For Webex Calling mutual TLS, the peer certificate must be signed by a CA on Webex's approved list, be within its validity period, chain through unexpired and unrevoked roots and intermediates, and carry the Control Hub FQDN in its CN or SAN.Security requirements for Webex Calling · Mutual TLS certificate requirements · Checked 2026-09-25
- 58Webex Calling secure SIP uses port 5061, discovered through a _sips._tcp DNS SRV lookup.Security requirements for Webex Calling · SIP signaling port · Checked 2026-09-25
- 59Webex Calling accepts peer certificates that carry only the Server Authentication EKU; the Client Authentication EKU is not required.Security requirements for Webex Calling · Mutual TLS certificate requirements, Extended Key Usage · Checked 2026-09-25
- 60Webex Calling supports TLS 1.2 and TLS 1.3 for secure SIP.Security requirements for Webex Calling · TLS versions supported for secure SIP · Checked 2026-09-25
Documents
RFC 5630: The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)
RFC 5922: Domain Certificates in the Session Initiation Protocol (SIP)
RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
RFC 8996: Deprecating TLS 1.0 and TLS 1.1
Azure direct routing infrastructure requirements - Azure Communication Services
Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - SIP TLS Support
Configure Local Gateway on Cisco IOS XE for Webex Calling
Configure SIP TLS Between CUCM-CUBE/CUBE-SBC With CA Signed Certificates
Plan Direct Routing
Public CA certificate changes impacting Dedicated Instance
SBC connectivity issues
Security requirements for Webex Calling
TLS - Wireshark Wiki
Troubleshoot Azure Communication Services direct routing TLS certificate and SIP OPTIONS issues
What's New Direct Routing
Cite this page
APA
WarmTransfer. (2026, September 25). SIP TLS handshake failures on trunks. WarmTransfer. https://warmtransfer.net/knowledge/sip-tls-handshake-failures
BibTeX
@misc{warmtransfer-sip-tls-handshake-failures,
title = {SIP TLS handshake failures on trunks},
author = {{WarmTransfer}},
year = {2026},
url = {https://warmtransfer.net/knowledge/sip-tls-handshake-failures},
note = {Verified 2026-09-25}
}