Çfarë kontrollon klienti juaj VPN përpara se t’i besojë një certifikate

Klienti juaj VPN thotë se certifikata nuk mund të verifikohej, dhe dialogu ndalet aty. Skedari është aty, serveri punon, dhe i njëjti profil funksionoi në një laptop tjetër muajin e kaluar. Nën atë paralajmërim një-rresht, klienti e kaloi certifikatën e palës nëpër katër porta: një autoritet certifikimi që ju konfiguruat garanton rrugën e nënshkrimit, ajo rrugë arrin autoritetin, emri i palës është ai që kërkuat, dhe certifikata është e përdorshme tani për këtë qëllim. Gjeni portën që u mbyll dhe rregullimi zakonisht është një skedar; kaloni atë hap dhe do të riimportoni paketa gjithë pasditen.

Lexoni dialogun përpara se të redaktoni profilin

Gabimet e certifikatës formulohen nga biblioteka poshtë, jo nga produkti VPN që instaloni, prandaj vargu i saktë është prova juaj e parë. «Nuk mund të merret certifikata e lëshuesit lokal» tregon rrugën ose ankorën e besimit. «Certifikata ka skaduar ose nuk është ende e vlefshme» tregon kohën. «Qëllimi i certifikatës nuk mbështetet» tregon përdorimin e zgjeruar të çelësit. Mospërputhja e emrit ju thotë cilin emër kërkonte. Asnjëra nga të katërtat nuk rregullohet duke reinstaluar klientin.

Rritni nivelin e regjistrimit përpara se të ndryshoni çdo gjë. OpenVPN raporton dështimin e verifikimit rreth shtrëngimit të duarve kur e ekzekutoni me --verb 4, dhe strongSwan shkruan vendimet e tij të identitetit dhe zinxhirit në regjistrin charon. Pastaj konfirmoni cilën certifikatë po ekzaminoni, sepse njerëzit zakonisht testojnë skedarin në disk ndërsa profili fut një kopje më të vjetër. Kur profili fut blloqe PEM, certifikata e futur është ajo që teston.

Një autoritet certifikimi nënshkruan identitete, jo leje

Autoriteti mban një emër dhe një çelës nënshkrimi. Ai lëshon certifikata që lidhin një çelës publik me atë emër sipas politikës së vet, me një dritare vlefshmërie dhe kufizime përdorimi të bashkangjitura. Klienti juaj ka nevojë vetëm për certifikatën e autoritetit për të njohur lëshuesin; nuk ka kurrë nevojë për çelësin e nënshkrimit, dhe dërgimi i atij çelësi klientëve do t’u jepte aftësinë të krijonin çdo identitet që beson vendosja.

Besimi në një autoritet e bën çdo certifikatë që ka nënshkruar kandidate, jo palën e duhur. Një certifikatë serveri web nga e njëjta CA e brendshme është gjithashtu kandidate. Prandaj ekzistojnë portat e emrit dhe qëllimit, dhe prandaj një çelës CA i komprometuar rëndësi më shumë se çdo server i vetëm: arrin çdo identitet që autoriteti ka lëshuar ndonjëherë. Shpërndani certifikata klienti për çdo pajisje, që një laptop i humbur të jetë një revokim dhe jo një rigjenerim çelësash për gjithë vendosjen.

Rindërtoni rrugën që klienti po përpiqet të ndërtojë

Rruga shkon nga certifikata e palës, përmes zero ose më shumë certifikatave të ndërmjetme, në një rrënjë në ruajtësen tuaj të besimit. Një certifikatë e ndërmjetme që mungon është dështimi më i shpeshtë i zinxhirit, dhe nga ana e klientit duket identike me një rrënjë të pabesuar. Lexoni së pari gjethen, pastaj lërini OpenSSL të ndërtojë rrugën nga materiali që mendoni të dërgoni.

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

