Listový certifikát platný, řetězec vypršel: čtěte hloubku

Chyba vypršení může patřit vydavateli, ne listu. Přečtěte si hloubku ověření a vstupy důvěry, než obnovíte certifikát, který stále vypadá aktuálně.

Zkontrolujete certifikát serveru, vidíte, že na hodinách zbývají měsíce, a klient přesto odmítne spojení s hlášením o vypršení. Datum, které čtete, patří listu a stížnost se může týkat něčeho hlouběji v cestě. Ověřování prochází řetězec a kterýkoli certifikát, který tento průchod vybere, může selhat ve svém vlastním okně platnosti. Přečtěte si, který selhal, než cokoli obnovíte.

Hloubka pojmenovává certifikát, který selhal

V diagnostice OpenSSL je hloubka 0 cílový certifikát a hloubka 1 vydavatel, který jej podepsal, přičemž vyšší čísla pokračují k zakotvení důvěry. Vypršení hlášené v hloubce 1 není v rozporu s aktuálním notAfter na listu, takže opětovná kontrola viditelného certifikátu chybu nikdy nevysvětlí.

Zaznamenejte otisk selhaného certifikátu spolu s jeho subjektem, protože různé certifikáty mohou nést stejný název CA. Křížové podepisování vytváří přesně tuto situaci: stejná autorita se objevuje vícekrát, s různými daty platnosti, a ověřovatel vybral tu, kterou jste neočekávali. Známý štítek není identifikátor a otisk je to, co odlišuje dva objekty se stejným jménem.

Všímejte si také produktů s více než jednou rolí certifikátu. Na OpenVPN Access Server jsou certifikáty chránící webová rozhraní oddělené od těch pro VPN připojení, takže prohlížeč, který otevře administrátorskou stránku, nic nedokazuje o cestě tunelu.

Vstupy důvěry nejsou totéž jako kandidáti řetězce

Dejte ověřovateli oba vstupy odděleně a výslovně. Soubor důvěry obsahuje kotvy, které přijímáte; nedůvěryhodný balík obsahuje mezilehlé certifikáty nabízené pro sestavení cesty. Jejich míchání je způsob, jakým lidé omylem povýší mezilehlý certifikát na kořen a pak se diví, proč je stejná chyba následuje mezi počítači.

$ openssl verify -verbose -show_chain -purpose sslserver \
    -CAfile trusted-roots.pem -no-CApath -no-CAstore \
    -untrusted intermediates.pem server.pem

Vypnutí výchozí cesty a úložiště pomocí -no-CApath -no-CAstore udržuje test poctivý: výsledek pak závisí na souborech, které jste uvedli, ne na tom, čemu pracovní stanice náhodou důvěřuje. Referenční příručka ověřování OpenSSL dokumentuje tyto volby a diagnostiku, kterou vytvářejí.

-show_chain vypíše sestavený řetězec, když ověření uspěje, což je užitečné pro potvrzení, že cesta je ta zamýšlená. Když selže, ponechte hlášenou hloubku a subjekt; tato dvě pole říkají dalšímu čtenáři, který certifikát zkontrolovat.

Co to nedělá, je reprodukce zásad každého klienta. Pin, omezení účelu nebo kontrola identity specifická pro klienta žije v klientovi, ne v tomto příkazu. To jsou nastavení, která je třeba zkontrolovat, když ověření na serveru projde a spojení stále selhává. Držte obě diagnózy oddělené, jinak obnovíte zdravý certifikát, zatímco budete pronásledovat chybu pinningu.

Co kontrola dokazuje a co vynechává

Toto je kontrola cesty a účelu proti souboru důvěry, který jste dodali. Pro kontrolu názvu HTTPS přidejte očekávané jméno hostitele příslušnou volbou; pro VPN připojení ponechte nakonfigurované kontroly identity klienta a použijte důvěryhodný materiál, který tento klient skutečně čte.

To, co server posílá, je sada kandidátů, ne cesta, kterou váš klient nakonec sestaví. Místní důvěra a pravidla sestavení knihovny utvářejí výsledek, a proto se stejná odpověď může ověřit na jednom počítači a selhat na jiném. Porovnejte udržované úložiště důvěry a implementaci TLS selhávajícího klienta s těmi funkčního klienta, než předpokládáte totožné vyhodnocení. Rozdíl tam vysvětluje mnoho hlášení „selhává jen tento notebook“.

Chcete-li vidět okno každého certifikátu místo po jednom, vypište je jako sadu:

$ openssl x509 -in server.pem -noout -subject -dates
$ openssl crl2pkcs7 -nocrl -certfile intermediates.pem \
    | openssl pkcs7 -print_certs -noout

Druhý příkaz vypisuje subjekty a vydavatele, aniž by ručně dekódoval každý soubor, takže odhalíte mezilehlý certifikát, jehož datum už minulo, zatímco list stále vypadá dobře.

Opravte cestu, aniž byste oslabili ověřování

Když je dodán vypršelý mezilehlý nebo zastaralý křížově podepsaný certifikát, získejte aktuálně podporovaný řetězec vydavatele a nasaďte jej dokumentovaným postupem certifikátů služby. Když klientovi chybí zamýšlená udržovaná kotva, aktualizujte jeho spravovanou konfiguraci důvěry nebo klientský software. Odolejte zkratce označit každý certifikát v balíku jako kořen jen proto, abyste zprávu umlčeli.

Zacházení s kořenem si zaslouží poznámku, protože shrnutí jej často přehánějí. RFC 5280 považuje kotvu za vstup, který stojí mimo předpokládanou cestu, zatímco OpenSSL dokumentuje kontroly platnosti, které zahrnují jeho kořenový certifikát CA. Obě tvrzení platí pro jejich vlastní systémy; zobecnění chování vypršení kořene jedné knihovny na každého klienta dává sebevědomě špatné odpovědi.

Po změně vynuťte na postiženém klientovi novou autentizaci a potvrďte, že konkrétní zpráva o vypršení zmizela. Obnovte list jen tehdy, když je samotný list nevhodný. Vypnutí kontrol času nebo obnovení historického křížového certifikátu nevytváří platnou aktuální cestu; jen odkládá další selhání.

Související články