Інцыдэнт у eMudhra: восем ключоў цэнтра сертыфікацыі было элементарна адгадаць — што ўладальнікам TLS-сертыфікатаў трэба праверыць цяпер

6 лістапада 2026 г.  |  Сертыфікаты  |  ІТ-бяспека

У кастрычніку 2026 года стала вядома, што індыйскі цэнтр сертыфікацыі eMudhra выдаў восем прамежкавых сертыфікатаў (Intermediate CAs) з практычна бескарыснымі прыватнымі ключамі. Прыватныя ключы былі цэлымі лікамі, меншымі за 256, а адзін з іх быў літаральна лікам 4. Той, хто ведае такі ключ, можа падпісваць сертыфікаты для любых даменаў ад імя цэнтра сертыфікацыі. Таму распрацоўшчыкі браўзераў адрэагавалі на працягу некалькіх гадзін: заблакавалі прамежкавыя сертыфікаты і выдалілі адпаведны каранёвы CA emSign ECC Root CA – G3 са сваіх спісаў даверу.

Гэты артыкул тлумачыць, што менавіта адбылося, чаму ключ «4» азначае поўны крах бяспекі, каго гэта закранае — і каго не закранае — і што цяпер варта праверыць адміністратарам вэб-сайтаў, паштовых сервераў і міжсеткавых экранаў. Мы строга прытрымліваемся таго, што пацвярджаюць першакрыніцы. У першых публікацыях і сацыяльных сетках сустракаюцца таксама недакладныя апісанні. Пра гэта — крыху ніжэй.

Коратка: што праўда, а што не

Храналогія падзей

• 17 кастрычніка 2026 г.: Пра інцыдэнт паведамляюць Mozilla (паводле Bugzilla, паведамленне атрымана а 18:05 UTC). Ужо а 22:59 UTC блакаванне прамежкавых сертыфікатаў распаўсюджана праз OneCRL Mozilla, гэта значыць менш чым праз тры гадзіны пасля атрымання паведамлення Mozilla.
• 18 кастрычніка 2026 г.: eMudhra адклікае восем прамежкавых сертыфікатаў.
• 19 кастрычніка 2026 г.: Sectigo адклікае крос-сертыфікаты, якімі кампанія дадаткова падпісала восем прамежкавых CA.
• 20. Oktober 2026: Mozilla veröffentlicht Firefox 158.0.1, ESR 115.43.1 und ESR 153.5.1 sowie NSS 3.131.1. Damit wird die Root emSign ECC Root CA – G3 entfernt. Zwischen dem 20. und 21. Oktober tauchen in den Certificate-Transparency-Logs zudem 107.107 Zertifikate auf, die mit sechs der acht schwachen Schlüssel signiert wurden (siehe unten).
• 22 кастрычніка 2026 г.: eMudhra абвяшчае пра сыход з рынку публічных TLS-сертыфікатаў. Падпісанне кода і S/MIME працягваюць працаваць пад асобнымі каранёвымі сертыфікатамі.
• 27 кастрычніка 2026 г.: Chrome таксама выдаляе каранёвы CA.
• 16 і 30 лістапада 2026 г.: Канчатковыя тэрміны для старых сертыфікатаў G1 (Chrome/Mozilla і Apple адпаведна), якія, паводле eMudhra, маюць значэнне для пераходу закранутага аб’яднання кліентаў з ЗША.

Чаму прыватны ключ «4» азначае поўны крах бяспекі

Цэнтр сертыфікацыі (CA) сваім лічбавым подпісам пацвярджае, што сертыфікат належыць пэўнаму дамену. Браўзеры давяраюць гэтаму подпісу, пакуль CA знаходзіцца ў іх спісе даверу. Бяспека грунтуецца на тым, што прыватны ключ ведае толькі CA.

