Kontrola formátu nic neříká o tom, jestli je tajemství tajné
V dubnu 2025 vzniklo osm intermediate certifikačních autorit eMudhry, šest pro TLS a dvě pro podepisování kódu. V květnu je křížově podepsal kořen Sectigo. V říjnu 2026 výzkumník zjistil, že jejich soukromé klíče jsou čísla jako 4, 56 nebo 115. Scott Helme je všechny dopočítal za méně než sekundu. Veřejné klíče přitom vypadaly naprosto validně, takže žádná běžná kontrola certifikátu nemohla nic poznat.
Bezpečnost eliptické křivky je jen předpoklad o náhodnosti
U křivky P-384 je soukromý klíč číslo d a veřejný klíč je bod d × G. Zpětně spočítat d je nemožné jen za předpokladu, že d je velké náhodné 384bitové číslo. Matematika křivky to nijak nevynucuje. Pro d = 56 dostaneš úplně normální bod na křivce, správně zakódovaný a se správnou délkou.
Útok je proto triviální: zkoušíš 1 × G, 2 × G a dál, dokud nenarazíš na zveřejněný bod. U klíče, který se vejde do jednoho bajtu, to je nejvýš 255 kroků. Podle eMudhry chyba vznikla ve skriptu pro generování klíčů. Skript vytvořil v HSM druhý, slabý pár klíčů a člověk kvůli podobným názvům použil pro žádost o certifikát ten špatný.
Obecné poučení přesahuje kryptografii. Validace tvaru dat ti potvrdí, že hodnota je dobře zformovaná. Nepotvrdí, že splňuje předpoklad, na kterém stojí bezpečnost. Entropii musíš ověřovat zvlášť, nejlépe v místě, kde klíč vzniká.
Nic neuniklo, a přesto se to nedá uzavřít
Klasický incident má okamžik krádeže. Tady žádný nebyl. Klíč byl fakticky veřejný od chvíle, kdy certifikát existoval, a kdokoli ho mohl dopočítat kdykoli během zhruba sedmnácti měsíců. Nikdo nemůže zjistit, jestli to někdo udělal.
Chrome a Firefox intermediate certifikáty zablokovaly do několika hodin a navíc vynucují Certificate Transparency. V logech CT se žádné certifikáty od těchto autorit neobjevily, takže prohlížeče jsou na tom dobře. Jenže CT chybné vydání certifikátu odhalí, nezabrání mu. A většina klientů mimo prohlížeč CT nekontroluje vůbec.
Revokace chrání jen toho, kdo se ptá
Typický klient mimo prohlížeč důvěřuje CA bundlu na disku, revokaci ve výchozím stavu nekontroluje a CT taky ne. V Helmeho testech na Linuxu a macOS přijaly curl, Python i Node podvržený certifikát pro api.stripe.com s výchozím nastavením. Na Windows ho CryptoAPI přijalo, pokud nebyla zapnutá kontrola revokace.
Ohrožené jsou tedy přesně ty cesty, kterým se nevěnuje pozornost: instalátory přes curl | sh, CI/CD pipeline, volání API mezi servery, IoT zařízení se zamrzlým úložištěm důvěry a podepisování kódu na Windows. Pomůže jen aktualizace CA bundlu v systému, v runtime jazyka a v kontejnerových image. Zařízení, která aktualizovat nejdou, zůstanou otevřená až do expirace certifikátů.
Co si z toho odnést
Bezpečnostní vlastnost, kterou nelze vyčíst z tvaru dat, musíš ověřit v místě vzniku. Na straně příjemce už ji nikdo nezkontroluje. A zjisti, odkud tvoje služby a pipeline berou důvěryhodné certifikáty. Bundle zabalený v Docker image nebo v balíčku certifi se neaktualizuje tím, že Chrome něco zablokoval. Revokace je mechanismus pro klienty, kteří se ptají. Tvůj backend se nejspíš neptá.