Přejít na obsah

AktuálněKritické chyby v PHP a Node.js z 21. 10. Týkají se i vás?Otestovat verzi

Kontrola SSL certifikátu

Co se dá o SSL certifikátu zjistit zvenčí?

Krátká odpověď

Jedním TLS spojením na port 443 se dá přečíst celá vizitka certifikátu: kdo ho vydal, pro která doménová jména platí, odkdy dokdy, jak silný má klíč a jaká verze protokolu se při spojení použila. Tegmia právě to dělá — jedno navázané spojení a nejvýše jedno druhé, které zkouší zastaralé verze TLS, žádný požadavek na obsah webu — a hlásí čtyři věci: certifikát není od důvěryhodné autority, neplatí pro tuto doménu, má slabý klíč, nebo server stále přijímá zastaralé verze TLS.

Patří do kontroly Certifikát a TLS.

Co to je

Certifikát je potvrzení, že veřejný klíč patří k danému doménovému jménu. Vydává ho certifikační autorita, které prohlížeč věří, a prohlížeč při každém spojení ověří tři věci: platnost v čase, důvěryhodnost vydavatele a to, že jméno v certifikátu odpovídá adrese v řádku prohlížeče.

Když neprojde cokoli z toho, prohlížeč nezobrazí web, ale varovnou stránku. Pro návštěvníka vypadá chyba konfigurace stejně jako skutečný útok — nemá jak je rozlišit.

Certifikát neříká nic o tom, kdo web provozuje a jak se chová. Potvrzuje jen šifrované spojení se správným jménem.

Jak to Tegmia měří

Co kontrola skutečně dělá, s prahy, na kterých hlásí nález.

  • Navážeme jedno TLS spojení na port 443. Žádný požadavek po něm neposíláme, takže se nestahuje obsah webu.
  • Spojení jde na IP adresu, kterou jsme předtím přeložili a ověřili jako veřejnou; jméno domény posíláme jen jako SNI. Adresa, kterou jsme ověřili, je ta, na kterou se připojíme.
  • Ověřování certifikátu v socketu záměrně nevynucujeme — vadný certifikát musíme umět přečíst, abychom ho mohli popsat. Platnost pak vyhodnocujeme sami a výsledek ověření si ukládáme jako důkaz.
  • Z certifikátu čteme vydavatele, subjekt, doménová jména (SAN, prvních 25), platnost od a do, počet bitů klíče, křivku u ECDSA, odtisk SHA-256 a dohodnutý protokol a šifru.
  • Soulad jména řeší standardní ověření identity serveru z Node.js. Když neprojde, hlásíme tls.hostname_mismatch a do důkazu uvedeme, pro která jména certifikát platí.
  • Vlastnoručně podepsaný certifikát poznáme z chyby ověření a hlásíme tls.self_signed.
  • Jinou chybu ověření (chybí mezilehlý certifikát, vypršel certifikát autority v řetězci, nedůvěryhodná autorita, certifikát ještě neplatí) hlásíme jako tls.chain_untrusted s kódem chyby, jak ho ověření vrátilo.
  • Slabý klíč je RSA pod 2048 bitů nebo ECDSA pod 224 bitů; hlásíme tls.weak_key s naměřenou hodnotou.
  • Zastaralý protokol zjišťujeme jedním spojením navíc, omezeným nejvýš na TLS 1.1. Když se spojení dokončí, server staré verze stále přijímá a hlásíme tls.legacy_protocol_supported. Když ho server odmítne upozorněním protokolu TLS, staré verze nepřijímá. Když spojení vyprší, server ho bez odpovědi zavře nebo na to naše vlastní prostředí nemá, odpověď nemáme a nepředstíráme ji: dřívější zjištění necháme, jak je.

Co tím nezměříme

  • Nehodnotíme sadu šifer a nedáváme známku. Na to je SSL Labs a dělá to lépe.
  • Neověřujeme odvolání certifikátu (OCSP ani CRL).
  • Kontrolujeme port 443 na zadané doméně. Jiné porty, jiné služby a subdomény jsou samostatné cíle.

Co v katalogu není a proč

Mezeru je lepší přiznat než zakrýt nálezem, kterému nelze věřit.

Zastaralý podpisový algoritmus (SHA-1) zatím nehlásíme, i když pravidlo tls.weak_signature v katalogu je. Důvod je prozaický: node:tls podpisový algoritmus nevystavuje a muselo by se parsovat DER. Pravidlo je proto vedené jako plánované, ne jako hotové.

Co z toho může vzejít za zjištění

Přímo z katalogu. Stejný text uvidíte i v hlášení.

Certifikát není vydaný důvěryhodnou autoritou

Vysoké

tls.self_signed · Certifikát a TLS

Vlastnoručně podepsaný certifikát nikdo zvenčí neověří. Pro veřejnou službu to znamená trvalé varování v prohlížeči.

Co udělat: Nasaďte certifikát od veřejné certifikační autority. Pro běžný web stačí bezplatná varianta přes ACME.

