Si të gjeneroni një çelës klienti VPN dhe të parashtroni një CSR për nënshkrim

Herët ose vonë, një përdorues VPN ofron të dërgojë një çelës privat me email që administratori të mund të bëjë një certifikatë, dhe pikërisht ajo ofertë është ajo që duhet refuzuar. Rrjedha që funksionon e mban çelësin te klienti që nga komanda e parë: klienti e gjeneron atë, dërgon një kërkesë për nënshkrim certifikate, lëshuesi e verifikon dhe e autorizon, dhe certifikata e nënshkruar kthehet për të qëndruar pranë çelësit që e krijoi. Lista e kontrollit më poshtë dështon e mbyllur në çdo hap, dhe ky është qëllimi, sepse dy nga pesë hapat janë pikërisht ata që njerëzit i kapërcejnë kur janë me nxitim.

Hapi 1: gjeneroni çelësin atje ku do të jetojë

Gjenerojeni në makinën që do të mbajë çelësin dhe lëreni atje. Një çelës softuerësh shkon në një skedar me leje të rrepta; një çelës i mbështetur nga hardueri ose në një magazinë të menaxhuar nuk bëhet kurrë skedar, dhe rruga e regjistrimit të tij është zakonisht një mjet i veçantë dhe jo një komandë OpenSSL. Në çdo rast, askush nuk ka nevojë të shohë gjysmën private.

Rrjedha softuerike duket kështu, me çelësin dhe kërkesën të krijuara në një sesion:

umask 077
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out client.key
openssl req -new -key client.key -out client.csr -subj "/CN=alice-vpn/O=Example"

Rreshti umask ka më shumë rëndësi sesa duket. Pa të çelësi shkruhet i lexueshëm nga të gjithë në një sistem lejues si parazgjedhje, dhe kopjimi i skedarit më vonë e përhap atë. Ripërdorimi i një çelësi ekzistues është i ligjshëm kur ai është tashmë i mbrojtur dhe përputhet me politikën tuaj; gjenerimi i një çelësi të ri për çdo pajisje është më i lehtë për t'u justifikuar.

Hapi 2: vendosni identitetin në kërkesë, jo në email

Vendosni se çfarë autentifikon në të vërtetë VPN-ja përpara se të krijohet kërkesa, sepse ajo përgjigje i përket brenda CSR-së. OpenVPN tradicionalisht e lidh identitetin e klientit me emrin e përbashkët të certifikatës, dhe mjetet si strongSwan përputhin një varg identiteti me subjektin ose një emër alternativ të subjektit. Një email që thotë se më quajnë alice nuk është provë, dhe një kërkesë subjekti i së cilës thotë të njëjtën gjë është vetëm pak më e mirë.

Shtoni një emër alternativ të subjektit kur verifikuesi juaj kontrollon një, pasi përputhja moderne shpesh e injoron CN-në e vjetër:

openssl req -new -key client.key -out client.csr \
  -subj "/CN=alice-vpn/O=Example" \
  -addext "subjectAltName=DNS:alice-vpn"

Mbajeni CN-në të shkurtër, të qëndrueshëm dhe të lidhur me llogarinë dhe jo me një model laptopi. Një emër që përmban numrin serial të pajisjes së përdoruesit është një problem mbështetjeje që pret zëvendësimin e parë të harduerit.

Hapi 3: verifikoni kërkesën përpara se ta nënshkruani

Lëshuesi verifikon dy gjëra të ndryshme, dhe përzierja e tyre është gabimi klasik. Së pari, që kërkesa është e qëndrueshme nga brenda: nënshkrimi verifikohet kundrejt çelësit publik që ajo mban. Së dyti, që kërkuesi ka të drejtë për atë që kërkon kërkesa, dhe kësaj asnjë kontroll kriptografik nuk mund t'i përgjigjet.

Pjesa mekanike është një komandë e vetme, dhe ajo duhet të shtypë një rezultat verifikimi së bashku me subjektin:

openssl req -in client.csr -noout -verify -subject
openssl req -in client.csr -noout -pubkey | openssl pkey -pubin -noout -text

Vini re çfarë provon kjo. Një kërkesë që verifikohet tregon vetëm se dërguesi kishte çelësin privat përputhës në momentin e parashtrimit; ajo nuk provon se dërguesi është personi i emërtuar në subjekt, dhe nuk autorizon aksesin në grupin ose rrugën e kërkuar. Rishikimi i regjistrimit është një portë e veçantë, dhe një kërkesë për një grup që askush nuk e miratoi duhet të refuzohet në vend që të redaktohet në heshtje.

Hapi 4: autorizoni, pastaj nënshkruani me zgjerime eksplicite

Nënshkrimi është vendi ku CA vendos politikën në vend që ta pranojë kërkesën fjalë për fjalë. Vlefshmëria, përdorimi i çelësit dhe zgjerimi i rolit i përkasin një skedari zgjerimesh, jo vlerave parazgjedhje që nuk do t'i mbani mend gjashtë muaj më vonë. Një certifikatë klienti për autentifikim VPN ka nevojë për autentifikim klienti si qëllim të saj.

cat > client.ext <<'EOF'
basicConstraints = CA:FALSE
keyUsage = digitalSignature
extendedKeyUsage = clientAuth
EOF
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -days 365 -extfile client.ext -out client.crt

Përdorni -CAserial me skedarin ekzistues serial nëse një i tillë është tashmë në përdorim, dhe mbajeni çelësin e CA jashtë linje ose në magazinën e mbrojtur që përmend politika juaj. Numrat serialë të certifikatave duhet të jenë unikë për çdo lëshues; rikrijimi i skedarit serial nga e para rrezikon përplasje që e bëjnë revokimin të paqartë.

Regjistroni çfarë u lëshua: numri serial, subjekti, identiteti i kërkuar, personi miratues dhe skadimi. Ai regjistër është ai nga i cili varet më vonë një vendim revokimi, dhe ai nuk mund të rindërtohet vetëm nga certifikata nëse gjurma e regjistrimit jeton vetëm në një kuti postare.

Hapi 5: instalojeni pranë çelësit përputhës dhe provoni çiftin

Klienti merr certifikatën dhe zinxhirin e lëshuesit, kurrë një çelës. Përpara lidhjes, konfirmoni se certifikata vërtet çiftëzohet me çelësin që ndodhet tashmë në disk, sepse një çift i papërputhshëm prodhon një dështim shtrëngimi duarsh konfuz shumë më vonë:

openssl x509 -in client.crt -noout -pubkey | openssl pkey -pubin -outform DER | openssl sha256
openssl pkey -in client.key -pubout -outform DER | openssl sha256

Të dy përmbledhjet duhet të përputhen. Pastaj lidhuni dhe konfirmoni se identiteti që regjistron serveri është ai që autorizuat, dhe jo thjesht se tuneli u ngrit. Nëse çelësi humbet ose pajisja zëvendësohet, përgjigjja është revokim plus një kërkesë e re nga pajisja e re; kërkimi i administratorit për të kthyer një çelës nga diku tjetër nuk e rikuperon origjinalin dhe e thyen në heshtje modelin që e bënte kërkesën të sigurt.