Čo váš VPN klient skontroluje, kým dôveruje certifikátu

Váš VPN klient hlási, že certifikát nebolo možné overiť, a dialóg sa tam končí. Súbor je na mieste, server beží a ten istý profil minulý mesiac fungoval na inom notebooku. Pod týmto jednoriadkovým varovaním klient previedol certifikát protistrany štyrmi bránami: certifikačná autorita, ktorú ste nastavili, ručí za cestu podpisu, táto cesta dosiahne autoritu, meno protistrany je to, ktoré ste chceli, a certifikát je teraz použiteľný na tento účel. Nájdite bránu, ktorá sa zavrela, a oprava je zvyčajne jeden súbor; ten krok preskočte a budete celé popoludnie znovu importovať balíky.

Prečítajte si dialóg, kým upravíte profil

Chyby certifikátov formuluje knižnica pod tým, nie VPN produkt, ktorý ste nainštalovali, takže presný reťazec je váš prvý dôkaz. „Nedá sa získať certifikát miestneho vydavateľa“ ukazuje na cestu alebo na koreň dôvery. „Certifikát vypršal alebo ešte nie je platný“ ukazuje na čas. „Nepodporovaný účel certifikátu“ ukazuje na rozšírené použitie kľúča. Nesúlad mena vám povie, ktoré meno chcel. Žiadna zo štyroch sa neopraví preinštalovaním klienta.

Zvýšte úroveň protokolovania, kým čokoľvek zmeníte. OpenVPN hlási zlyhanie overenia okolo handshake, keď ho spustíte s --verb 4, a strongSwan zapisuje svoje rozhodnutia o identite a reťazci do protokolu charon. Potom potvrďte, ktorý certifikát skúmate, pretože ľudia bežne testujú súbor na disku, zatiaľ čo profil vkladá staršiu kópiu. Keď profil vkladá bloky PEM, testovaný certifikát je ten vložený.

Certifikačná autorita podpisuje identity, nie oprávnenia

Autorita drží meno a podpisový kľúč. Vydáva certifikáty, ktoré viažu verejný kľúč k tomuto menu podľa jej vlastných zásad, s pripojeným obdobím platnosti a obmedzeniami použitia. Váš klient potrebuje na rozpoznanie vydavateľa iba certifikát autority; podpisový kľúč nikdy nepotrebuje a poslať tento kľúč klientom by im dalo schopnosť vytvoriť akúkoľvek identitu, ktorej nasadenie dôveruje.

Dôvera v autoritu robí každý ňou podpísaný certifikát kandidátom, nie správnou protistranou. Certifikát webového servera z tej istej internej CA je tiež kandidát. Preto existujú brány mena a účelu a preto kompromitovaný kľúč CA záleží viac než ktorýkoľvek jednotlivý server: dosiahne na každú identitu, ktorú autorita kedy vydala. Vydávajte klientske certifikáty pre každé zariadenie, aby stratený notebook bol jedným odvolaním namiesto obnovy kľúčov pre celé nasadenie.

Znovu postavte cestu, ktorú sa klient snaží postaviť

Cesta vedie od certifikátu protistrany cez nula alebo viac sprostredkujúcich certifikátov ku koreňu vo vašom úložisku dôvery. Chýbajúci sprostredkujúci certifikát je najčastejšia porucha reťazca a z pohľadu klienta vyzerá rovnako ako nedôveryhodný koreň. Najprv prečítajte list, potom nechajte OpenSSL postaviť cestu z materiálu, ktorý hodláte odoslať.

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 bola postavená z týchto súborov; zlyhanie pomenuje certifikát, ku ktorému sa nedostalo. Ak openssl verify uspeje, zatiaľ čo klient stále odmieta, rozdiel je v tom, čo server skutočne posiela, alebo v tom, ktorý súbor dôvery profil načítava. V OpenVPN môžu sprostredkujúce certifikáty ísť so súborom certifikátu servera alebo byť dodané zvlášť pomocou --extra-certs, a balík s dvoma koreňmi zapísanými pod rovnakým menom subjektu pošle jedného z vašich klientov do nesprávnej vetvy.

Meno a účel sú oddelené brány

Budovanie reťazca sa nikdy nepýta, či je meno vaše. OpenVPN ho kontroluje len vtedy, keď profil nastaví --verify-x509-name, a starý zvyk porovnávať iba všeobecné meno sa láme na certifikátoch, ktorých identity žijú v subjectAltName. Nasadenia IKEv2 porovnávajú nastavenú identitu so záznamami SAN alebo s rozlišujúcim menom, podľa klienta, a hodnota s divým znakom alebo %any ticho vypne porovnanie, o ktorom ste si mysleli, že ho máte.

Ďalej prichádza čas a účel. Notebook, ktorého hodiny idú o niekoľko hodín dopredu, odmietne certifikát, ktorý ešte nie je platný, a vypršaný sprostredkujúci certifikát zhatí cestu, kým list je platný. Zlyhania účelu pochádzajú z certifikátu bez serverAuth v rozšírenom použití kľúča alebo s keyUsage, ktorý nepovoľuje podpis handshake, čo OpenSSL hlási ako nepodporovaný účel certifikátu. Vydajte znova zo správnej šablóny; nič v tej správe nie je dôvod vypnúť overovanie.

Odvolanie beží len vtedy, keď ho niekto nastavil

CRL ani odpoveď OCSP sa nekonzultujú automaticky. Na serveri OpenVPN sa klientske certifikáty porovnávajú so zoznamom len vtedy, keď --crl-verify na nejaký ukazuje. Kontrola certifikátu servera na strane klienta závisí od implementácie a často chýba. strongSwan potrebuje svoj zásuvný modul pre odvolanie a zásadu, kým sa pozrie na CRL pre protistranu.

To vysvetľuje tiket, ktorý nakoniec dostanete: odvolaný klientsky certifikát sa stále pripojí a všetci usúdia, že odvolanie je pokazené. Nič nekontrolovalo. Publikujte a obnovte CRL alebo držte klientske certifikáty dostatočne krátkodobé, aby zastarané odvolanie krátko záležalo, a nacvičte cestu odvolania na laboratórnom certifikáte, kým ju budete potrebovať počas incidentu.

Poradie opravy, ktoré udrží overovanie zapnuté

Zoraďte podľa symptómu, kým sa dotknete súborov, pretože každý riadok tabuľky vás posiela k inému objektu.

Prejdite zoznam jedným prechodom: potvrďte súbor, ktorý profil načítava, postavte cestu sami, skontrolujte, či server posiela sprostredkujúci certifikát, porovnajte hodiny, prečítajte SAN, prečítajte EKU, potom sa znova pripojte a sledujte, ako ten istý riadok protokolu mizne. Ak zariadeniu nemožno vôbec dať CA, pinning je poctivá alternatíva, pretože OpenVPN 2.6 prijíma --peer-fingerprint a zužuje dôveru na jeden kľúč namiesto odstránenia kontroly. RFC 5280 je referenciou pre to, čo každé z tých polí znamená.