Hva VPN-klienten din kontrollerer før den stoler på et sertifikat

VPN-klienten din sier at sertifikatet ikke kunne verifiseres, og dialogen stopper der. Filen er der, serveren kjører, og samme profil fungerte på en annen bærbar PC i forrige måned. Under den enlinjes advarselen kjørte klienten peer-sertifikatet gjennom fire porter: et sertifikatmyndighet du har konfigurert garanterer signaturstien, stien når myndigheten, peernavnet er det du ba om, og sertifikatet kan brukes nå til dette formålet. Finn porten som lukket seg, og reparasjonen er vanligvis én fil; hopper du over det trinnet, importerer du bunter på nytt hele ettermiddagen.

Les dialogen før du redigerer profilen

Sertifikatfeil formuleres av biblioteket under, ikke av VPN-produktet du installerte, så den nøyaktige strengen er ditt første bevis. «Kan ikke hente sertifikatet til den lokale utstederen» peker på stien eller på tillitsankeret. «Sertifikatet er utløpt eller er ennå ikke gyldig» peker på tid. «Ikke støttet sertifikatformål» peker på utvidet nøkkelbruk. Et navneavvik forteller deg hvilket navn den ville ha. Ingen av de fire repareres ved å installere klienten på nytt.

Hev loggnivået før du endrer noe. OpenVPN rapporterer verifiseringsfeilen rundt håndtrykket når du kjører det med --verb 4, og strongSwan skriver identitets- og kjedebeslutningene sine til charon-loggen. Bekreft deretter hvilket sertifikat du undersøker, fordi folk rutinemessig tester filen på disken mens profilen bygger inn en eldre kopi. Når profilen bygger inn PEM-blokker, er det innebygde sertifikatet det som testes.

En sertifikatmyndighet signerer identiteter, ikke tillatelser

Myndigheten holder et navn og en signeringsnøkkel. Den utsteder sertifikater som binder en offentlig nøkkel til det navnet etter sin egen policy, med et gyldighetsvindu og bruksbegrensninger vedlagt. Klienten din trenger bare myndighetens sertifikat for å gjenkjenne utstederen; den trenger aldri signeringsnøkkelen, og å sende den nøkkelen til klienter ville gi dem evnen til å lage hvilken som helst identitet utrullingen stoler på.

Tillit til en myndighet gjør hvert sertifikat den har signert til en kandidat, ikke den riktige peeren. Et webserver-sertifikat fra samme interne CA er også en kandidat. Derfor finnes navne- og formålsportene, og derfor betyr en kompromittert CA-nøkkel mer enn noen enkelt server: den når hver identitet myndigheten noen gang har utstedt. Del ut klient-sertifikater per enhet, slik at en mistet bærbar PC er én tilbakekalling i stedet for en nøkkelutskiftning for hele utrullingen.

Bygg stien på nytt som klienten prøver å bygge

Stien går fra peer-sertifikatet, gjennom null eller flere mellomliggende sertifikater, til en rot i tillitslageret ditt. Et manglende mellomledd er den vanligste kjedefeil, og fra klientsiden ser det identisk ut med en ikke-klarert rot. Les bladet først, og la deretter OpenSSL bygge stien fra materialet du har tenkt å 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

Null i utgangsstatus betyr at stien ble bygget fra disse filene; en feil navngir sertifikatet den ikke kunne nå. Hvis openssl verify lykkes mens klienten fortsatt avviser, ligger forskjellen i hva serveren faktisk sender eller i hvilken tillitsfil profilen laster. I OpenVPN kan mellomliggende sertifikater følge serverens sertifikatfil eller leveres separat med --extra-certs, og en bunt med to røtter skrevet under samme subjektnavn vil sende en av klientene dine ned feil gren.

Navn og formål er separate porter

Kjedeoppbygging spør aldri om navnet er ditt. OpenVPN kontrollerer det bare når profilen setter --verify-x509-name, og den eldre vanen med å matche bare det vanlige navnet bryter sammen på sertifikater der identitetene bor i subjectAltName. IKEv2-utrullinger matcher den konfigurerte identiteten mot SAN-oppføringer eller mot det særskilte navnet, avhengig av klienten, og en wildcard- eller %any-verdi slår stille av sammenligningen du trodde du hadde.

Deretter kommer tid og formål. En bærbar PC hvis klokke går et par timer for fort avviser et sertifikat som ennå ikke er gyldig, og et utløpt mellomledd får stien til å feile mens bladet er gyldig. Formålsfeil kommer fra et sertifikat uten serverAuth i utvidet nøkkelbruk, eller med en keyUsage som ikke tillater håndtrykkssignaturen, noe OpenSSL rapporterer som ikke støttet sertifikatformål. Utsted på nytt fra riktig mal; ingenting i den meldingen er grunn til å slå av verifiseringen.

Tilbakekalling kjører bare hvis noen har konfigurert den

En CRL eller en OCSP-respons konsulteres ikke automatisk. På en OpenVPN-server kontrolleres klient-sertifikater mot en liste bare når --crl-verify peker på en. Klientsidens kontroll av serversertifikatet avhenger av implementasjonen og mangler ofte. strongSwan trenger tilbakekallingsprogramtillegget sitt og en policy før det ser på en CRL for en peer.

Det forklarer billetten du etter hvert får: et tilbakekalt klient-sertifikat kobler fortsatt til, og alle konkluderer med at tilbakekallingen er ødelagt. Ingenting kontrollerte. Publiser og oppdater CRL-en, eller hold klient-sertifikatene så kortlivede at en utdatert tilbakekalling bare betyr noe kort, og øv på tilbakekallingsstien med et laboratoriesertifikat før du trenger den under en hendelse.

En reparasjonsrekkefølge som holder verifiseringen på

Sorter etter symptom før du rører filer, fordi hver rad i tabellen sender deg til et annet objekt.

Gå gjennom listen i én runde: bekreft filen profilen laster, bygg stien selv, kontroller at serveren sender mellomleddet, sammenlign klokken, les SAN-en, les EKU-en, og koble deretter til på nytt og se den samme logglinjen forsvinne. Hvis en enhet ikke kan få noen CA i det hele tatt, er pinning det ærlige alternativet, fordi OpenVPN 2.6 godtar --peer-fingerprint og snevrer tilliten inn til én nøkkel i stedet for å fjerne kontrollen. RFC 5280 er referansen for hva hvert av disse feltene betyr.