Hvad din VPN-klient kontrollerer, før den stoler på et certifikat

Din VPN-klient siger, at certifikatet ikke kunne verificeres, og dialogen stopper der. Filen er til stede, serveren kører, og den samme profil virkede på en anden bærbar computer i sidste måned. Under den enlinjes advarsel kørte klienten peer-certifikatet gennem fire porte: en certifikatmyndighed, du har konfigureret, garanterer signaturstien, stien når myndigheden, peer-navnet er det, du bad om, og certifikatet kan bruges nu til dette formål. Find den port, der lukkede, og reparationen er som regel én fil; spring det trin over, og du vil genimportere bundter hele eftermiddagen.

Læs dialogen, før du redigerer profilen

Certifikatfejl formuleres af biblioteket nedenunder, ikke af det VPN-produkt, du installerede, så den præcise streng er dit første bevis. »Kan ikke hente lokalt udsteder-certifikat« peger på stien eller på tillidsankeret. »Certifikatet er udløbet eller endnu ikke gyldigt« peger på tid. »Ikke-understøttet certifikatformål« peger på udvidet nøglebrug. En navneforskel fortæller dig, hvilket navn den ville have. Ingen af de fire repareres ved at geninstallere klienten.

Hæv logningsniveauet, før du ændrer noget. OpenVPN rapporterer verifikationsfejlen omkring håndtrykket, når du kører det med --verb 4, og strongSwan skriver sine identitets- og kædebeslutninger til charon-loggen. Bekræft derefter, hvilket certifikat du undersøger, for folk tester rutinemæssigt filen på disken, mens profilen indlejrer en ældre kopi. Når profilen indlejrer PEM-blokke, er det indlejrede certifikat det, der testes.

En certifikatmyndighed underskriver identiteter, ikke tilladelser

Myndigheden holder et navn og en signeringsnøgle. Den udsteder certifikater, der binder en offentlig nøgle til det navn efter sin egen politik, med et gyldighedsvindue og brugsbegrænsninger vedhæftet. Din klient har kun brug for myndighedens certifikat for at genkende udstederen; den har aldrig brug for signeringsnøglen, og at sende den nøgle til klienter ville give dem evnen til at skabe enhver identitet, som udrulningen stoler på.

Tillid til en myndighed gør hvert certifikat, den har underskrevet, til en kandidat, ikke den rigtige peer. Et webserver-certifikat fra samme interne CA er også en kandidat. Derfor findes navne- og formålsportene, og derfor betyder en kompromitteret CA-nøgle mere end nogen enkelt server: den når hver identitet, myndigheden nogensinde har udstedt. Udlever klientcertifikater pr. enhed, så en mistet bærbar computer er ét tilbagekald i stedet for en nøglefornyelse for hele udrulningen.

Genopbyg den sti, klienten prøver at bygge

Stien løber fra peer-certifikatet gennem nul eller flere mellemliggende certifikater til en rod i dit tillidslager. Et manglende mellemliggende certifikat er den mest almindelige kædefejl, og fra klientsiden ser det identisk ud med en ubetroet rod. Læs bladet først, og lad derefter OpenSSL bygge stien ud fra det materiale, du agter at sende.

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

Exitstatus nul betyder, at stien blev bygget ud fra disse filer; en fejl navngiver det certifikat, den ikke kunne nå. Hvis openssl verify lykkes, mens klienten stadig afviser, ligger forskellen i, hvad serveren faktisk sender, eller i hvilken tillidsfil profilen indlæser. I OpenVPN kan mellemliggende certifikater følge med servercertifikatfilen eller leveres separat med --extra-certs, og et bundt med to rødder skrevet under samme subjektnavn vil sende en af dine klienter ned ad den forkerte gren.

Navn og formål er separate porte

Kædeopbygning spørger aldrig, om navnet er dit. OpenVPN kontrollerer det kun, når profilen sætter --verify-x509-name, og den ældre vane med kun at matche det fælles navn bryder sammen på certifikater, hvis identiteter lever i subjectAltName. IKEv2-udrulninger matcher den konfigurerede identitet mod SAN-poster eller mod det særlige navn, afhængigt af klienten, og en wildcard- eller %any-værdi slår stille den sammenligning fra, som du troede, du havde.

Tid og formål kommer næste. En bærbar computer, hvis ur går et par timer for hurtigt, afviser et certifikat, der endnu ikke er gyldigt, og et udløbet mellemliggende certifikat får stien til at fejle, mens bladet er gyldigt. Formålsfejl kommer fra et certifikat uden serverAuth i udvidet nøglebrug eller med en keyUsage, der ikke tillader håndtrykssignaturen, hvilket OpenSSL rapporterer som et ikke-understøttet certifikatformål. Genudsted fra den rigtige skabelon; intet i den meddelelse er grund til at slå verifikationen fra.

Tilbagekaldelse kører kun, hvis nogen har konfigureret den

En CRL eller et OCSP-svar konsulteres ikke automatisk. På en OpenVPN-server kontrolleres klientcertifikater mod en liste kun, når --crl-verify peger på en. Klientsidens kontrol af servercertifikatet afhænger af implementeringen og mangler ofte. strongSwan har brug for sit tilbagekaldelses-plugin og en politik, før det ser på en CRL for en peer.

Det forklarer den billet, du til sidst får: et tilbagekaldt klientcertifikat forbinder stadig, og alle konkluderer, at tilbagekaldelse er brudt. Intet kontrollerede. Udgiv og opdater CRL'en, eller hold klientcertifikater så kortlivede, at et forældet tilbagekald kun betyder noget kort, og øv tilbagekaldelsesstien på et laboratoriecertifikat, før du får brug for den under en hændelse.

En reparationsrækkefølge, der holder verifikationen tændt

Sortér efter symptom, før du rører filer, fordi hver række i tabellen sender dig til et andet objekt.

Gå listen igennem i ét gennemløb: bekræft den fil, profilen indlæser, byg stien selv, kontroller, at serveren sender det mellemliggende certifikat, sammenlign uret, læs SAN'en, læs EKU'en, og genopret derefter forbindelsen og se den samme loglinje forsvinde. Hvis en enhed slet ikke kan få en CA, er pinning det ærlige alternativ, fordi OpenVPN 2.6 accepterer --peer-fingerprint og indsnævrer tilliden til én nøgle i stedet for at fjerne kontrollen. RFC 5280 er referencen for, hvad hvert af de felter betyder.