У сертыфікатах на аснове эліптычных крывых (ECDSA) прыватны ключ — гэта вельмі вялікі лік d. Публічны ключ — пункт Q = d · G на крывой (G — зададзены базавы пункт). Аднавіць лік d з Q практычна немагчыма, калі ён выпадкова выбраны і мае даўжыню 384 біты. Але калі d малы, напрыклад 4, дастаткова паслядоўна вылічыць 1·G, 2·G, 3·G, 4·G … і параўнаць вынікі з публічным пунктам. Гэта займае секунды і не патрабуе ніякіх спецыяльных ведаў.

Публічны ключ змяшчаецца ў кожным сертыфікаце, таму даступны кожнаму. Такім чынам, любы, хто выканае гэтыя разлікі, можа ствараць сертыфікаты, якія выглядаюць сапраўднымі, ад імя CA — для любых даменаў, пакуль браўзер яшчэ давярае гэтаму CA. Менавіта таму Mozilla і іншыя неадкладна ўвялі блакаванне.

Мы спампавалі восем прамежкавых сертыфікатаў, названых у Bugzilla, з публічных журналаў празрыстасці (crt.sh) паводле адбіткаў SHA-256 і для кожнага параўналі k · G з публічным пунктам пры k ад 1 да 1000. Усе восем сертыфікатаў маюць ключ P-384, і для ўсіх васьмі знойдзена супадзенне:

Значэнні супадаюць са звесткамі ў Bugzilla і публікацыях СМІ (у тым ліку The Register: адзін з ключоў быў «літаральна 4»). Мы нічога не падпісвалі і не выпускалі з выкарыстаннем гэтых значэнняў; разлікі служаць выключна для праверкі публічных сертыфікатаў.

Прычына паводле eMudhra

Паводле тлумачэння eMudhra ў Bugzilla, слабыя ключы ўзніклі падчас цырымоніі генерацыі ключоў 30 красавіка 2025 года. У межах узгодненага адступлення ад звычайнай працэдуры тады правялі тэст Wrap/Unwrap. Як паведамляецца, праз памылку ў кодзе ў прыладзе была створана другая пара са слабымі ключамі. Затым яе памылкова выкарысталі для стварэння запыту на сертыфікат, бо назвы ключоў былі падобныя. Пасля гэтага сертыфікаты выпусцілі, уключылі ў спісы даверу, і яны заставаліся там больш за год, пакуль памылка не стала публічна вядомай.

Паводле The Register, ключ «4» выявіў даследчык бяспекі Scott Helme. Правераныя намі першакрыніцы не апісваюць, якім метадам была выяўлена памылка; аднак праверыць малыя значэнні ключоў на аснове публічных сертыфікатаў можа кожны.

Каго гэта закранае, а каго не?

Ланцужок складаецца з трох узроўняў: каранёвы цэнтр сертыфікацыі, прамежкавы цэнтр сертыфікацыі і канцавы сертыфікат сайта або сервера. Праблема закранула сярэдні ўзровень. З гэтага вынікае:

• Ключы ўладальнікаў сертыфікатаў (ключ вашага сервера), паводле ўсіх наяўных у нас крыніц, не закрануты. Іх не трэба замяняць на той падставе, што яны нібыта сталі «вядомымі».
• Zertifikate, die unter der entfernten Root laufen, werden von Browsern nicht mehr akzeptiert. Sie müssen ersetzt werden, weil die Vertrauenskette weg ist, nicht weil der Server-Schlüssel schwach ist. Laut der Analyse des Chrome-Root-Programms (Stand 21.10.2026) betrifft das rund 30.800 noch gültige Zertifikate. 30.791 davon wurden von Unter-CAs von Internet2/InCommon ausgestellt, einem US-Verbund, der vor allem Hochschulen und Forschungseinrichtungen bedient. eMudhra spricht von einem einzigen Kundenverbund in den USA.
• Усіх астатніх кліентаў eMudhra, паводле eMudhra, праблема не закранула. Лічбавыя подпісы, eSign, emSigner, CertiNext, SecurePass, PrivaTrust і emCA працягваюць працаваць на асобнай інфраструктуры.

