В тази статия
dropdown icon
Какво може да бъде засегнато
    Сертификатни органи
Проверете и заменете засегнатите сертификати или вериги
Свързана информация
30 октомври 2026 г. | 36 преглеждане(ия) | 0 души считат, че това е полезно
Проверка и коригиране на сертификатите, засегнати от актуализацията на защитата на eMuDHRA за Webex Meetings
list-menuВ тази статия
list-menuОбратна връзка?

Cisco премахва доверието в някои основни CA, използвани за валидиране на сигурни SIP връзки, след инцидента със сигурността на сертифициращия орган на eMudhra (CA) през октомври 2026 г. Прилагането на засегнатите Webex Meetings SIP интеграции се планира да започне на 2 ноември 2026 г. Внедряването може да се осъществи на етапи. Планирайте да завършите промените си преди 2 ноември. Клиентите, чиито вериги на сертификати зависят от недоверчивите органи, трябва да заменят засегнатия сертификат или верига. В противен случай засегнатата сигурна SIP връзка ще се провали с TLS удостоверяването, когато актуализираната политика за доверие бъде приложена за тази връзка.

Какво може да бъде засегнато

Интеграции

  • Webex MeetingsEdge Audio: При набиране и набиране на срещи чрез засегнатите корпоративни SIP връзки ще спрат да работят, когато изпълнението достигне тези връзки.

  • Конферентни зали за сътрудничество (CMR): Присъединяването на базирани на SIP видео устройства чрез засегнатите защитени SIP връзки ще се провали, когато прилагането достигне тези връзки.

  • Управляваната от клиенти инфраструктура може да включва Cisco CUBE, Expressway-E и други контролери за граници на сесиите (SBC). Прегледайте както първичните, така и излишните системи.

Тези промени са насочени към SIP интеграции, използващи засегнатите вериги на сертификати; други методи за достъп до събрания не зависят от същия път на SIP сертификат, управляван от клиента.

Сертификатни органи

Проверете за вериги на сертификати, които зависят от някой от следните органи:

  • Корен на eMsign TLS CA - G3

  • eMsign ECC Корен CA - G3

  • eMsign корен CS CA - G3

  • Услуги за сертификат AAA (корен на Comodo AAA Services)

AAA Certificate Services не беше компрометиран, но кръстосано подписва засегнатите междинни продукти на eMu DHRA и е включен в този отговор за сигурност. Някои сертификати, издадени от Sectigo, могат да използват кръстосано подписан AAA сертификат, въпреки че самите сертификати за клиенти на Sectigo не са били компрометирани.

EmSign Root CA - G1 не е включен в тази промяна в недоверието. Не заменяйте или премахвайте сертификатите единствено защото използват G1.

Проверете и заменете засегнатите сертификати или вериги

1

Идентифицирайте CUBE, Expressway-E или SBC, използвани за засегнатата интеграция на срещи, базирани на Edge Audio или SIP. Запишете действителното име на хоста и конфигурирания SIP TLS порт. След това проверете TLS серти фиката за самоличност, инсталиран на тази система, и всички придружаващи междинни CA сертификати.

В Expressway-E инсталираният сървър сертификат може да се види в Поддръжка > Защита > Сер ти фикат на сър вър а. За CUBE и други SBC използвайте приложимата процедура за проверка на сертификат за доставчик.

Повторете за резервни и излишни системи.

2

От компютър с инсталиран OpenSSL и мрежов достъп до слушателя SIP TLS изпълнете съответ ния пример:

  • Линукс или macOS: 

    openssl s_client -connect sip-gateway.example.com:5061 -showcerts </dev/null

  • Команден ред на Windows: 

    openssl s_client -connect sip-gateway.example.com:5061 -showcerts <NUL

Заменете примерното име на хост и порт с действителната си SIP TLS крайна точка; портът може да се различава според внедряването. Ако входящият TLS достъп е ограничен, изпълнете проверката от оторизирана система за управление.

На Expressway-E SIP TLS портът, използван с Webex, може да изисква клиентски сертификат. След това командата може да завърши с грешка, но веригата на сертификатите все още се показва.

