CUBE with MS Teams Direct Routing SIP TLS error

[Rene Mueller]

Hi Folks!

strange situation here. Since a week or two I can see on almost every CUBE we are running in our branch offices that there are SIP TLS errors coming up. Here is an example:

7231900: Jun 16 07:40:07.293 SAST: %SIP-2-TLS_HANDSHAKE_FAILED: TLS handshake failure - remote_addr=52.114.132.46, remote_port=5061
7231908: Jun 16 07:42:03.362 SAST: %SIP-2-TLS_HANDSHAKE_FAILED: TLS handshake failure - remote_addr=52.114.132.46, remote_port=5061
7231909: Jun 16 07:43:05.509 SAST: %SIP-2-TLS_HANDSHAKE_FAILED: TLS handshake failure - remote_addr=52.114.148.0, remote_port=5061
7231910: Jun 16 07:44:05.513 SAST: %SIP-2-TLS_HANDSHAKE_FAILED: TLS handshake failure - remote_addr=52.114.148.0, remote_port=5061
7231912: Jun 16 07:45:05.528 SAST: %SIP-2-TLS_HANDSHAKE_FAILED: TLS handshake failure - remote_addr=52.114.148.0, remote_port=5061
7231924: Jun 16 07:47:04.525 SAST: %SIP-2-TLS_HANDSHAKE_FAILED: TLS handshake failure - remote_addr=52.114.148.0, remote_port=5061
7231929: Jun 16 07:49:05.513 SAST: %SIP-2-TLS_HANDSHAKE_FAILED: TLS handshake failure - remote_addr=52.114.148.0, remote_port=5061
7231935: Jun 16 07:51:03.336 SAST: %SIP-2-TLS_HANDSHAKE_FAILED: TLS handshake failure - remote_addr=52.114.132.46, remote_port=5061
7231939: Jun 16 07:52:04.537 SAST: %SIP-2-TLS_HANDSHAKE_FAILED: TLS handshake failure - remote_addr=52.114.148.0, remote_port=5061
7231943: Jun 16 07:54:05.285 SAST: %SIP-2-TLS_HANDSHAKE_FAILED: TLS handshake failure - remote_addr=52.114.132.46, remote_port=5061
7231946: Jun 16 07:56:05.339 SAST: %SIP-2-TLS_HANDSHAKE_FAILED: TLS handshake failure - remote_addr=52.114.132.46, remote_port=5061
7231954: Jun 16 07:58:03.486 SAST: %SIP-2-TLS_HANDSHAKE_FAILED: TLS handshake failure - remote_addr=52.114.148.0, remote_port=5061
7231955: Jun 16 07:59:04.516 SAST: %SIP-2-TLS_HANDSHAKE_FAILED: TLS handshake failure - remote_addr=52.114.148.0, remote_port=5061

In this scenario we receive incoming pstn call, but cannot dial out anymore. We don't use the Baltimore cert anymore which was used by MS before.

We used the design configruation from Cisco:

https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://www.cisco.com/c/dam/en/us/solutions/collateral/enterprise/interoperability-portal/direct-routing-with-cube.pdf&ved=2ahUKEwiL9s_yhviNAxX7TqQEHUU9E4oQFnoECB4QAQ&usg=AOvVaw0xFsI1k...

Does anyone here experience the same issue in the last couple of weeks?

[Nithin Eluvathingal]

Has Microsoft announced that they are no longer using Baltimore CA-signed certificates? My customer has Baltimore root CA in their trust store without any issues. Why was the Baltimore Root removed from your CUBE trust store?

Additionally, I have the DigiCert Root CA in the CUBE trust store.

[Rene Mueller]

The Baltimore root CA expired last month. I think it has something to do with that behaviour. However, I also added DigiCert Root CA but still see those TLS erros

[Rene Mueller · Accepted solution]

I got that fixed now. I manually added the Digicert Root CA and removed the setup I added previously from Ciscos "Direct Routing for Microsoft Phone System with Cisco Unified Border Element (CUBE)" guide.

Here is what I did:

crypto pki trustpoint DigiCert_Root_CA
enrollment terminal pem
revocation-check none

crypto pki authenticate DigiCert_Root_CA

-----BEGIN CERTIFICATE-----
MIIDjjCCAnagAwIBAgIQAzrx5qcRqaC7KGSxHQn65TANBgkqhkiG9w0BAQsFADBh
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMSAwHgYDVQQDExdEaWdpQ2VydCBHbG9iYWwgUm9vdCBH
MjAeFw0xMzA4MDExMjAwMDBaFw0zODAxMTUxMjAwMDBaMGExCzAJBgNVBAYTAlVT
MRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j
b20xIDAeBgNVBAMTF0RpZ2lDZXJ0IEdsb2JhbCBSb290IEcyMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuzfNNNx7a8myaJCtSnX/RrohCgiN9RlUyfuI
2/Ou8jqJkTx65qsGGmvPrC3oXgkkRLpimn7Wo6h+4FR1IAWsULecYxpsMNzaHxmx
1x7e/dfgy5SDN67sH0NO3Xss0r0upS/kqbitOtSZpLYl6ZtrAGCSYP9PIUkY92eQ
q2EGnI/yuum06ZIya7XzV+hdG82MHauVBJVJ8zUtluNJbd134/tJS7SsVQepj5Wz
tCO7TG1F8PapspUwtP1MVYwnSlcUfIKdzXOS0xZKBgyMUNGPHgm+F6HmIcr9g+UQ
vIOlCsRnKPZzFBQ9RnbDhxSJITRNrw9FDKZJobq7nMWxM4MphQIDAQABo0IwQDAP
BgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBhjAdBgNVHQ4EFgQUTiJUIBiV
5uNu5g/6+rkS7QYXjzkwDQYJKoZIhvcNAQELBQADggEBAGBnKJRvDkhj6zHd6mcY
1Yl9PMWLSn/pvtsrF9+wX3N3KjITOYFnQoQj8kVnNeyIv/iPsGEMNKSuIEyExtv4
NeF22d+mQrvHRAiGfzZ0JFrabA0UWTW98kndth/Jsw1HKj2ZL7tcu7XUIOGZX1NG
Fdtom/DzMNU+MeKNhJ7jitralj41E6Vf8PlwUHBHQRFXGU7Aj64GxJUTFy8bJZ91
8rGOmaFvE7FBcf6IKshPECBV1/MUReXgRPTqh5Uykw7+U0b6LJ3/iyK5S9kJRaTe
pLiaWN0bfVKfjllDiIGknibVb63dDcY3fe0Dkhvld1927jyNxF1WW6LZZm6zNTfl
MrY=
-----END CERTIFICATE-----

no crypto pki trustpool policy
no crypto pki certificate pool

[NickEoannidis4670]

I had this problem today - 19/06/25. In my case the 8200 and 4300 series routers were also locking up CPU with the following messages:

%SYS-3-CPUHOG: Task is running for (12913)msecs, more than (2000)msecs (2/2),process = CCSIP_TLS_HANDSHAKE.

Along with OPs:
%SIP-2-TLS_HANDSHAKE_FAILED: TLS handshake failure - remote_addr=x.x.x.x, remote_port=xxxx

When i cleared the trustpool policy and the certificate pool the new DigiCert Root G2 could be used. I had already applied this cert but it was not working untill the no commands that Rene linked.

[Roger Kallberg]

I believe that this due to that the certificate that Microsoft used to use has expired and the new cert that you uploaded hadn't taken effect in IOS. This could be by not fully completing the deployment/usage of it when you uploaded it in IOS or due to some defect that did not load the certificate as used in IOS.

[Nithin Eluvathingal]

Ensure that the Baltimore and DigiCert Root CAs are added to the CUBEs Trsutstore. I keep , the revocation check setting as "none."

[Rene Mueller]

There is no need for the Baltimore Root CA anymore as it is already expired. 

[NickEoannidis4670]

OFFICIAL

Yep, Microsoft removed Baltimore CA and that's what caused this.
Dead give away for me that it was certificate is how can both router models (8200 and 4300) have the same type of cpu hog and TLS errors.

Thanks again, Rene.

[Nithin Eluvathingal]

I saw on the Microsoft site that Baltimore has been removed. Thanks. So, only DigiCert is needed here.

[Rene Mueller]

I saw the same on our router. Even the 1111 router was not able to handle those errors and crashed whenever I had all three dial-peers up (sip. sip1. and sip2.pstnhub.microsoft.com).

[Mike40]

Hi Rene and Folks,

I need your help, I am relatively new to PKI you will forgive me if i ask the obvious. 

I am facing the same issue with numerous %SYS-3-CPUHOG: Task is running for (2589)msecs, more than (2000)msecs (1/1),process = CCSIP_TLS_HANDSHAKE.

status summary: 

• Baltimore certificate(expired) is set to enrollment terminal,  revocation-check none
• DigiCert Root CA is already present in the router and it is set to revocation-check crl

I have check for trust policy here is the status:

Trustpool Policy

Chain validation will stop at the first CA certificate in the pool
Trustpool CA certificates will expire 22:25:42  May 14 2039
Trustpool revocation checking is disabled:
Certificate matching is disabled
Policy Overrides:
CA Bundle Location: http://www.cisco.com/security/pki/trs/ios_core.p7b

Do I have to manually re-add the DigiCert Root CA in with a new separate Trustpoint or, I need assistance

[Stijni]

We had this problem too and even though I read about the Baltimore certificate being expired, I found it strange that problems started to show up after a month.

Your solution worked perfectly. I initially added the digicert certificate, but those 2 last commands did the trick:

no crypto pki trustpool policy
no crypto pki certificate pool

 Thanks. Wished I found this one earlier.