Máte na e-shopu platební bránu? Po incidentu eMudhra hrozí útoky

Aktualizováno: 23.10.2026, Zabere vám 12 minut času S pomocí AI

Indická certifikační autorita eMudhra vygenerovala tak slabé klíče k osmi svým certifikátům, že je kdokoliv dokáže prolomit za méně než sekundu. Koho se incident týká a jak se ujistit, že je vaše zařízení v bezpečí? Zpozornět byste měli i tehdy, když máte web, e-shop nebo aplikaci a server vám spravuje někdo jiný. Pro vývojáře přidáváme postup, který jsme sami použili na našich serverech i v aplikacích zákazníků.

Co se stalo a k čemu je certifikát?

Osm zprostředkujících certifikátů eMudhra má prolomené klíče, takže kdokoliv s nimi mohl vydat důvěryhodně vypadající certifikát pro cizí web.

Když otevřete web banky, e-shopu nebo e-mailu, prohlížeč s ním naváže šifrované spojení (HTTPS). Než odešle vaše heslo nebo číslo karty, potřebuje vědět, že na druhé straně je opravdu ten web, a ne někdo, kdo se za něj vydává. K tomu slouží certifikát. Je to digitální průkaz webu, který potvrzuje, že server vydávající se za facebook.com opravdu patří Facebooku.

Když je certifikát v pořádku, uvidíte vedle adresy zámeček. Když není, prohlížeč ukáže varování a web neotevře. Stejně to funguje v aplikacích v telefonu, jen tam zámeček nevidíte.

Kdo certifikáty vydává

Průkaz si web nemůže vystavit sám. Vydává ho certifikační autorita, tedy firma, které výrobci prohlížečů a operačních systémů věří, třeba právě eMudhra.

Každá autorita má dvojici klíčů. Privátním klíčem se autorita podepisuje a ten musí zůstat tajný. Veřejným klíčem může kdokoli ověřit, že je podpis opravdu její.

Certifikát je vlastně veřejný klíč a k němu údaje o tom, komu patří, do kdy platí a k čemu slouží. Důvěra se předává po řetězci takto:

Kořenový (root) certifikát autority je předem uložený ve vašem telefonu, počítači nebo prohlížeči v seznamu důvěryhodných certifikátů. Zařízení s ním jen ověřuje podpisy. Privátní klíč certifikační autority neuvidí.
Zprostředkující (intermediate) certifikát podepíše autorita svým privátním klíčem. Zprostředkovatel má vlastní dvojici klíčů a jeho certifikát obsahuje jeho veřejný klíč. Zařízení tak věří i všemu, co zprostředkovatel podepíše. Autorita díky tomu drží privátní klíč bezpečně stranou a certifikáty webům vydávají právě zprostředkovatelé.
Certifikát webu podepíše zprostředkovatel svým privátním klíčem, když ověří, že web patří tomu, kdo o certifikát žádá.

Když otevřete web, zařízení zkontroluje, že certifikát webu podepsal zprostředkovatel a jeho certifikát podepsala autorita, které věří. Pak ukáže zámeček.

Co se pokazilo u eMudhra

U osmi zprostředkujících certifikátů eMudhra byly klíče tak slabé, že je šlo uhodnout. Podle The Register byl jedním z nich doslova číslo „4". Kdo klíč zná, může vydat certifikát pro jakýkoliv web a zařízení mu uvěří, protože řetězec vede k důvěryhodnému kořenovému certifikátu. Podvržený web by pak v prohlížeči, který o blokaci neví, ukázal stejný zámeček jako ten pravý.

Někde útok stále hrozí

Útočníci mohou pomocí prolomených klíčů vyrobit platně vypadající HTTPS certifikát pro libovolnou doménu a pokusit se o útok typu man-in-the-middle. Google, Mozilla, Apple a Microsoft postižené certifikáty do tří dnů zablokovali, takže aktualizované prohlížeče a telefony jim už nevěří. Servery, Docker kontejnery a aplikace, které samy volají cizí služby (API), ale zůstávají zranitelné, dokud jim někdo neaktualizuje seznam důvěryhodných certifikátů.

Chrome navíc od 27. října přestane přijímat certifikáty, které vedou ke kořenovému certifikátu emSign ECC Root CA - G3. Weby s takovým certifikátem ho musí vyměnit, jinak návštěvníci uvidí místo webu varování.