Прегледайте записите на веригата на сертификати, включително субекта (ите:) и издателя (i:). Потър сете някое от четирите засегнати имена на CA, включително сертификат UserTrust RSA сертифициращ орган, изда ден от AAA Certificate Services.

Пример за засегнато кръстосано въвеждане на верига:

  • s: cn = UserTrust RSA сертифициращ орган

  • i: CN = AAA сертификатни услуги

3

Тълкувайте констатациите:

  • От@@ крит е засегнат CA: Третирайте веригата като засегната и я актуализирайте преди прилагането.

  • Не е показан засегнат CA и SIP интеграцията работи: Тази проверка не показва незабавни действия , освен ако Cisco не уведоми отделно организацията ви за засегната зависимост.

  • Не е показан засегнат сертификат, но Cisco уведоми вашата организация или интеграцията на SIP се проваля: Свържете се с вашия партньор на Cisco или Cisco TAC за помощ за идентифициране на пълния път на сертифициране и засегнатата връзка.

  • Няма показан сертификат или изтичане на времето за свързване: Потвърдете правилното име на хоста, порта, контролите за достъп и метода на проверка.

4

Свържете се с вашия доставчик на сертификати или дистрибутор за заместващ сертификат или алтернативна верига на сертификати, завършваща на корен, който не е изброен по-горе. Помолете доставчика да потвърди, че веригата за замяна е подходяща за интеграцията на Webex SIP.

  • Когато се поддържа, запазете съществуващия сертификат за самоличност и заменете само междинната верига. За засегнатите внедрявания на Sectigo заменете сертификата UserTrust, издаден от AAA Certificate Services, с подходяща алтернативна верига от Sectigo или вашия доставчик. Никога не го премахвайте, без да инсталирате и потвърдите под мяната му.

  • Инсталирайте сертификата или веригата на всеки засегнат CUBE, Expressway-E или SBC, следвайки инструкциите за конфигуриране на този продукт. Уверете се, че инсталираният сертификат за самоличност остава валиден за конфигурираната SIP идентичност на системата.

Проверете отново инсталираната верига, за да проверите дали тя вече не зависи от недоверчивите органи.

5

Потвърждаване на свързаността на събранието:

  • За Edge Audio тествайте маршрутите за набиране и обратно повикване/набиране на срещи, които преминават засегнатата корпоративна SIP връзка.

  • За CMR тествайте видео устройството, базирано на SIP, се присъединява през засегнатата инфраструктура.

  • Проверете както първичния, така и пътеките за прекъсване на Прегледайте грешките в TLS и неуспехите при проверка на сертификати, ако връзката остава недостъпна.

Ако съществуват проблеми със свързаността със сертификат или SIP, свържете се с вашия партньор на Cisco или Cisco Technical Assistance Center (TAC). Предоставете вашия Webex Organization ID, засегнатата услуга, засегнат ата система и името на SIP хост, подробности за веригата на сертификати и всички съобщения за грешки в TLS или SIP. Не споделяйте лични ключове.

Беше ли полезна тази статия?
Беше ли полезна тази статия?
ЦениПриложение WebexСрещиCallingИзпращане на съобщенияСподеляне на екрана
Webex SuiteCallingСрещиИзпращане на съобщенияSlidoУебинариEventsContact CenterCPaaSЗащитаControl Hub
СлушалкиКамериСерия на бюротоСерия RoomСерия BoardСерия PhoneАксесоари
ОбразованиеЗдравеопазванеДържавен секторФинансиСпорт и развлеченияFrontlineНестопански организацииСтартиращи компанииХибридна работа
ИзтеглянияПрисъединяване към тестова срещаОнлайн уроциИнтеграцииДостъпностПриобщаванеУебинари в реално време и при поискванеОбщност на WebexWebex разработчициНовини и иновации
CiscoСвържете се с поддръжкатаВръзка с отдел „Продажби“Webex BlogWebex – лидерство в мисленетоМагазин за стоки на WebexКариери
  • X
  • LinkedIn
  • Facebook
  • Youtube
  • Instagram
Правила и условияДекларация за поверителностБисквиткиТърговски марки
©2026 Cisco и/или техните филиали. Всички права запазени.
Правила и условияДекларация за поверителностБисквиткиТърговски марки