Chrome і Firefox заблокували сертифікати eMudhra: що робити
У системі довіри до захищених сайтів виявили серйозну помилку: приватні ключі восьми проміжних сертифікатів компанії eMudhra виявилися настільки слабкими, що їх можна було відновити з відкритих даних. Chrome, Firefox та інші постачальники програм почали блокувати ці сертифікати, а Google оголосила про вилучення пов’язаного кореневого сертифіката. Для більшості людей це не привід змінювати паролі, але важливо розуміти, які оновлення вже захищають браузери і чому старі пристрої можуть залишатися проблемою.
Чому вісім сертифікатів спричинили тривогу
Коли браузер відкриває сайт із HTTPS, він перевіряє не лише шифрування з’єднання, а й те, чи має сервер підстави називатися саме цим сайтом. Для цього використовується ланцюжок цифрових сертифікатів, який веде до довіреного центру сертифікації. Проміжний центр може підтверджувати справжність інших сертифікатів. Якщо його приватний ключ стає доступним стороннім, виникає ризик підроблення документів довіри для чужих доменів.
Саме така небезпека з’явилася після повідомлення про вісім ключів eMudhra. Із них шість були призначені для випуску сертифікатів сайтів, а два — для підписування програм. Йдеться не про вкрадений пароль конкретного користувача і не про злам усіх HTTPS-сайтів. Це помилка в інфраструктурі, від якої залежить перевірка справжності вебресурсів. Її масштаб визначається тим, які програми довіряли відповідним центрам та чи отримали вони оновлення.
Що сталося з криптографічними ключами
Проблема полягала не в тому, що складний секрет зберігали у відкритому файлі. За повідомленнями дослідників, значення приватних ключів були надзвичайно малими для використаного криптографічного алгоритму. Через це їх можна було вивести з опублікованих сертифікатів без звичайного тривалого перебору. У матеріалах The Register описано випадок, коли один із приватних ключів фактично відповідав числу 4. Для ключа, який повинен мати величезний простір можливих значень, це критична помилка.
eMudhra заявила, що під час процедури створення ключів у квітні 2025 року збій операції обробки призвів до появи слабкого набору поруч із належним. За версією компанії, саме неправильний набір потрапив до систем довіри. Це пояснення виробника, а не остаточно встановлена незалежним розслідуванням причина. Важливо й те, що проходження попередніх перевірок не запобігло інциденту: сам факт аудиту не замінює перевірки якості ключів.
Як можна було використати підроблений сертифікат
Уявімо, що зловмисник контролює частину мережевого шляху між людиною та сайтом — наприклад, небезпечну точку доступу або скомпрометований маршрутизатор. Якщо програма довіряє підробленому сертифікату, атакувальник потенційно може видати свій сервер за справжній, читати або змінювати передані дані. Але сам факт існування слабкого ключа не дає автоматичного доступу до чужих повідомлень: потрібні додаткові умови, а сучасні браузери застосовують і інші перевірки.
Одна з них — Certificate Transparency, публічні журнали випущених сертифікатів. Команда Chrome повідомила, що до запровадження блокування в цих журналах не було TLS-сертифікатів, які спиралися на шість проблемних проміжних центрів. Для браузерів, які вимагають такого запису, це суттєво знижує ймовірність непомітного використання підробки. Водночас журнали не доводять, що жодна інша програма або старий пристрій ніколи не міг бути вразливим.
Що зробили Chrome та Android
Chrome Root Program повідомила, що отримала сигнал 17 жовтня о 18:05 UTC, а вже о 19:45 UTC підготувала блокування шести проміжних центрів для TLS. Захист передавався через CRLSet — механізм оновлення переліку недовірених сертифікатів. За офіційним поясненням Google, стандартним користувачам Chrome не потрібно було чекати повного випуску нової версії браузера чи вручну перезапускати його, щоб отримати це блокування.
Для Android аналогічне обмеження Google розповсюдила через системні сервіси Play. Окремо компанія оголосила про вилучення пов’язаного кореневого сертифіката eMudhra з Chrome Root Store у версії 43. На момент підготовки матеріалу офіційне повідомлення описувало цей крок як запланований; стверджувати, що оновлення вже отримали всі пристрої, було б передчасно. Вилучення кореня має значення також для програм, які використовують список довіри Chrome, але не користуються його оперативним списком блокування.
Що змінилося у Firefox і чому важлива версія Android
Mozilla підтвердила отримання повідомлення 17 жовтня о 20:06 UTC. За її даними, розповсюдження блокування через OneCRL завершилося до 22:59 UTC того самого дня для звичайних конфігурацій Firefox. Це дозволило захистити користувачів без окремого завантаження великого оновлення. Водночас компанія випустила Firefox 158.0.1 і спеціальні випуски ESR, щоб охопити системи, де віддалене оновлення списку сертифікатів могло бути вимкнене.
Для Firefox на Android 21 жовтня вийшла версія 158.0.2. Mozilla пояснила, що додаткове виправлення усуває проблему застосування вбудованого списку блокування під час запуску на частині пристроїв. Компанія також оновила бібліотеку NSS, вилучивши довіру до відповідного кореня. Отже, навіть якщо браузер зазвичай оновлюється автоматично, корисно перевірити версію та доступні оновлення в магазині застосунків.
Чи потрібно терміново змінювати паролі
Підтвердженого масового перехоплення паролів через цей інцидент офіційні повідомлення не описують. Тому рекомендація всім користувачам негайно змінювати паролі від банків, пошти та соціальних мереж була б необґрунтованою. Розумніший перший крок — оновити браузер, операційну систему й системні сервіси, а потім перевірити, чи не з’являються попередження про недовірений сертифікат під час відкриття знайомих сайтів.
Якщо браузер показує помилку перевірки сертифіката, не слід натискати кнопку продовження лише заради доступу до сторінки. Причиною може бути як некоректно налаштований легітимний сервер, так і спроба втручання у з’єднання. Особливо важливо не вводити пароль або платіжні дані на сторінці, справжність якої браузер не підтверджує. Для щоденного захисту залишаються актуальними менеджер паролів і двофакторна автентифікація, але вони не замінюють перевірки HTTPS.
Чому старі роутери й розумні пристрої потребують уваги
Не всі програми покладаються на оновлюваний браузерний список сертифікатів. Частина застосунків, контейнерів, вбудованих систем і пристроїв інтернету речей має власне сховище довірених центрів. Деякі клієнти взагалі не перевіряють відкликання сертифікатів під час кожного з’єднання. Тому блокування, яке швидко захистило Chrome, не обов’язково автоматично виправляє старий телевізор, мережевий накопичувач або давно не оновлюваний пристрій.
Для домашнього користувача практичні дії прості: перевірити оновлення прошивки маршрутизатора, мережевих камер та інших пристроїв, особливо тих, що мають доступ до особистих даних. Не варто самостійно видаляти сертифікати із системного сховища за випадковою інструкцією: це може порушити роботу інших сервісів. Якщо виробник давно припинив підтримку пристрою, обмеження його доступу до інтернету або заміна стають питанням загальної безпеки, а не лише інциденту eMudhra.
Що це означає для власників сайтів
У вебмайстрів є інше завдання: перевірити, хто видав сертифікат їхнього домену і через який ланцюжок довіри він проходить. Якщо сервер використовує корінь emSign ECC Root CA – G3, вилучення цього кореня з браузерних сховищ може спричинити помилки підключення. Це не означає, що кожен сертифікат eMudhra автоматично підроблений, але сайтам із відповідним ланцюжком потрібно своєчасно отримати заміну від довіреного центру.
eMudhra повідомила про згортання свого міжнародного бізнесу SSL/TLS-сертифікатів та перехід клієнтів на інші рішення. Для власника невеликого сайту важливо не експериментувати з невідомими сертифікатами, а звернутися до хостинг-провайдера або адміністратора, якщо моніторинг показує проблемний ланцюжок. Після заміни слід перевірити сайт із кількох браузерів і пристроїв, а також переконатися, що не зламалися піддомени та автоматичне поновлення.
Чому історія не завершилася після блокування
Браузери здатні швидко розповсюдити списки недовірених сертифікатів, але світ програм значно ширший за Chrome і Firefox. Бібліотеки перевірки TLS, мобільні застосунки, серверні компоненти й застарілі системи оновлюються з різною швидкістю. Саме тому експерти, яких цитує Ars Technica, наголошують на тривалому періоді очищення екосистеми. Особливо складно знайти програму, у якій копію списку довірених центрів вбудували багато років тому.
Паралельно виробники мають розібратися, як слабкі ключі пройшли процедури створення й аудиту. Виправлення наслідків без встановлення причини не виключає повторення помилки. Водночас немає підстав робити висновок, що всі сертифікаційні центри мають таку саму проблему: Google повідомила, що перевірила інші сертифікати у своєму сховищі та не знайшла аналогічного випадку. Це обмежує масштаб підтвердженої загрози.
Що перевірити сьогодні на своїх пристроях
На комп’ютері слід дозволити браузеру встановити актуальні оновлення, а на Android — перевірити оновлення браузера й Google Play services. Користувачам Firefox варто переконатися, що версія не старіша за випуски, у яких Mozilla закріпила блокування, особливо за нестандартних налаштувань. На старих пристроях корисно переглянути розділ оновлень системи. Якщо виробник не підтримує пристрій, не слід вважати його захищеним лише тому, що звичайні вебсторінки відкриваються без попереджень.
Головний висновок не в тому, що HTTPS перестав бути надійним. Навпаки, інцидент показав, навіщо існують незалежні перевірки, журнали сертифікатів і механізми швидкого відкликання довіри. Для більшості читачів достатньо своєчасних оновлень і уважності до попереджень браузера. Для адміністраторів сайтів та старих підключених пристроїв потрібна додаткова перевірка ланцюжків сертифікатів і програмних компонентів.
Джерела та права на ілюстрації
Основні незалежні джерела: Ars Technica, 20.10.2026, The Register, 22.10.2026 і The Register про вихід eMudhra з ринку, 22.10.2026. Першоджерела: повідомлення Mozilla від 20.10.2026 та публічні пояснення Chrome Root Program від 20.10.2026. Описані ризики не означають підтвердженого використання ключів у злочинних атаках.
Головне зображення: Google Chrome icon, автор Google, Wikimedia Commons, PD-simple/PD-textlogo; торговельна марка. Додаткова ілюстрація: Firefox logo and wordmark (2026), автор Mozilla Corporation, Mozilla Public License 2.0; торговельна марка. Зображення використано як позначення браузерів, а не як знімки уразливості.