Víc o průběhu incidentu najdete na emudhra.we-have-a-problem.com a v hlášení v Bugzille Mozilly.

Pro běžné uživatele: Jak se mě to může dotknout?

Ohrožené jsou aplikace v telefonu a v počítači, které postiženým certifikátům pořád věří. Útočník, který se dostane mezi takovou aplikaci a její server, čte všechno, co si posílají. Vidí vaše jméno a heslo při přihlášení, osobní údaje, objednávky i zprávy. Z přihlášení si vezme i přístup k vašemu účtu, takže za vás může posílat zprávy, měnit nastavení nebo objednávat, dokud se neodhlásíte nebo nezměníte heslo.

Útočník ale musí ovládat síť, přes kterou se připojujete. Nejsnáz se mu to podaří na veřejné Wi-Fi, třeba na letišti nebo v kavárně.

Neznamená to, že je ohrožená každá aplikace. Některé mají ochranu navíc. WhatsApp nebo Signal šifrují zprávy přímo mezi telefony, takže jejich obsah útočník nepřečte. Řada bankovních aplikací zase přijme jen certifikát svého vlastního serveru. Aktuální prohlížeč podvržený certifikát odmítne, protože výrobci postižené certifikáty zablokovali.

Podle Googlu se navíc žádný podvržený certifikát neobjevil v Certificate Transparency, veřejném seznamu vydaných certifikátů, který vyžadují Chrome a Safari.

Co udělat na svých zařízeních

Pokud používáte aktuální Chrome, Firefox, Safari nebo jiný prohlížeč postavený na Chromu, jste při procházení webů v bezpečí. Blokace do prohlížečů dorazila automaticky.

Prohlížeč ale chrání jen sebe. Ostatní aplikace a programy spoléhají na certifikáty operačního systému, a ty opraví až aktualizace systému. Na svých zařízeních proto udělejte tohle:

Android: oprava přišla přes Google Play Services 19. října. Většina zařízení ji má automaticky, restart telefonu ji vynutí hned. U zařízení bez služeb Google (některé telefony Huawei, televize, auta) jsme spolehlivý údaj nenašli. Počítejte s tím, že chráněná nejsou, a nepřihlašujte se na nich přes veřejnou Wi-Fi.
iPhone, iPad, Mac: podle přehledu incidentu Apple certifikáty zablokoval 19. října. Nainstalujte dostupné aktualizace a zařízení restartujte.
Windows: podle přehledu incidentu přišla blokace 20. října přes automatickou aktualizaci seznamu důvěryhodných certifikátů. Microsoft k incidentu oficiální oznámení nevydal. Spusťte Windows Update.

Je můj prohlížeč zranitelný?

Jestli váš prohlížeč podvrženým certifikátům ještě věří, ověříte na stránce emudhra.we-have-a-problem.com. Klikněte na tlačítko pro spuštění kontroly. U všech 12 testů by se mělo objevit „Did not connect“. To znamená, že prohlížeč prolomeným certifikátům odmítl věřit. Test platí jen pro prohlížeč, ve kterém ho spustíte.

Aplikace v telefonu

Mobilní aplikace nejdou přes prohlížeč, se svým serverem komunikují napřímo. Pokud aplikace používá certifikáty systému, ochrání ji i systémová aktualizace, která prolomené certifikáty blokuje. Pokud si nese vlastní seznam certifikátů, může zůstat zranitelná i po aktualizaci systému.

Jako uživatelé většinou nemáte jednoduchý způsob, jak zjistit, jaké certifikáty aplikace používá. Nejjistější je proto mít telefon i aplikace aktualizované, hlavně ty, které pracují s citlivými daty.

Co dělat, když web nebo e-shop nespravujete sami

Máte web, e-shop nebo aplikaci a technickou stránku za vás řeší vývojář, agentura nebo hosting? Sami nic instalovat nemusíte, ale zeptejte se jich na dvě věci.

Vede certifikát webu ke kořenovému certifikátu emSign?

Podle analýzy Chrome Root Program existuje přes 30 800 platných certifikátů, které vedou ke kořenovému certifikátu emSign ECC Root CA - G3. Většinu vydala americká služba InCommon, přes kterou si certifikáty pořizují univerzity. Od 27. října je Chrome přestane přijímat a návštěvníci uvidí místo webu varování.