Таму для кліентаў у Германіі, Аўстрыі і Швейцарыі верагоднасць выкарыстання сертыфіката з гэтым каранёвым сертыфікатам невялікая. Але дакладна даведацца можна толькі пасля праверкі. Яна зойме некалькі хвілін — глядзіце кантрольны спіс.

Die 107.107 Zertifikate in den Transparenz-Logs

Nach dem Widerruf tauchten laut Bugzilla zwischen dem 20. und 21. Oktober 2026 107.107 Zertifikate in den Certificate-Transparency-Logs auf, die mit sechs der acht schwachen Schlüssel signiert wurden. Darunter sind nachweislich Proof-of-Concept-Zertifikate, etwa mit google.com als Namen. Die meisten davon laufen über die inzwischen widerrufenen Cross-Zertifikate von Sectigo.

Гэта паказвае дзве рэчы: па-першае, кожны з базавымі ведамі крыптаграфіі мог адразу скарыстацца памылкай; па-другое, гэта пацвярджае каштоўнасць журналаў празрыстасці, дзе такі выпуск сертыфікатаў бачны ўсім. Ці выкарыстоўваліся якія-небудзь з іх са зламыснымі мэтамі па-за межамі тэстаў, з наяўных у нас крыніц невядома, і мы гэтага не сцвярджаем.

Якія меры прынялі распрацоўшчыкі браўзераў і цэнтры сертыфікацыі

Паводле ўласнай заявы ў абмеркаванні на dev-security-policy, Mozilla не лічыць, што праблема закранула іншыя цэнтры сертыфікацыі.

Кантрольны спіс: што цяпер варта праверыць

1. Вызначце, хто выпусціў вашы сертыфікаты. На любым камп’ютары з OpenSSL:

   openssl s_client -connect ihre-domain.example:443 -servername ihre-domain.example </dev/null 2>/dev/null | openssl x509 -noout -issuer -dates

   Калі ў якасці выдаўца пазначаны eMudhra або emSign (напрыклад, «EM DV TLS CA – G3B» або «G3C»), праверце ўвесь ланцужок і каранёвы сертыфікат з дапамогай -showcerts. Калі ланцужок вядзе да emSign ECC Root CA – G3, сертыфікат трэба замяніць.
2. Праверце ўсе сэрвісы, а не толькі сайт. Паштовыя серверы (SMTPS, IMAPS), VPN-шлюзы, інтэрфейсы міжсеткавых экранаў, балансіроўшчыкі нагрузкі, унутраныя сэрвісы, прылады і апаратна-праграмныя комплексы з уласнымі сертыфікатамі.
3. Прагледзьце публічныя сертыфікаты для вашага дамена. Праз crt.sh (пошук па %.ihre-domain.example) вы ўбачыце ўсе сертыфікаты, выпушчаныя для вашага дамена, у тым ліку тыя, пра якія вы не ведаеце. Гэта добрая магчымасць выявіць непажаданы выпуск сертыфікатаў.
4. Betroffene Zertifikate ersetzen. Bei einer anderen, etablierten CA oder per ACME (z. B. Let’s Encrypt). Den Server-Schlüssel beim Austausch gleich neu erzeugen. Das ist keine Pflicht aus diesem Vorfall, aber bei einem Wechsel der CA ohnehin der saubere Weg.
5. Праверце сховішчы давераных сертыфікатаў на сваіх прыладах. Калі каранёвы сертыфікат eMudhra пастаянна прапісаны ў вашых прыладах, сховішчах ключоў Java, кантэйнерах або наборах сертыфікатаў, яго варта адтуль выдаліць. Браўзеры абнаўляюць свае сховішчы самастойна, а такія сховішчы аўтаматычна не абнаўляюцца.
6. Абнавіце Firefox. Блакіраванні ўключаны пачынаючы з версіі 158.0.1, а таксама ESR 115.43.1 / 153.5.1. На цэнтралізавана кіраваных працоўных станцыях праверце, ці ўсталёўваюцца абнаўленні.
7. Аўтаматызуйце. Калі вы кіруеце сертыфікатамі ўручную, варта перайсці на аўтаматычнае абнаўленне (ACME). Тады пераход да іншага цэнтра сертыфікацыі будзе зменай канфігурацыі, а не экстранай аперацыяй.

