CUBE с ошибкой MS Teams Direct Routing SIP TLS
-
Вам просто нужно добавить 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».
Здравствуйте! Похоже, вам интересна эта беседа, но у вас пока нет учетной записи.
Вы устали просматривать одни и те же посты каждый раз, когда заходите на сайт? После регистрации, вам не придётся искать обсуждения в которых вы принимали участие, настройте уведомления о новых сообщениях так как вам это удобно (по электронной почте или уведомлением). У вас появится возможность сохранять закладки и ставить лайки постам, чтобы выразить свою благодарность другим участникам сообщества.
С вашими комментариями этот пост может стать ещё лучше 💗
Зарегистрироваться Войти