Google provozovatelům vzkazuje, že certifikát musí okamžitě vyměnit za certifikát od jiné autority. Ke kterému kořenovému certifikátu váš certifikát vede, uvidíte v prohlížeči v detailu certifikátu (ikona vedle adresy webu), nebo se zeptejte toho, kdo vám certifikát vydal.

Věří váš server ještě postiženým certifikátům?

Většina webů a e-shopů komunikuje s dalšími službami. Typicky volá platební brány, přihlášení přes Google nebo Facebook nebo reklamní a analytická API. Ve chvíli, kdy se váš server ptá jiné služby, je sám v roli klienta a musí poznat, jestli mluví se správnou protistranou. Pokud pořád věří postiženým certifikátům, útočník v síti mezi serverem a třeba platební bránou může číst a měnit, co si posílají.

Pro vývojáře

Prohlížeče jsou opravené, ale curl, Java, Node.js, Python, PHP i Docker image musíte aktualizovat a ověřit každý zvlášť. Níže je postup pro jednotlivá prostředí a test, kterým vaši opravu ověříte.

Rozdíly proti prohlížečům

Na rozdíl od prohlížečů většina TLS klientů, jako curl, PHP, Python, Node.js, Go nebo Java, ve výchozím nastavení prostě věří certifikátům na disku nebo ve svém úložišti důvěryhodných certifikátů (trust store).

Nevyžadují Certificate Transparency a nekontrolují oznámení o zneplatnění certifikátů. Bezpečnostní výzkumník Scott Helme si to vyzkoušel: curl, Python i Node s výchozím nastavením přijaly podvržený certifikát pro api.stripe.com.

Podle odborníků, které cituje Ars Technica, zůstanou nejdéle zranitelná IoT zařízení (chytrá zařízení připojená k internetu), zapomenuté linuxové stroje, Docker kontejnery a nástroje s vlastní kopií certifikátů. Některé postižené certifikáty mají platnost až do roku 2039.

Seznam opravených verzí

Opravené verze jednotlivých systémů a knihoven průběžně sbírá tabulka na we-have-a-problem.com. Pro nejčastější prostředí (uvedená verze nebo novější):

Ubuntu ca-certificates: 20260816ubuntu0.22.04.1, 20260816ubuntu0.24.04.1, 20260816ubuntu0.26.04.1
Debian ca-certificates: 20250419~deb12u2 (bookworm), 20250419+deb13u1 (trixie)
Alpine ca-certificates: 20261020-r0
Node.js: 22.23.4, 24.22.1, 26.12.1
Go: 1.27.3, 1.26.10, balíček x509roots/fallback z 20. října
Python certifi: 2026.10.19
Java (OpenJDK, Oracle): 25.0.5.0.2, 21.0.13.0.2, 17.0.21.0.2, 11.0.33.0.2, 8u511 (OpenJDK advisory)
PHP composer/ca-bundle: 1.4.16, 1.6.0

Ubuntu server

Na serverech s Ubuntu je potřeba aktualizovat balíček s certifikáty. Nejdřív nanečisto, abyste viděli, co se změní:

sudo apt-get update
sudo apt-get --simulate install --only-upgrade --no-remove --no-install-recommends ca-certificates

Pak naostro:

sudo apt-get install --only-upgrade --no-remove ca-certificates

Verzi ověříte příkazem apt-cache policy ca-certificates a porovnáte se seznamem opravených verzí výše.

Běžící procesy si nový soubor nemusí načíst hned. OpenSSL načítá certifikáty při vytvoření spojení a libcurl si je ve výchozím nastavení drží až 24 hodin. Dlouho běžící služby, workery a fronty je proto bezpečnější restartovat.

Docker a Java

V kontejnerech nestačí aktualizovat hostitelský server, protože každý image si nese vlastní certifikáty. Image je potřeba sestavit znovu z aktuálního základu a kontejnery spustit nanovo:

docker build --pull --no-cache -t moje-aplikace .
docker compose up -d --force-recreate

Bez --no-cache může Docker použít starou vrstvu, ve které zůstal neopravený balíček. Jak se s certifikáty chová PHP v kontejneru, popisuje sekce o PHP.

Java s vlastním seznamem certifikátů

Java typicky nepoužívá systémové certifikáty, ale vlastní soubor lib/security/cacerts. Nestačí proto opravit certifikáty na serveru ani v Docker kontejneru. Nejjednodušší cesta je přejít na opravené JDK (Java Development Kit, tedy instalaci Javy, se kterou aplikace běží) ze seznamu výše.

