Co váš VPN klient kontroluje, než důvěří certifikátu

Váš VPN klient hlásí, že certifikát nebylo možné ověřit, a dialog tam končí. Soubor je na místě, server běží a stejný profil minulý měsíc fungoval na jiném notebooku. Pod tímto jednořádkovým varováním klient protlačil certifikát protistrany čtyřmi branami: certifikační autorita, kterou jste nastavili, ručí za cestu podpisu, tato cesta dosáhne autority, jméno protistrany je to, které jste chtěli, a certifikát je nyní pro tento účel použitelný. Najděte bránu, která se zavřela, a oprava je obvykle jeden soubor; ten krok přeskočte a budete celé odpoledne znovu importovat balíky.

Přečtěte si dialog, než upravíte profil

Chyby certifikátů formuluje knihovna pod tím, ne VPN produkt, který jste nainstalovali, takže přesný řetězec je váš první důkaz. „Nelze získat certifikát místního vydavatele“ ukazuje na cestu nebo na kořen důvěry. „Certifikát vypršel nebo ještě není platný“ ukazuje na čas. „Nepodporovaný účel certifikátu“ ukazuje na rozšířené použití klíče. Nesoulad jména vám řekne, které jméno chtěl. Žádná ze čtyř se neopraví přeinstalováním klienta.

Zvyšte úroveň protokolování, než cokoli změníte. OpenVPN hlásí selhání ověření kolem handshake, když jej spustíte s --verb 4, a strongSwan zapisuje svá rozhodnutí o identitě a řetězci do protokolu charon. Poté potvrďte, který certifikát zkoumáte, protože lidé běžně testují soubor na disku, zatímco profil vkládá starší kopii. Když profil vkládá bloky PEM, testovaný certifikát je ten vložený.

Certifikační autorita podepisuje identity, ne oprávnění

Autorita drží jméno a podpisový klíč. Vydává certifikáty, které vážou veřejný klíč k tomuto jménu podle jejích vlastních zásad, s připojeným obdobím platnosti a omezeními použití. Váš klient potřebuje k rozpoznání vydavatele jen certifikát autority; podpisový klíč nikdy nepotřebuje a poslat tento klíč klientům by jim dalo schopnost vytvořit jakoukoli identitu, které nasazení důvěřuje.

Důvěra v autoritu činí každý jí podepsaný certifikát kandidátem, ne správnou protistranou. Certifikát webového serveru ze stejné interní CA je také kandidát. Proto existují brány jména a účelu a proto kompromitovaný klíč CA záleží víc než kterýkoli jednotlivý server: dosáhne na každou identitu, kterou autorita kdy vydala. Vydávejte klientské certifikáty pro každé zařízení, aby ztracený notebook byl jedním odvoláním místo obnovy klíčů pro celé nasazení.

Znovu postavte cestu, kterou se klient snaží postavit

Cesta vede od certifikátu protistrany přes nula nebo více zprostředkujících certifikátů ke kořeni ve vašem úložišti důvěry. Chybějící zprostředkující certifikát je nejčastější porucha řetězce a z pohledu klienta vypadá stejně jako nedůvěryhodný kořen. Přečtěte nejdřív list, potom nechte OpenSSL postavit cestu z materiálu, který hodláte odeslat.

openssl x509 -in server.crt -noout -subject -issuer -dates
openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt
openssl verify -show_chain -CAfile root.crt -untrusted intermediate.crt server.crt

Nulový návratový stav znamená, že cesta byla z těchto souborů postavena; selhání pojmenuje certifikát, k němuž se nedostalo. Pokud openssl verify uspěje, zatímco klient stále odmítá, rozdíl je v tom, co server skutečně posílá, nebo v tom, který soubor důvěry profil načítá. V OpenVPN mohou zprostředkující certifikáty jet se souborem certifikátu serveru nebo být dodány zvlášť pomocí --extra-certs, a balík se dvěma kořeny zapsanými pod stejným jménem subjektu pošle jednoho z vašich klientů do špatné větve.

Jméno a účel jsou oddělené brány

Stavba řetězce se nikdy neptá, zda je jméno vaše. OpenVPN ho kontroluje jen tehdy, když profil nastaví --verify-x509-name, a starý zvyk porovnávat pouze běžné jméno se láme na certifikátech, jejichž identity žijí v subjectAltName. Nasazení IKEv2 porovnávají nastavenou identitu se záznamy SAN nebo s rozlišujícím jménem, podle klienta, a hodnota se zástupným znakem nebo %any tiše vypne porovnání, o kterém jste si mysleli, že ho máte.

Dál přichází čas a účel. Notebook, jehož hodiny jdou o několik hodin napřed, odmítne certifikát, který ještě není platný, a vypršelý zprostředkující certifikát zhatí cestu, zatímco list je platný. Selhání účelu pocházejí z certifikátu bez serverAuth v rozšířeném použití klíče nebo s keyUsage, který nepovoluje podpis handshake, což OpenSSL hlásí jako nepodporovaný účel certifikátu. Vydávejte znovu ze správné šablony; nic v té zprávě není důvod vypnout ověřování.

Odvolání běží jen tehdy, když ho někdo nastavil

CRL ani odpověď OCSP se nekonzultují automaticky. Na serveru OpenVPN se klientské certifikáty porovnávají se seznamem jen tehdy, když --crl-verify na nějaký ukazuje. Kontrola certifikátu serveru na straně klienta závisí na implementaci a často chybí. strongSwan potřebuje svůj zásuvný modul pro odvolání a zásadu, než se podívá na CRL pro protistranu.

To vysvětluje tiket, který nakonec dostanete: odvolaný klientský certifikát se stále připojí a všichni usoudí, že odvolání je rozbité. Nic nekontrolovalo. Publikujte a obnovujte CRL, nebo držte klientské certifikáty dostatečně krátkodobé, aby zastaralé odvolání krátce záleželo, a nacvičte cestu odvolání na laboratorním certifikátu, než ji budete potřebovat při incidentu.

Pořadí opravy, které udrží ověřování zapnuté

Seřaďte podle symptomu, než se dotknete souborů, protože každý řádek tabulky vás posílá k jinému objektu.

Projděte seznam jedním průchodem: potvrďte soubor, který profil načítá, postavte cestu sami, zkontrolujte, že server posílá zprostředkující certifikát, porovnejte hodiny, přečtěte SAN, přečtěte EKU, potom se znovu připojte a sledujte, jak stejný řádek protokolu mizí. Pokud zařízení vůbec nelze dát CA, pinning je poctivá alternativa, protože OpenVPN 2.6 přijímá --peer-fingerprint a zužuje důvěru na jeden klíč, místo aby kontrolu odstranil. RFC 5280 je referencí k tomu, co každé z těch polí znamená.