Što vaš VPN klijent provjerava prije nego što povjeruje certifikatu

Vaš VPN klijent kaže da certifikat nije mogao biti verificiran, i dijalog se tu zaustavlja. Datoteka je tu, poslužitelj radi, a isti je profil radio na drugom prijenosnom računalu prošloga mjeseca. Ispod tog upozorenja od jednog retka klijent je propustio certifikat peera kroz četiri vrata: ustanova za izdavanje certifikata koju ste konfigurirali jamči put potpisa, taj put doseže ustanovu, ime peera je ono koje ste tražili, i certifikat je sada upotrebljiv za tu namjenu. Nađite vrata koja su se zatvorila i popravak je obično jedna datoteka; preskočite taj korak i uvozit ćete pakete cijelo poslijepodne.

Pročitajte dijalog prije nego što uredite profil

Certifikatne pogreške formulira biblioteka ispod, a ne VPN proizvod koji ste instalirali, pa je točan niz vaš prvi dokaz. „Nije moguće dobiti certifikat lokalnog izdavatelja“ upućuje na put ili na sidro povjerenja. „Certifikat je istekao ili još nije valjan“ upućuje na vrijeme. „Nepodržana namjena certifikata“ upućuje na proširenu upotrebu ključa. Nesklad imena vam kaže koje je ime htio. Nijedna od četiri ne popravlja se ponovnom instalacijom klijenta.

Podignite razinu dnevnika prije nego što bilo što promijenite. OpenVPN prijavljuje neuspjeh provjere oko rukovanja kada ga pokrenete s --verb 4, a strongSwan zapisuje svoje odluke o identitetu i lancu u charon dnevnik. Zatim potvrdite koji certifikat pregledavate, jer ljudi rutinski testiraju datoteku na disku dok profil ugrađuje stariju kopiju. Kada profil ugrađuje PEM blokove, ugrađeni certifikat je onaj koji se testira.

Ustanova za certifikate potpisuje identitete, ne ovlasti

Ustanova drži ime i ključ za potpisivanje. Izdaje certifikate koji vežu javni ključ za to ime prema vlastitoj politici, s pridruženim rokom valjanosti i ograničenjima upotrebe. Vašem klijentu treba samo certifikat ustanove da prepozna izdavatelja; nikad mu ne treba ključ za potpisivanje, a slanje tog ključa klijentima dalo bi im mogućnost stvaranja bilo kojeg identiteta kojem implementacija vjeruje.

Povjerenje u ustanovu čini svaki certifikat koji je potpisala kandidatom, a ne pravim peerom. Certifikat web poslužitelja iz iste interne CA također je kandidat. Zato postoje vrata imena i namjene i zato je kompromitirani CA ključ važniji od bilo kojeg pojedinačnog poslužitelja: doseže svaki identitet koji je ustanova ikad izdala. Izdajte klijentske certifikate po uređaju, da izgubljeno prijenosno računalo bude jedno opoziv, a ne ponovno generiranje ključeva za cijelu implementaciju.

Ponovno izgradite put koji klijent pokušava izgraditi

Put ide od certifikata peera, kroz nula ili više posrednih certifikata, do korijena u vašoj trgovini povjerenja. Nedostajući posredni certifikat najčešći je kvar lanca, a s klijentske strane izgleda isto kao nepouzdan korijen. Pročitajte prvo list, pa pustite OpenSSL da izgradi put iz materijala koji namjeravate poslati.

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

Izlazni status nula znači da je put izgrađen iz tih datoteka; neuspjeh imenuje certifikat do kojeg nije mogao doći. Ako openssl verify uspije dok klijent još odbija, razlika je u tome što poslužitelj stvarno šalje ili koju datoteku povjerenja profil učitava. U OpenVPN-u posredni certifikati mogu putovati uz datoteku certifikata poslužitelja ili se dostaviti odvojeno s --extra-certs, a paket s dva korijena napisana pod istim imenom subjekta poslat će jednog od vaših klijenata u pogrešnu granu.

Ime i namjena su odvojena vrata

Izgradnja lanca nikad ne pita je li ime vaše. OpenVPN ga provjerava samo kada profil postavi --verify-x509-name, a stara navika da se uspoređuje samo uobičajeno ime lomi se na certifikatima čiji identiteti žive u subjectAltName. Implementacije IKEv2 uspoređuju konfigurirani identitet sa SAN unosima ili s razlikovnim imenom, zavisno od klijenta, a wildcard ili %any vrijednost tiho isključuje usporedbu za koju ste mislili da je imate.

Zatim slijede vrijeme i namjena. Prijenosno računalo čiji sat žuri nekoliko sati odbija certifikat koji još nije valjan, a istekao posredni certifikat ruši put dok je list valjan. Kvarovi namjene dolaze od certifikata bez serverAuth u proširenoj upotrebi ključa ili s keyUsage koji ne dopušta potpis rukovanja, što OpenSSL prijavljuje kao nepodržanu namjenu certifikata. Ponovno izdajte iz ispravnog predloška; ništa u toj poruci nije razlog da isključite provjeru.

Opoziv radi samo ako ga je netko konfigurirao

CRL ili OCSP odgovor ne pregledavaju se automatski. Na OpenVPN poslužitelju klijentski certifikati provjeravaju se prema listi samo kada --crl-verify pokazuje na nju. Provjera certifikata poslužitelja na strani klijenta zavisi od implementacije i često izostaje. strongSwan treba svoj dodatak za opoziv i politiku prije nego pogleda CRL za peera.

To objašnjava tiket koji ćete na kraju dobiti: opozvani klijentski certifikat se još povezuje i svi zaključe da je opoziv pokvaren. Ništa nije provjeravalo. Objavite i osvježite CRL ili držite klijentske certifikate dovoljno kratkotrajnim da zastarjeli opoziv kratko bude važan, i uvježbajte put opoziva na laboratorijskom certifikatu prije nego vam zatreba tijekom incidenta.

Redoslijed popravka koji zadržava provjeru uključenom

Sortirajte po simptomu prije nego dodirnete datoteke, jer vas svaki red tablice šalje na drugi objekt.

Prođite listu u jednom prolazu: potvrdite datoteku koju profil učitava, sami izgradite put, provjerite da poslužitelj šalje posredni certifikat, usporedite sat, pročitajte SAN, pročitajte EKU, pa se ponovno povežite i gledajte kako isti red dnevnika nestaje. Ako se uređaju uopće ne može dati CA, pinning je iskrena alternativa, jer OpenVPN 2.6 prihvaća --peer-fingerprint i sužava povjerenje na jedan ključ umjesto da ukloni provjeru. RFC 5280 je referenca za značenje svakog od tih polja.