Oficiální image eclipse-temurin:21-alpine měl 22. října systémové certifikáty už opravené, ale pořád neopravenou Javu 21.0.12.1. Náš test proti testovacímu serveru dv-g3b-emudhra s podvrženým řetězcem v něm skončil výsledkem TRUSTED: Java podvrženému certifikátu pořád věřila.

Jedna z Java aplikací, které provozujeme, komunikuje s Facebookem. Při její opravě jsme nečekali na vydání opraveného JDK. Při sestavování image jsme z java trust storu odebrali kořenové certifikáty, přes které Java postiženým intermediate certifikátům věřila. Jejich seznam je v souborech impacted-intermediates.json a roots.json. Image pustíme do registru, jen když v něm Java odmítne všech 12 testovacích řetězců.

Kdybyste se vydali podobnou cestou, dejte si pozor: odebrání kořenového certifikátu AAA Certificate Services od Sectigo může rozbít i legitimní služby, které přes něj vedou. Ať zvolíte kteroukoliv cestu, otestujte, že vaše aplikace dál dosáhne na všechny potřebné služby.

PHP

PHP většinou používá certifikáty systému, takže stačí opravený image a nový kontejner. To platí i pro výchozí nastavení frameworků Laravel a Symfony. Výjimkou jsou aplikace s vlastním souborem certifikátů. Oficiální image php:8.5-fpm-bookworm a php:8.5-fpm-alpine mají opravené systémové certifikáty uvnitř kontejneru od 21., resp. 22. října.

Pokud vaše aplikace používá balíček composer/ca-bundle, aktualizujte ho na verzi 1.4.16 nebo 1.6.0.

Jak ověřit, že je oprava účinná

Oprava funguje, když se klient k oběma testovacím serverům odmítne připojit kvůli certifikátu. Servery dv-g3b-emudhra.we-have-a-problem.com a dv-g3b-aaa-emudhra.we-have-a-problem.com používají podvržený řetězec. Pokud selže jen DNS nebo vyprší časový limit, test nic neříká.

Spusťte příkaz uvnitř kontejneru nebo na serveru:

for h in dv-g3b-emudhra.we-have-a-problem.com dv-g3b-aaa-emudhra.we-have-a-problem.com; do
  curl -sS --connect-timeout 10 -o /dev/null "https://$h/"
  echo "$h curl_exit=$?"
done

Správný výsledek je chyba curl: (60) a curl_exit=60 u obou adres. Kód 0 znamená, že klient podvrženému certifikátu věří - to je špatný výsledek.

Test přes curl ale ověřuje jen curl. Java, Node nebo Python mají vlastní cestu k certifikátům a vlastní HTTP klienty. Jak upozorňuje Cloudflare, úspěšný test v jednom nástroji neznamená, že je chráněná i jiná služba běžící na pozadí. Ověřujte proto přímo v tom prostředí (Java, Node.js, Python, PHP), které vaše aplikace používá: z aplikace nebo jejího kontejneru otevřete HTTPS spojení na stejné dvě adresy. Správný výsledek je i tady chyba certifikátu.

A nakonec: checklist, pokud se to týká vaší firmy

Hlavní prohlížeče a operační systémy certifikáty zablokovaly během tří dnů. Na serverech a v kontejnerech to potrvá týdny a u zařízení, která nikdo neaktualizuje, roky. Pro firmu z toho plynou tři úkoly, které můžete rovnou předat vývojáři nebo správci:

Zkontrolujte, jestli váš web nemá certifikát pod kořenovým certifikátem emSign ECC Root CA - G3, a pokud ano, vyměňte ho hned. Chrome ho přestane přijímat 27. října, Mozilla datum zatím nezveřejnila.
Aktualizujte certifikáty na serverech a znovu sestavte Docker image. Pokud opravená verze základního image ještě nevyšla, upravte certifikáty v image sami, jako jsme to udělali u Javy.
Ověřte každý runtime zvlášť, protože Java a další jazyky mají vlastní seznam certifikátů. To, že curl certifikáty odmítá, neznamená, že Java taky.

Pokud si nejste jistí, jestli jsou vaše aplikace zranitelné, rádi to s vámi projdeme. Napište nám nebo se podívejte, jak vyvíjíme a spravujeme aplikace.

Zdroje