Инцидентът с eMudhra: осем ключа на удостоверители са били лесно отгатваеми — какво трябва да проверят сега притежателите на TLS сертификати

6 ноември 2026 г.  |  Сертификати  |  ИТ сигурност

През октомври 2026 г. стана известно, че индийският удостоверителен орган eMudhra е издал осем междинни сертификата (Intermediate CAs) с практически безполезни частни ключове. Частните ключове са били цели числа, по-малки от 256, а един от тях е бил буквално числото 4. Всеки, който знае такъв ключ, може да подписва сертификати за произволни домейни от името на удостоверителния орган. Затова производителите на браузъри реагираха в рамките на часове, блокираха междинните сертификати и премахнаха съответния коренов CA emSign ECC Root CA – G3 от списъците си с доверени удостоверителни органи.

Тази публикация обяснява какво точно се е случило, защо ключ „4“ означава пълен провал на сигурността, кой е засегнат — и кой не е — и какво трябва да проверят сега администраторите на уебсайтове, пощенски сървъри и защитни стени. Придържаме се строго към потвърденото от първоизточниците. В първоначалните публикации и в социалните мрежи се разпространяват и твърдения, които не отговарят на фактите. След малко ще разгледаме и тях.

Накратко: кое е вярно и кое не

Хронология на събитията

• 17 октомври 2026 г.: За инцидента е подаден сигнал до Mozilla (получен в 18:05 UTC според Bugzilla). Още в 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 изследователят по сигурността Scott Helme е открил ключа „4“. Проверените от нас първични източници не описват по какъв начин е установена грешката; всеки обаче може да провери за малки стойности на ключовете въз основа на публичните сертификати.

Кой е засегнат и кой не е?

Веригата се състои от три нива: коренов удостоверител, междинен удостоверител и краен сертификат на уебсайта или сървъра. Засегнато е средното ниво. От това следва:

• Ключовете на притежателите на сертификатите (ключът на вашия сървър) не са засегнати според всички източници, с които разполагаме. Не се налага да бъдат подменяни с аргумента, че са „известни“.
• 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 не са засегнати според компанията. Цифровите подписи, 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. Подменете засегнатите сертификати. Използвайте друг утвърден удостоверител или ACME (например Let’s Encrypt). При подмяната генерирайте и нов ключ за сървъра. Този инцидент не го налага, но при смяна на удостоверителя това така или иначе е добра практика.
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) и с наблюдение на вашите домейни. Като доставчик на ИТ услуги поддържаме сървъри, защитни стени и уебприложения за малки и средни предприятия.

Свържете се с нас сега

Актуално към 6 ноември 2026 г. Ситуацията може да се промени; определяща е информацията, публикувана от Mozilla, Google, Apple и eMudhra.