Kva VPN-klienten din kontrollerer før han stolar på eit sertifikat

VPN-klienten din seier at sertifikatet ikkje kunne verifiserast, og dialogen stoppar der. Fila ligg der, serveren køyrer, og same profil fungerte på ein annan berbar PC i førre månad. Under den éinlinjes åtvaringa køyrde klienten peer-sertifikatet gjennom fire portar: ei sertifikatstyresmakt du har konfigurert garanterer signaturstien, stien når styresmakta, peernamnet er det du bad om, og sertifikatet kan brukast no til dette føremålet. Finn porten som lukka seg, og reparasjonen er vanlegvis éi fil; hoppar du over det trinnet, importerer du buntar på nytt heile ettermiddagen.

Les dialogen før du redigerer profilen

Sertifikatfeil vert formulerte av biblioteket under, ikkje av VPN-produktet du installerte, så den nøyaktige strengen er det første beviset ditt. «Kan ikkje hente sertifikatet til den lokale utgivaren» peikar på stien eller på tillitsankeret. «Sertifikatet er utløpt eller er enno ikkje gyldig» peikar på tid. «Ikkje støtta sertifikatføremål» peikar på utvida nøkkelbruk. Eit namneavvik fortel deg kva namn han ville ha. Ingen av dei fire vert reparerte ved å installere klienten på nytt.

Hev loggnivået før du endrar noko. OpenVPN rapporterer verifiseringsfeilen rundt handtrykket når du køyrer det med --verb 4, og strongSwan skriv identitets- og kjedebeslutningane sine til charon-loggen. Stadfest deretter kva sertifikat du granskar, fordi folk rutinemessig testar fila på disken medan profilen byggjer inn ein eldre kopi. Når profilen byggjer inn PEM-blokker, er det innebygde sertifikatet det som vert testa.

Ei sertifikatstyresmakt signerer identitetar, ikkje løyve

Styresmakta held eit namn og ein signeringsnøkkel. Ho gjev ut sertifikat som bind ein offentleg nøkkel til det namnet etter si eiga policy, med eit gyldigheitsvindauge og bruksavgrensingar vedlagde. Klienten din treng berre sertifikatet til styresmakta for å kjenne att utgivaren; han treng aldri signeringsnøkkelen, og å sende den nøkkelen til klientar ville gjeve dei evna til å lage kva som helst identitet utrulleringa stolar på.

Tillit til ei styresmakt gjer kvart sertifikat ho har signert til ein kandidat, ikkje den rette peeren. Eit webserver-sertifikat frå same interne CA er òg ein kandidat. Difor finst namne- og føremålsportane, og difor tyder ein kompromittert CA-nøkkel meir enn nokon einstaka server: han når kvar identitet styresmakta nokon gong har gjeve ut. Del ut klient-sertifikat per eining, slik at ein mist bærbar PC er éin tilbakekalling i staden for ein nøkkelutskiftning for heile utrulleringa.

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

Stien går frå peer-sertifikatet, gjennom null eller fleire mellomliggjande sertifikat, til ei rot i tillitslageret ditt. Eit manglande mellomledd er den vanlegaste kjedefeil, og frå klientsida ser det identisk ut med ei ikkje-klarert rot. Les bladet fyrst, og la deretter OpenSSL byggje stien frå 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 tyder at stien vart bygd frå desse filene; ein feil namngjev sertifikatet han ikkje kunne nå. Viss openssl verify lukkast medan klienten framleis avviser, ligg skilnaden i kva serveren faktisk sender eller i kva tillitsfil profilen lastar. I OpenVPN kan mellomliggjande sertifikat følgje sertifikatfila til serveren eller leverast separat med --extra-certs, og ein bunt med to røter skrivne under same subjektnamn vil sende ein av klientane dine ned feil grein.

Namn og føremål er separate portar

Kjedebygging spør aldri om namnet er ditt. OpenVPN kontrollerer det berre når profilen set --verify-x509-name, og den eldre vanen med å matche berre det vanlege namnet bryt saman på sertifikat der identitetane bur i subjectAltName. IKEv2-utrulleringar matchar den konfigurerte identiteten mot SAN-oppføringar eller mot det særskilde namnet, avhengig av klienten, og ein wildcard- eller %any-verdi slår stille av samanlikninga du trudde du hadde.

Deretter kjem tid og føremål. Ein berbar PC der klokka går eit par timar for fort avviser eit sertifikat som enno ikkje er gyldig, og eit utløpt mellomledd får stien til å feile medan bladet er gyldig. Føremålsfeil kjem frå eit sertifikat utan serverAuth i utvida nøkkelbruk, eller med ein keyUsage som ikkje tillèt handtrykkssignaturen, noko OpenSSL rapporterer som ikkje støtta sertifikatføremål. Gjev ut på nytt frå rett mal; ingenting i den meldinga er grunn til å slå av verifiseringa.

Tilbakekalling køyrer berre viss nokon har konfigurert henne

Ein CRL eller ein OCSP-respons vert ikkje konsultert automatisk. På ein OpenVPN-server vert klient-sertifikat kontrollerte mot ei liste berre når --crl-verify peikar på ei. Klientsida si kontroll av serversertifikatet avheng av implementasjonen og manglar ofte. strongSwan treng tilbakekallingsprogramtillegget sitt og ein policy før det ser på ein CRL for ein peer.

Det forklarer billetten du etter kvart får: eit tilbakekalla klient-sertifikat koplar framleis til, og alle konkluderer med at tilbakekallinga er øydelagd. Ingenting kontrollerte. Publiser og oppdater CRL-en, eller hald klient-sertifikata så kortliva at ei utdatert tilbakekalling berre tyder noko kort, og øv på tilbakekallingsstien med eit laboratoriesertifikat før du treng han under ei hending.

Ein reparasjonsrekkjefølgje som held verifiseringa på

Sorter etter symptom før du rører filer, fordi kvar rad i tabellen sender deg til eit anna objekt.

Gå gjennom lista i éin runde: stadfest fila profilen lastar, bygg stien sjølv, kontroller at serveren sender mellomleddet, samanlikn klokka, les SAN-en, les EKU-en, og kople deretter til på nytt og sjå den same logglinja forsvinne. Viss ei eining ikkje kan få nokon CA i det heile, er pinning det ærlege alternativet, fordi OpenVPN 2.6 godtar --peer-fingerprint og snevrar tilliten inn til éin nøkkel i staden for å fjerne kontrollen. RFC 5280 er referansen for kva kvart av desse felta tyder.