Дякуємо за відгук.
Надіслати відгук?Після інциденту безпеки сертифікаційного органу eMUdhra (CA) у жовтні 2026 року було знято довіру до чотирьох Webex Calling кореневих сертифікатів. Якщо магістраль локального шлюзу на основі сертифікатів залежить від одного з цих органів, замініть відповідний сертифікат або ланцюжок, щоб зберегти безпечне підключення до TLS. Якщо задіяний магістраль перебуває в автономному режимі, вхідні та вихідні виклики PSTN та локальні інтеграції, які залежать від нього, можуть бути недоступні.
Постраждалі кореневі сертифікати:
-
Коренева служба сертифікації TLS EmSign - G3
-
Коренева сертифікація EMSign ECC - G3
-
emSign Коренева сертифікація CS - G3
-
Послуги сертифікатів AAA (корінь служб Comodo AAA)
Послуги сертифікатів AAA не були порушені. Однак він перехресно підписав уражені проміжні сертифікати eMUdhra, надаючи альтернативний шлях довіри до скомпрометованих сертифікатів.
Це впливає на клієнтів, які використовують магістралі локального шлюзу на основі сертифікатів (LGW), ланцюжки сертифікатів яких залежать від цих органів. Сюди входять сертифікати, видані Sectigo, які підключаються до Сервісів сертифікатів AAA через 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Перш ніж почати
- Вам потрібен доступ до центру керування з дозволом для перегляду стовбурів організації.
- Ім'я хоста шлюзу та порт SIP TLS для кожного основного, резервного та резервного шлюзу.
- Доступ до авторизованого комп'ютера за допомогою OpenSSL, який може досягти кожної кінцевої точки шлюзу.
| 1 |
Визначте свої магістралі локального шлюзу.
| ||||||||||
| 2 |
Перевірте ланцюжок сертифікатів кожного шлюзу.
| ||||||||||
| 3 |
Перегляньте суб'єкти сертифікатів та емітентів.
| ||||||||||
| 4 |
Інтерпретувати результати перевірки.
Підтверджується, що шлюз не впливає лише тоді, коли жодне з перерахованих коренів не з'являється, а стовбур перебуває в мережі в Центрі управління. | ||||||||||
| 5 |
Замініть ланцюжок сертифікатів, що стосуються.
| ||||||||||
| 6 |
Перевірте підключення до локального шлюзу.
|
Що робити далі
Якщо ланцюг виглядає правильним, але магістраль залишається «Офлайн», «Пошкоджений» або «Невідомий»:
- Переконайтеся, що сертифікат дійсний і встановлений правильно.
- Перевірте повний проміжний ланцюжок CA та очікувану ідентичність сертифіката.
- Перегляньте помилки підключення до TLS та перевірки сертифікатів у шлюзі.
- Зверніться до постачальника сертифікатів, партнера Cisco або Cisco Technical Assistance Center (TAC), якщо проблема не зникне. Під час контакту нада Cisco Technical Assistance Center йте ідентифікатор організації, дані магістралу, ім'я хоста шлюзу, інформацію про ланцюжок сертифікатів та відповідні повідомлення про помилки TLS.
Пов'язана інформація:
