CUBE с ошибкой MS Teams Direct Routing SIP TLS

[NickEoannidis4670]

Сегодня, 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. Я уже применил этот сертификат, но он не работал до тех пор, пока Рене не дал ссылку на команды.

[Roger Kallberg]

Я полагаю, что это связано с тем, что срок действия сертификата, который ранее использовала Microsoft, истек, а новый сертификат, который вы загрузили, не вступил в силу в IOS. Это могло произойти из-за того, что вы не завершили его развертывание/использование при загрузке в IOS, или из-за некоторого дефекта, из-за которого сертификат не был загружен в IOS. ![Response Signature]

[Nithin Eluvathingal]

Убедитесь, что корневые центры сертификации Baltimore и DigiCert добавлены в хранилище доверия CUBEs. Я сохраняю настройку проверки отзыва как «нет». ![Response Signature]

[Rene Mueller]

Балтиморский корневой центр сертификации больше не нужен, так как его срок действия истек.

[NickEoannidis4670]

ОФИЦИАЛЬНО Да, Microsoft удалила Baltimore CA, и именно это стало причиной. Для меня очевидно, что это был сертификат, поскольку обе модели маршрутизаторов (8200 и 4300) имеют одинаковый тип ошибок, связанных с перегрузкой процессора и TLS. Еще раз спасибо, Рене.

[Nithin Eluvathingal]

Я видел на сайте Microsoft, что Балтимор был удален. Спасибо. Значит, здесь нужен только DigiCert. ![Response Signature]

[Rene Mueller]

Я видел то же самое на нашем маршрутизаторе. Даже маршрутизатор 1111 не мог справиться с этими ошибками и выходил из строя, когда у меня были запущены все три dial-peers (sip. sip1. и sip2.pstnhub.microsoft.com).

[Mike40]

Привет, Рене и друзья! Мне нужна ваша помощь, я относительно новичок в 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 или мне нужна помощь?

[Mike40]

Спасибо, Рене, за помощь. Хитрость сработала на несколько дней, а затем проблема вновь возникла. Я решил ее, восстановив и импортировав новый пакет CA в trustpool.

[MTex]

Спасибо,
@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».