nepodporovaný účel certifikátu: proč mezilehlá CA selhává

Účel serverového certifikátu vypadá správně, klíč sedí, data jsou v pořádku, a spojení přesto selhává s unsupported certificate purpose. Detail, který to vyřeší, bývá na stejném řádku jako chyba: hodnota hloubky a subjekt, které pojmenovávají certifikát výše v řetězci. Provádějí se dva různé testy a jen jeden z nich se týká koncového certifikátu. Jejich srovnání vysvětluje, proč výměna serverového certifikátu nic nezmění.

Který certifikát ověřovatel skutečně odmítl

Řetězec není jeden objekt zopakovaný třikrát. Koncový certifikát nese jméno a klíč serveru, mezilehlé jej propojují s kořenem a každý má vlastní dobu platnosti, omezení a použití. Když chyba uvede hloubku, toto číslo označuje pozici v řetězci, který ověřovatel sestavil, a ta nemusí být pozicí, kterou očekáváte, pokud server posílá neočekávaný řetězec.

Čtěte pole certifikátu v této hloubce, ne certifikátu, který jste považovali za viníka. Vyžádejte si dvě rozšíření, která omezují vydávání, místo výpisu všech polí, protože odpověď je téměř vždy v jednom z nich. Výstup rozšíření je bezpečné sdílet; soukromé klíče nikdy.

openssl x509 -in issuing-ca.pem -noout -subject -issuer -ext basicConstraints -ext extendedKeyUsage

Pokud je uvedený certifikát mezilehlý a jeho rozšířené použití klíče zmiňuje něco nesouvisejícího s ověřováním serveru TLS, zbytek selhání plyne mechanicky. Řetězec nelze použít pro účel, který OpenVPN požadoval.

Účel koncového certifikátu a politika řetězce jsou dva testy

Test koncového certifikátu klade úzkou otázku: dovoluje tento certifikát koncové entity ověřování serveru pro toto jméno? Test řetězce klade širší: smí každý certifikát v cestě sloužit tomuto účelu? Certifikační autorita, která smí vydávat jen klientské certifikáty, projde vlastními kontrolami podpisu a přesto selže ve druhém testu, protože cesta, kterou povoluje, nezahrnuje účel, který aplikace potřebuje. Oba testy selhávají stejnými slovy a mají zcela odlišné opravy.

Proto může nově vydaný koncový certifikát, správný ve všech viditelných polích, selhat okamžitě. Proto oprava obvykle patří do profilu vydávající autority, nikoli do konfigurace VPN.

Chybějící EKU není omezující EKU

RFC 5280 činí rozšíření rozšířeného použití klíče nepovinným a, je-li přítomno, omezujícím. Certifikát CA bez rozšíření tedy neřekl „ne“ ověřování serveru, zatímco ten, který uvádí jen nesouvisející účel, řekl něco velmi konkrétního. Považovat tyto dva stavy za rovnocenné vede k chybné diagnóze a, hůř, k chybné opravě. Rozdíl také vysvětluje, proč se dvě autority, které v konzoli vypadají podobně, v řetězci chovají zcela odlišně.

Chování knihoven tu také není jednotné. dokument OpenSSL k možnostem ověřování popisuje vlastní přístup ke kontrolám účelu u certifikátů CA a tento přístup je politikou implementace, nikoli pravidlem, které každý TLS stack dodržuje stejně. Popište, co váš ověřovatel dělá, a poté to ověřte na verzi, kterou skutečně provozujete.

Reprodukujte selhání offline, než cokoli znovu vydáte

Ověření offline vyjímá aplikaci z otázky. Pokud řetězec selhává stejně při stejném účelu, problém je v certifikátu a žádná konfigurace serveru to neskryje. Pokud řetězec offline projde, zatímco služba stále odmítá, aplikace žádá jiný účel nebo používá jiný řetězec, než jste testovali.

openssl verify -purpose sslserver -show_chain -CAfile root-ca.pem -untrusted issuing-ca.pem vpn-server.pem

-show_chain je důležitý, protože vypisuje cestu, kterou nástroj sestavil, a ta často není pořadím souborů, které jste zadali. Tento výstup je nejrychlejší způsob, jak zjistit, že se druhý mezilehlý certifikát tahá z úložiště důvěry, že server posílá křížově podepsanou variantu, kterou jste nezamýšleli, nebo že příznak účelu zkopírovaný z návodu patří jiné roli, než která je obsluhována.

Opravte politiku vydávání, ne volání ověření

Trvalou opravou je mezilehlý certifikát vydaný podle politiky, která povoluje účely, jimž musí sloužit, s omezením zapsaným a revidovaným. Přidávat každý účel každé autoritě není politika; odstraňuje to omezení, které dávalo rozšíření smysl, a obvykle přežije incident, který je vyvolal. Krátká poznámka v profilu popisující, které role autorita smí certifikovat, zabrání tomu, aby příští vydání zopakovalo stejnou hádku.

Vypnutí ověření je druhá lákavá zkratka a mění problém certifikátu na problém důvěry. Ponechte kontrolu účelu, opravte řetězec a znovu spusťte stejné ověření offline, abyste potvrdili, že cesta nyní slouží zamýšlené roli, než se znovu dotknete služby.