Якія высновы мы можам зрабіць

• Выбар цэнтра сертыфікацыі — гэта рашэнне, звязанае з рызыкай. Вырашальнае значэнне маюць празрыстасць, якасць працэсаў і ўдзел у праграмах каранёвых сертыфікатаў. Цана нічога пра гэта не кажа. Інцыдэнт паказвае памылку ў працэдуры падчас цырымоніі генерацыі ключоў, якая магла б здарыцца ў любым цэнтры сертыфікацыі.
• Certificate Transparency funktioniert. Die öffentlich einsehbaren Logs haben es ermöglicht, den Vorfall schnell einzugrenzen und die 107.107 Zertifikate zu erkennen.
• Крыптаграфічная гнуткасць сябе апраўдвае. Калі сертыфікаты абнаўляюцца аўтаматычна і можна змяніць цэнтр сертыфікацыі без ручнога ўмяшання ў дзясяткі сістэм, на ліквідацыю наступстваў такіх інцыдэнтаў хопіць аднаго працоўнага дня замест тыдня.
• Сачыце за сваімі даменамі. Маніторынг журналаў празрыстасці (напрыклад, праз crt.sh або сэрвісы з апавяшчэннямі па электроннай пошце) пакажа, калі хтосьці выпускае сертыфікаты для вашага дамена.
• Некалькі ўзроўняў абароны. TLS-сертыфікаты — толькі адзін узровень. Дадаткова дапамагаюць CAA-запісы ў DNS (яны вызначаюць, які цэнтр сертыфікацыі мае права выпускаць сертыфікаты для вашага дамена) і двухфактарная аўтэнтыфікацыя. Падрабязней — у нашым артыкуле Абарона Odoo 19: міжсеткавы экран, 2FA & Web RBL.

Частыя пытанні

Што менавіта адбылося ў eMudhra?

Восем прамежкавых сертыфікатаў цэнтра сертыфікацыі eMudhra мелі закрытыя ключы, якія ўяўлялі сабой цэлыя лікі менш за 256 (адзін з іх — лік 4). Дзякуючы гэтаму кожны мог вылічыць закрыты ключ па публічным сертыфікаце і падпісваць сертыфікаты, якія выглядалі сапраўднымі. Прамежкавыя цэнтры сертыфікацыі былі адкліканы, а каранёвы сертыфікат emSign ECC Root CA – G3 выдалены з Firefox (20.10.2026) і Chrome (27.10.2026).

Ці выдавала eMudhra закрыты ключ «4» кліентам?

Не. Слабыя ключы належалі прамежкавым сертыфікатам самога цэнтра сертыфікацыі. Яны не былі ключамі кліентаў і не выдаваліся кліентам. Сцвярджэнні ў сацыяльных сетках пра адваротнае гэтага не змяняюць.

Ці трэба мне як кліенту eMudhra неадкладна замяніць свой сертыфікат?

Nur, wenn Ihr TLS-Zertifikat über die Root emSign ECC Root CA – G3 läuft. Das betrifft nach Angaben von eMudhra einen einzelnen US-Kundenverbund mit rund 30.800 Zertifikaten. Für alle anderen Kunden ist laut eMudhra keine Maßnahme nötig. Prüfen Sie den Aussteller Ihres Zertifikats, bevor Sie handeln.

Як даведацца, ці закрануты мой сертыфікат?

Па выдаўцы і ланцужку: прагледзьце сертыфікат у браўзеры або скарыстайцеся камандай OpenSSL з кантрольнага спіса. Назвы накшталт «EM DV TLS CA – G3B», «EM OV TLS CA – G3C» або «emSign ECC Root CA – G3» паказваюць на закрануты ланцужок.

