После инцидента, произошедшего в октябре 2026 года в центре сертификации eMudhra, доверие к четырем корневым центрам сертификации Webex Calling было подорвано. Если магистраль локального шлюза на основе сертификатов зависит от одного из этих органов, замените поврежденный сертификат или цепочку, чтобы обеспечить безопасное подключение по протоколу TLS. Если зараженная магистраль находится в автономном режиме, входящие и исходящие вызовы PSTN и зависящие от нее локальные интеграции могут быть недоступны.
Затронуты следующие корневые сертификаты:
-
Корневой протокол TLS EMSign CA-G3
-
Корневой центр переменного тока EMSign ECC — 3G
-
Корневой маршрутизатор EMsign CS — 3G
-
Службы сертификации AAA (корень служб Comodo AAA)
Службы сертификации AAA не были скомпрометированы. Однако компания поставила перекрестную подпись на уязвимые промежуточные центры сертификации eMudhra, предоставив скомпрометированным сертификатам альтернативный путь доверия.
Это влияет на клиентов, использующих магистральные каналы локального шлюза на основе сертификатов (LGW), чьи цепочки сертификатов зависят от этих органов. Сюда входят сертификаты, выпущенные Sectigo, которые передаются в службы сертификации AAA через UserTrust.
Webex Callingтеперь отклоняет соединения TLS от затронутых локальных шлюзов. Входящие и исходящие вызовы PSTN, а также интеграция локальных вызовов, использующая эти шлюзы, потерпят неудачу.
На авторизованном компьютере, который может подключиться к порту SIP TLS шлюза, выполните соответствующую команду. Замените lgw.example.com и 5061 на имя хоста шлюза и порт TLS. Если внешний доступ ограничен, запустите команду с авторизованного внутреннего хоста управления.
Linux или macOS:
openssl s_client -connect lgw.example.com:5061 -showcerts </dev/null
Командная строка Windows:
openssl s_client -connect lgw.example.com:5061 -showcerts <NUL
Прежде чем начать
- Для просмотра транков организации требуется доступ к Control Hub с разрешением.
- Имя хоста шлюза и порт SIP TLS для каждого основного, резервного и резервного шлюза.
- Доступ к авторизованному компьютеру с OpenSSL, который может подключиться к каждой конечной точке шлюза.
| 1 |
Определите магистрали локального шлюза.
| ||||||||||
| 2 |
Проверьте цепочку сертификатов каждого шлюза.
| ||||||||||
| 3 |
Ознакомьтесь с субъектами и эмитентами сертификатов.
| ||||||||||
| 4 |
Интерпретируйте результаты проверки.
Подтверждается, что шлюз не затронут, только если ни один из перечисленных корней не отображается, а магистраль в Control Hub подключена к сети. | ||||||||||
| 5 |
Замените поврежденную цепочку сертификатов.
| ||||||||||
| 6 |
Проверьте подключение к локальному шлюзу.
|
Что делать дальше
Если цепочка выглядит правильно, но магистраль остается в автономном режиме, повреждена или неизвестна, выполните следующие действия:
- Убедитесь, что сертификат действителен и правильно установлен.
- Проверьте всю промежуточную цепочку центров сертификации и ожидаемый идентификатор сертификата.
- Проверьте ошибки подключения по протоколу TLS и проверки сертификатов на шлюзе.
- Если проблема не исчезнет, обратитесь к поставщику сертификатов, партнеру Cisco или Cisco Technical Assistance Center (TAC). При обращении укажите идентификатор организацииCisco Technical Assistance Center, сведения о затронутой магистрали, имя хоста шлюза, информацию о цепочке сертификатов и соответствующие сообщения об ошибках TLS.
Сопутствующая информация: