Šta 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, server radi, a isti profil je radio na drugom laptopu prošlog mjeseca. Ispod tog upozorenja od jednog reda klijent je propustio certifikat peera kroz četiri kapije: 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 kapiju koja se zatvorila i popravka je obično jedna datoteka; preskočite taj korak i uvozit ćete pakete cijelo poslijepodne.

Pročitajte dijalog prije nego što uredite profil

Certifikatne greške formulira biblioteka ispod, a ne VPN proizvod koji ste instalirali, pa je tačan niz vaš prvi dokaz. „Nije moguće dobiti certifikat lokalnog izdavaoca“ 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 nivo dnevnika prije nego što bilo šta promijenite. OpenVPN prijavljuje neuspjeh verifikacije oko rukovanja kada ga pokrenete s --verb 4, a strongSwan zapisuje svoje odluke o identitetu i lancu u charon dnevnik. Zatim potvrdite koji certifikat pregledate, jer ljudi rutinski testiraju datoteku na disku dok profil ubacuje stariju kopiju. Kada profil ugrađuje PEM blokove, ugrađeni certifikat je onaj koji se testira.

Ustanova za certifikate potpisuje identitete, ne dozvole

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

Povjerenje u ustanovu čini svaki certifikat koji je potpisala kandidatom, a ne pravim peerom. Certifikat web servera iz iste interne CA također je kandidat. Zato postoje kapije imena i namjene i zato je kompromitirani CA ključ važniji od bilo kojeg pojedinačnog servera: doseže svaki identitet koji je ustanova ikad izdala. Izdajte klijentske certifikate po uređaju, da izgubljeni laptop bude jedno opoziv, a ne ponovno generisanje 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 server stvarno šalje ili koju datoteku povjerenja profil učitava. U OpenVPN-u posredni certifikati mogu putovati uz datoteku certifikata servera 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 odvojene kapije

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 upoređuje samo uobičajeno ime lomi se na certifikatima čiji identiteti žive u subjectAltName. Implementacije IKEv2 upoređuju konfigurirani identitet sa SAN unosima ili s razlikovnim imenom, zavisno od klijenta, a wildcard ili %any vrijednost tiho isključuje poređenje za koje ste mislili da ga imate.

Zatim slijede vrijeme i namjena. Laptop č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 verifikaciju.

Opoziv radi samo ako ga je neko konfigurirao

CRL ili OCSP odgovor ne pregledaju se automatski. Na OpenVPN serveru klijentski certifikati provjeravaju se prema listi samo kada --crl-verify pokazuje na nju. Provjera certifikata servera 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 tokom incidenta.

Redoslijed popravke koji zadržava verifikaciju uključenom

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

Prođite listu u jednom prolazu: potvrdite datoteku koju profil učitava, sami izgradite put, provjerite da server šalje posredni certifikat, uporedite sat, pročitajte SAN, pročitajte EKU, pa se ponovo 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.