Výchozí závažnost vysoké: Naplánujte do týdne. Výrazně zvyšuje šanci na úspěšný útok. Celé pravidlo v katalogu

Certifikát se nedá ověřit až k důvěryhodné autoritě

Vysoké

tls.chain_untrusted · Certifikát a TLS

Server obvykle neposílá mezilehlý certifikát nebo posílá už vypršelý, certifikát vydala autorita, které prohlížeče nevěří, případně certifikát ještě neplatí. Běžné prohlížeče chybějící mezilehlý certifikát často dohledají samy. Aplikace v telefonu a služby, které se k webu připojují automaticky, to dělat nemusí a spojení odmítnou.

Co udělat: Nasaďte na server celý aktuální řetězec: certifikát i mezilehlé certifikáty, které autorita vydává teď (u Let’s Encrypt soubor fullchain.pem, ne cert.pem). Certifikát, který ještě neplatí, nasaďte až od začátku jeho platnosti, nebo si nechte vystavit nový.

Výchozí závažnost vysoké: Naplánujte do týdne. Výrazně zvyšuje šanci na úspěšný útok. Celé pravidlo v katalogu

Certifikát neplatí pro tuto doménu

Vysoké

tls.hostname_mismatch · Certifikát a TLS

Jméno v certifikátu neodpovídá adrese, na které služba běží. Prohlížeč zobrazí varování a návštěvník nepozná rozdíl mezi chybou konfigurace a skutečným útokem.

Co udělat: Nechte vystavit certifikát, který obsahuje tuto doménu (nebo ji doplňte do SAN u stávajícího). Zkontrolujte i přesměrování mezi variantou s www a bez www.

Výchozí závažnost vysoké: Naplánujte do týdne. Výrazně zvyšuje šanci na úspěšný útok. Celé pravidlo v katalogu

Slabý klíč certifikátu

Střední

tls.weak_key · Certifikát a TLS

RSA klíč pod 2048 bitů nesplňuje současná doporučení a prohlížeče ho postupně přestávají přijímat.

Co udělat: Při příští obnově vystavte certifikát s RSA 2048+ nebo ECDSA P-256.

Výchozí závažnost střední: Naplánujte do měsíce. Samo o sobě nestačí k útoku, ale usnadňuje ho. Celé pravidlo v katalogu

Server stále přijímá zastaralé TLS 1.0 nebo 1.1

Střední

tls.legacy_protocol_supported · Certifikát a TLS

Staré verze protokolu mají známé slabiny a jejich podpora je častý nález v auditech i v bezpečnostních dotaznících od zákazníků.

Co udělat: Na webovém serveru nebo load balanceru povolte jen TLS 1.2 a 1.3. Před vypnutím zkontrolujte, že se nepřipojují staré firemní aplikace.

Výchozí závažnost střední: Naplánujte do měsíce. Samo o sobě nestačí k útoku, ale usnadňuje ho. Celé pravidlo v katalogu

Typická chybná konfigurace

Certifikát bez varianty s www, nebo naopak. Vystaví se na „vasedomena.cz“, web běží i na „www.vasedomena.cz“ — a tam prohlížeč hlásí, že certifikát pro tu adresu neplatí. Vzniká to tím, že obě varianty vedou na stejný server a všechno vypadá v pořádku, dokud někdo nenapíše tu druhou.

Druhá situace: certifikát se obnoví, ale nasadí se jen na jeden server ze dvou za load balancerem. Polovina návštěvníků pak vidí varování a druhá ne, podle toho, kam je spojení pustí.

Jak to opravit

Konkrétní kroky v pořadí, ve kterém mají smysl.

  1. 01Otevřete web ve variantě s www i bez www a v prohlížeči se podívejte na detail certifikátu — jméno v něm musí obě varianty pokrývat.
  2. 02Chybějící jméno nechte doplnit do certifikátu (SAN) a znovu vystavit. U certifikátu přes ACME stačí doplnit doménu do konfigurace.
  3. 03Vlastnoručně podepsaný certifikát na veřejné službě vyměňte za certifikát od veřejné autority. Pro běžný web stačí bezplatná varianta přes ACME.
  4. 04U klíče pod 2048 bitů RSA nechte při nejbližší obnově vystavit RSA 2048 nebo ECDSA P-256.
  5. 05Zastaralé TLS 1.0 a 1.1 vypněte na serveru nebo na load balanceru. Před tím zkontrolujte, že se nepřipojují staré firemní aplikace, které novější verzi neumějí.
  6. 06Po každé obnově ověřte certifikát na všech serverech, které doménu obsluhují, ne jen na jednom.

Zkontrolovat to na své doméně

Čteme jen to, co doména zveřejnila.

Sken přečte veřejné záznamy a konfiguraci domény a ukáže výsledek téhle kontroly u vás, včetně důkazu, ze kterého jsme vycházeli.

Situace, které to řeší

Související kontroly

Co se k tomu váže a dělá se obvykle spolu.

Naposledy upraveno 3. listopadu 2026. Stránku píšeme ručně a opravujeme ji, když se změní to, co měříme. Našli jste tu chybu? Napište na kontakt.