CUBE с ошибкой MS Teams Direct Routing SIP TLS
-
Привет, ребята! Странная ситуация. В течение последних одной-двух недель я заметил, что почти на всех CUBE, которые мы используем в наших филиалах, возникают ошибки SIP TLS. Вот пример: 7231900: 16 июня 07:40:07.293 SAST: %SIP-2-TLS_HANDSHAKE_FAILED: сбой установления соединения TLS — remote_addr=52.114.132.46, remote_port=5061
7231908: 16 июня 07:42:03.362 SAST: %SIP-2-TLS_HANDSHAKE_FAILED: сбой установления соединения TLS — remote_addr=52.114.132.46, remote_port=5061
7231909: 16 июня 07:43:05.509 SAST: %SIP-2-TLS_HANDSHAKE_FAILED: сбой установления соединения TLS — remote_addr=52.114.148.0, remote_port=5061
7231910: 16 июня 07:44:05.513 SAST: %SIP-2-TLS_HANDSHAKE_FAILED: сбой установления соединения TLS — remote_addr=52.114.148.0, remote_port=5061
7231912: 16 июня 07:45:05.528 SAST: %SIP-2-TLS_HANDSHAKE_FAILED: сбой установления соединения TLS — remote_addr=52.114.148.0, remote_port=5061
7231924: 16 июня 07:47:04.525 SAST: %SIP-2-TLS_HANDSHAKE_FAILED: сбой установления соединения TLS — remote_addr=52.114.148.0, remote_port=5061
7231929: 16 июня 07:49:05.513 SAST: %SIP-2-TLS_HANDSHAKE_FAILED: сбой установления соединения TLS — remote_addr=52.114.148.0, remote_port=5061
7231935: 16 июня 07:51:03.336 SAST: %SIP-2-TLS_HANDSHAKE_FAILED: сбой установления соединения TLS — remote_addr=52.114.132.46, remote_port=5061
7231939: 16 июня 07:52:04.537 SAST: %SIP-2-TLS_HANDSHAKE_FAILED: сбой установления соединения TLS — remote_addr=52.114.148.0, remote_port=5061
7231943: 16 июня 07:54:05.285 SAST: %SIP-2-TLS_HANDSHAKE_FAILED: сбой установления соединения TLS — remote_addr=52.114.132.46, remote_port=5061
7231946: 16 июня 07:56:05.339 SAST: %SIP-2-TLS_HANDSHAKE_FAILED: сбой установления соединения TLS — remote_addr=52.114.132.46, remote_port=5061
7231954: 16 июня 07:58:03.486 SAST: %SIP-2-TLS_HANDSHAKE_FAILED: сбой установления соединения TLS — remote_addr=52.114.148.0, remote_port=5061
7231955: 16 июня 07:59:04.516 SAST: %SIP-2-TLS_HANDSHAKE_FAILED: сбой установления соединения TLS — remote_addr=52.114.148.0, remote_port=5061 В этом сценарии мы получаем входящий вызов pstn, но больше не можем выходить на внешнюю линию. Мы больше не используем сертификат Baltimore, который ранее использовался MS. Мы использовали конфигурацию дизайна от 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... Кто-нибудь из вас сталкивался с такой же проблемой в последние пару недель? -
Я исправил эту ошибку. Я вручную добавил корневой центр сертификации Digicert и удалил настройки, которые ранее добавил из руководства Cisco «Прямая маршрутизация для телефонной системы Microsoft с Cisco Unified Border Element (CUBE)». Вот что я сделал: 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 -
Вам просто нужно добавить DigiCert Trustpoint с корневым центром сертификации: 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 -
Microsoft объявила, что больше не использует сертификаты, подписанные Baltimore CA? У моего клиента в хранилище доверенных сертификатов без каких-либо проблем есть корневой центр сертификации Baltimore. Почему корневой центр Baltimore был удален из хранилища доверенных сертификатов CUBE? Кроме того, в хранилище доверенных сертификатов CUBE у меня есть корневой центр сертификации DigiCert. ![Response Signature]
-
Корневой центр сертификации Baltimore истек в прошлом месяце. Я думаю, что это как-то связано с таким поведением. Однако я также добавил корневой центр сертификации DigiCert, но все равно вижу эти ошибки TLS.
-
Сегодня, 19/06/25, у меня возникла эта проблема. В моем случае маршрутизаторы серий 8200 и 4300 также блокировали ЦП со следующими сообщениями:
%SYS-3-CPUHOG: Задача выполняется в течение (12913) мс, более (2000) мс (2/2), процесс = CCSIP_TLS_HANDSHAKE.
Вместе с OPs:
%SIP-2-TLS_HANDSHAKE_FAILED: сбой TLS-рукопожатия — remote_addr=x.x.x.x, remote_port=xxxx
Когда я очистил политику trustpool и пул сертификатов, можно было использовать новый DigiCert Root G2. Я уже применил этот сертификат, но он не работал до тех пор, пока Рене не дал ссылку на команды. -
Я полагаю, что это связано с тем, что срок действия сертификата, который ранее использовала Microsoft, истек, а новый сертификат, который вы загрузили, не вступил в силу в IOS. Это могло произойти из-за того, что вы не завершили его развертывание/использование при загрузке в IOS, или из-за некоторого дефекта, из-за которого сертификат не был загружен в IOS. ![Response Signature]
-
Убедитесь, что корневые центры сертификации Baltimore и DigiCert добавлены в хранилище доверия CUBEs. Я сохраняю настройку проверки отзыва как «нет». ![Response Signature]
-
Балтиморский корневой центр сертификации больше не нужен, так как его срок действия истек.
-
ОФИЦИАЛЬНО Да, Microsoft удалила Baltimore CA, и именно это стало причиной. Для меня очевидно, что это был сертификат, поскольку обе модели маршрутизаторов (8200 и 4300) имеют одинаковый тип ошибок, связанных с перегрузкой процессора и TLS. Еще раз спасибо, Рене.
-
Я видел на сайте Microsoft, что Балтимор был удален. Спасибо. Значит, здесь нужен только DigiCert. ![Response Signature]
-
Я видел то же самое на нашем маршрутизаторе. Даже маршрутизатор 1111 не мог справиться с этими ошибками и выходил из строя, когда у меня были запущены все три dial-peers (sip. sip1. и sip2.pstnhub.microsoft.com).
-
Привет, Рене и друзья! Мне нужна ваша помощь, я относительно новичок в PKI, прошу прощения, если задаю очевидные вопросы. Я столкнулся с одной и той же проблемой с многочисленными %SYS-3-CPUHOG: задача выполняется в течение (2589) мс, более (2000) мс (1/1), процесс = CCSIP_TLS_HANDSHAKE. Краткое описание состояния: Сертификат Baltimore (с истекшим сроком действия) установлен на терминале регистрации, проверка отзыва отсутствует
DigiCert Root CA уже присутствует в маршрутизаторе и настроен на проверку отзыва crl Я проверил политику доверия, вот статус: Политика Trustpool Проверка цепочки будет остановлена на первом сертификате CA в пуле
Сертификаты Trustpool CA истекут 22:25:42 14 мая 2039 г. Проверка
отзыва Trustpool отключена:
Сопоставление сертификатов отключено
Переопределения политики: Расположение
пакета CA:
http://www.cisco.com/security/pki/trs/ios_core.p7b Должен ли я вручную повторно добавить корневой центр сертификации DigiCert с новым отдельным Trustpoint или мне нужна помощь? -
Спасибо, Рене, за помощь. Хитрость сработала на несколько дней, а затем проблема вновь возникла. Я решил ее, восстановив и импортировав новый пакет CA в trustpool.
-
Спасибо,
@Rene Mueller,
ваш вклад очень помог мне решить эту проблему. Я воспользовался вашими советами и провел несколько тестов. Делюсь своими выводами и альтернативным способом решения проблемы. Я понял, что пакет cisco ca-bundle (
http://www.cisco.com/security/pki/trs/ios.p7b))
уже содержит сертификат DigiCert Global Root G2 CA. Я также понял, что в процессе установки trustpool устанавливаются «
внутренние
» точки доверия для всех сертификатов CA в пакете. Я решил изменить проверку отзыва на «нет» и таким образом также смог решить проблему. Вот что я сделал вместо этого, и это тоже сработало: 1) Удалить текущий trustpool: no crypto pki certificate pool 2) Отключите проверку отзыва в политике trustpool crypto pki trustpool policy
revocation-check none 3) Установите сертификат устройства также с опцией «
revocation-check none
». -------------- Во время тестирования я понял, что проблема каким-то образом связана с «
revocation-check crl»
либо при установке точки доверия сертификата устройства, либо при установке Truspool. Вот вывод отладки, который я получаю, когда «
revocation-check crl»
включен либо в Device Certificate trustpoint, либо в политике доверенного пула: CRYPTO_PKI: (50D35) Checking certificate revocation
CRYPTO_PKI: Attempt to set req from global storage handle has failed
CRYPTO_PKI: Current operation is aborted
CRYPTO_PKI: Remove session revocation service providers
CRYPTO_PKI: Rcvd request to end PKI session 50D35. Я не смог найти причину этой ошибки. Я смог решить ее только с помощью «
revocation-check none».
Здравствуйте! Похоже, вам интересна эта беседа, но у вас пока нет учетной записи.
Вы устали просматривать одни и те же посты каждый раз, когда заходите на сайт? После регистрации, вам не придётся искать обсуждения в которых вы принимали участие, настройте уведомления о новых сообщениях так как вам это удобно (по электронной почте или уведомлением). У вас появится возможность сохранять закладки и ставить лайки постам, чтобы выразить свою благодарность другим участникам сообщества.
С вашими комментариями этот пост может стать ещё лучше 💗
Зарегистрироваться Войти