Изисква се действие: Актуализация на защитата на сертификата на сертификата eMudhra за Webex Calling Local Gateways

След инцидента със сигурността на сертификационния орган на eMudhra (CA) през октомври 2026 г. Webex Calling премахна доверието в четири основни КО. Ако вашият основен локален шлюз, базиран на сертификат, зависи от някой от тези органи, заменете засегнатия сертификат или верига, за да поддържате сигурна TLS свързаност. Ако засегнатият багажник е офлайн, входящите и изходящите PSTN обаждания и локалните интеграции, които зависят от него, може да са недостъпни.

Засегнатите основни сертификати са:

Корен на eMsign TLS CA - G3
eMsign ECC Корен CA - G3
eMsign корен CS CA - G3
Услуги за сертификат AAA (корен на Comodo AAA Services)

Услугите за сертификат AAA не бяха компрометирани. Въпреки това той подписа кръстосани засегнатите междинни агенции на eMuDHRA, предоставяйки алтернативен път на доверие към компрометираните сертификати.

Клиентите, използващи базирани на сертификати стълбове Local Gateway (LGW), чиито вериги на сертификати зависят от тези органи, са засегнати. Това включва издадени от Sectigo сертификати, които се свързват с AAA Certificate Services чрез UserTrust.

Webex Callingсега отхвърля TLS връзки от засегнатите локални шлюзове. Входящите и изходящите PSTN обаждания и локалните интеграции на повиквания, които разчитат на тези шлюзове, ще се провалят.

От оторизиран компютър, който може да достигне SIP TLS порта на шлюза, изпълнете приложимата команда. Заменете lgw.example.com и 5061 с името на хоста на шлюза и TLS порт. Ако външният достъп е ограничен, изпълнете командата от оторизиран вътрешен хост за управление.

Линукс или 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, който може да достигне до всяка крайна точка на шлюза.

Идентифицирайте вашите стволове на Local Gateway.

В Контролния център отидете на У слу ги > PSTN и маршрутизиране > Конфигурации на шлюз > Trunk.
За клиенти, използващи плана за обаждания на Cisco, списъкът с багажника е достъпен и в Сер виз > Обаждания > Мар шру тизиране на повиквания > T run k.
Идентифицирайте базирани на сертификати стволове и запишете конфигурирания FQDN или SRV адрес, името на хоста на шлюза и SIP TLS порт. Повторете за излишни и резервни шлюзове.

Проверете веригата за сертификати на всеки шлюз.

Изпълнете приложимата команда OpenSSL. Изходът показва сертификати, представени от Local Gateway; той не проверява независимо цялата верига спрямо магазина за Webex Calling доверие.
Грешка в TLS ръкостискането или неуспешната проверка на OpenSSL не доказва, че шлюзът е засегнат от тази актуализация на доверието.

Прегледайте субектите на сертификатите и емитентите.

В раздела Сертификатна верига прегледайте предмета (ите:) и издателя (i:) на всеки сертификат. Проверете общото наименование (КН) и всяко вписване във веригата за изброените по-горе недоверчиви органи.
Например запис с тема CN=UserTrust RSA сертифициращ орган и емитент CN=AAA Certificate Services идентифицира сертификат, издаден от AAA Certificate Services.

Тълкувайте резултатите от инспекцията.

Резултат от веригата на сертификат	Състояние
Всеки ред s: или i: показва услуги за сертификати AAA или засегнат орган на eMSign	Засегнати. Поправете сега.
Никой от засегнатите органи не се появява и багажникът е онлайн в контролния център	Не е засегнат.
Никой от засегнатите органи не се появява, но багажникът е офлайн	Свържете се с партньора си или Cisco TAC за проверка на списъка с засегнати клиенти на Cisco.
Сроковете за свързване са изтекли или не се връща веригата на сертификати	Неубедителен. Проверете мрежовия достъп до TLS порта на шлюза и опитайте отново.

Шлюзът се потвърждава като незасегнат само когато нито един от изброените корени не се появи и стволът е онлайн в контролния център.

Заменете засегната верига на сертификати.

Свържете се с вашия доставчик на сертификати, за да получите заместващ сертификат или алтернативна верига, която приключва в корен, на който се доверяваWebex Calling. В много случаи съществуващият сертификат за шлюз може да бъде запазен и заменена само междинната верига. За засегнатите внедрявания на Sectigo това може да включва замяна на сертификат UserTrust с подписан AAA с подходяща алтернатива.
Инсталирайте актуализираната верига на сертификати на вашия Local Gateway и повторете проверката на сертификата.
Потвърдете, че багажника се показва онлайн в Control Hub и тествайте входящи и изходящи повиквания.

Проверете свързаността на локалния шлюз.

Повторете проверката на OpenSSL и потвърдете, че веригата за подмяна вече не зависи от недоверчивите органи.
В Control Hub потвърдете, че багажникът се показва онлайн.
Тествайте входящи и изходящи PSTN повиквания и локални интеграции за повиквания, които използват багажника.
Повторете валидирането за архивиране и излишни шлюзове.

Какво да правя по-нататък

Ако веригата изглежда правилна, но багажникът остава офлайн, нарушен или неизвестен:

Проверете дали сертификатът е валиден и инсталиран правилно.
Проверете пълната междинна CA верига и очакваната идентичност на сертификата.
Прегледайте TLS свързаността и грешките за валидиране на сертификати на шлюза.
Свържете се с вашия доставчик на сертификати, партньор на Cisco или Cisco Technical Assistance Center (TAC), ако проблемът продължава. Когато се свързватеCisco Technical Assistance Center, посочете идентификационния номер на вашата организация, данните за засегнатия багажник, името на хоста на шлюза, информация за веригата на сертификати и съответните съобщения за грешка в TLS.

Свързана информация:

Cisco AI Assistant

Благодарим за обратната връзка.

Малък бизнес

Предприятие

Устройства

Решения за

Ресурси

Фирма