Statusi i daljes zero do të thotë që rruga u ndërtua nga ata skedarë; një dështim emërton certifikatën që nuk mundi të arrihej. Nëse openssl verify ka sukses ndërsa klienti vazhdon të refuzojë, diferenca është në atë që serveri dërgon në të vërtetë ose në cilin skedar besimi ngarkon profili. Në OpenVPN certifikatat e ndërmjetme mund të udhëtojnë me skedarin e certifikatës së serverit ose të jepen veçmas me --extra-certs, dhe një paketë me dy rrënjë të shkruara nën të njëjtin emër subjekti do të dërgojë një nga klientët tuaj në degën e gabuar.

Emri dhe qëllimi janë porta të ndara

Ndërtimi i zinxhirit nuk pyet kurrë nëse emri është i juaji. OpenVPN e kontrollon atë vetëm kur profili vendos --verify-x509-name, dhe zakoni i vjetër për të përputhur vetëm emrin e përbashkët prishet në certifikatat identitetet e të cilave jetojnë në subjectAltName. Vendosjet IKEv2 përputhin identitetin e konfiguruar me hyrjet SAN ose me emrin dallues, në varësi të klientit, dhe një vlerë wildcard ose %any çaktivizon në heshtje krahasimin që mendonit se e kishit.

Më pas vijnë koha dhe qëllimi. Një laptop ora e të cilit shkon disa orë përpara refuzon një certifikatë që nuk është ende e vlefshme, dhe një certifikatë e ndërmjetme e skaduar dështon rrugën ndërsa gjetja është aktuale. Dështimet e qëllimit vijnë nga një certifikatë pa serverAuth në përdorimin e zgjeruar të çelësit, ose me një keyUsage që nuk lejon nënshkrimin e shtrëngimit të duarve, të cilën OpenSSL e raporton si qëllim certifikate të pambështetur. Rilëshojeni nga shablloni i duhur; asgjë në atë mesazh nuk është arsye për të çaktivizuar verifikimin.

Revokimi funksionon vetëm nëse dikush e ka konfiguruar

Një CRL ose një përgjigje OCSP nuk konsultohen automatikisht. Në një server OpenVPN, certifikatat e klientëve krahasohen me një listë vetëm kur --crl-verify tregon një të tillë. Kontrolli i certifikatës së serverit nga ana e klientit varet nga zbatimi dhe shpesh mungon. strongSwan ka nevojë për shtojcën e revokimit dhe një politikë përpara se të shikojë një CRL për një palë.

Kjo shpjegon tiketën që do të merrni përfundimisht: një certifikatë klienti e revokuar ende lidhet, dhe të gjithë konkludojnë se revokimi është prishur. Asgjë nuk po kontrollonte. Publikoni dhe rifreskoni CRL-në, ose mbani certifikatat e klientëve aq jetëshkurtra sa një revokim i vjetëruar të rëndësi për pak kohë, dhe provoni rrugën e revokimit me një certifikatë laboratori përpara se t’ju duhet gjatë një incidenti.

Një rend rregullimi që e mban verifikimin ndezur

Renditni sipas simptomës përpara se të prekni skedarë, sepse çdo rresht i tabelës ju dërgon te një objekt tjetër.

Kaloni listën në një kalim: konfirmoni skedarin që ngarkon profili, ndërtoni vetë rrugën, kontrolloni nëse serveri dërgon certifikatën e ndërmjetme, krahasoni orën, lexoni SAN-in, lexoni EKU-në, pastaj rilidhuni dhe shikoni të njëjtën rresht regjistri duke u zhdukur. Nëse një pajisjeje nuk mund t’i jepet fare CA, pinning është alternativa e ndershme, sepse OpenVPN 2.6 pranon --peer-fingerprint dhe e ngushton besimin në një çelës të vetëm në vend që të heqë kontrollin. RFC 5280 është referenca për kuptimin e secilës prej atyre fushave.