Ці трэба замяняць закрыты ключ майго сервера?

Не з прычыны гэтага інцыдэнту. Паводле крыніц, ключ сервера не закрануты. Аднак пры неабходнай замене сертыфіката ўсё ж рэкамендуецца стварыць новы ключ.

Ці могуць зламыснікі ствараць падробленыя сертыфікаты для майго дамена?

З дапамогай гэтых васьмі ключоў тэхнічна можна было падпісваць сертыфікаты для любых даменаў. Гэта працавала толькі да таго часу, пакуль браўзеры давяралі ланцужку. Пасля блакіраванняў з боку Mozilla і Chrome у актуальных версіях браўзераў гэта ўжо немагчыма. На прыладах, якія не абнаўляюцца або ў якіх каранёвы сертыфікат пастаянна прапісаны, рызыка можа захоўвацца даўжэй. Таму сачыце за сертыфікатамі для свайго дамена.

Ці закрануты сертыфікаты Let’s Encrypt або іншых цэнтраў сертыфікацыі?

Паводле апублікаваных крыніц — не. Mozilla не лічыць, што праблема закранула іншыя цэнтры сертыфікацыі.

Што азначае выхад eMudhra з бізнесу TLS-сертыфікатаў?

eMudhra больш не выпускае новых публічных TLS-сертыфікатаў. Падпісванне кода, S/MIME, лічбавыя подпісы і eSign працягваюць працаваць. Тым, хто дагэтуль атрымліваў TLS-сертыфікаты ад eMudhra, патрэбны новы пастаўшчык.

Ці закрануты Odoo?

Сам Odoo — не. Аднак, як і для любога вэб-прыкладання, TLS-сертыфікат вашага дамена Odoo павінен быць выпушчаны надзейным цэнтрам сертыфікацыі. Праверце выдаўца, асабліва калі сертыфікаты не абнаўляюцца аўтаматычна.

Крыніцы

Дата доступу: 6 лістапада 2026 года:

• Mozilla Bugzilla, памылка 2083449 (справаздача аб інцыдэнце, храналогія, адбіткі сертыфікатаў): bugzilla.mozilla.org/show_bug.cgi?id=2083449
• Mozilla Security Blog, 20.10.2026: Абарона карыстальнікаў Firefox пасля кампраметацыі прамежкавых сертыфікатаў eMudhra
• eMudhra, заява: emudhra.com/en/post/certificate-security-incident
• The Register, 20.10.2026: Закрытыя ключы індыйскага цэнтра сертыфікацыі eMudhra скампраметаваны, адзін з іх быў лікам 4
• Mozilla dev-security-policy: Галіна абмеркавання інцыдэнту
• Пошук у Certificate Transparency: crt.sh

Значэнні васьмі ключоў мы самастойна вылічылі на аснове публічных сертыфікатаў. Звесткі пра прычыну інцыдэнту, пра тое, што канцавыя сертыфікаты не выпускаліся, і пра колькасць закранутых кліентаў паходзяць ад eMudhra або з Bugzilla і не былі незалежна правераны намі.

Падтрымка ад Biricon IT Services

Калі вы не ўпэўнены, хто выпусціў вашы TLS-сертыфікаты, мы ахвотна дапаможам: з інвентарызацыяй усіх сертыфікатаў на вэб-серверах, паштовых серверах, міжсеткавых экранах і апаратна-праграмных комплексах, з пераходам да іншага цэнтра сертыфікацыі, з наладжваннем аўтаматычнага абнаўлення (ACME) і з маніторынгам вашых даменаў. Як пастаўшчык ІТ-паслуг, мы абслугоўваем серверы, міжсеткавыя экраны і вэб-прыкладанні малых і сярэдніх прадпрыемстваў.

Jetzt Kontakt aufnehmen

Станам на 6 лістапада 2026 года. Сітуацыя можа змяніцца; арыентуйцеся на публікацыі Mozilla, Google, Apple і eMudhra.