Cum să generați o cheie de client VPN și să trimiteți un CSR spre semnare

Mai devreme sau mai târziu, un utilizator VPN oferă să trimită o cheie privată prin e-mail ca administratorul să poată face un certificat, și exact această ofertă trebuie refuzată. Fluxul care funcționează ține cheia la client din prima comandă: clientul o generează, trimite o cerere de semnare a certificatului, emitentul o verifică și o autorizează, iar certificatul semnat revine și stă lângă cheia care l-a creat. Lista de verificare de mai jos eșuează închis la fiecare pas, și acesta este rostul, pentru că două din cele cinci etape sunt exact cele pe care oamenii le sar când se grăbesc.

Pasul 1: generați cheia acolo unde va trăi

Generați pe mașina care va ține cheia și lăsați-o acolo. O cheie software ajunge într-un fișier cu permisiuni restrictive; o cheie susținută de hardware sau dintr-un depozit administrat nu devine niciodată fișier, iar calea ei de înregistrare este de obicei un instrument separat, nu o comandă OpenSSL. În orice caz, nimeni nu trebuie să vadă jumătatea privată.

Fluxul software arată astfel, cu cheia și cererea create într-o singură sesiune:

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"

Linia umask contează mai mult decât pare. Fără ea cheia este scrisă lizibil pentru toți pe un sistem permisiv implicit, iar copierea fișierului mai târziu răspândește asta. Reutilizarea unei chei existente este legitimă când este deja protejată și se potrivește cu politica dumneavoastră; generarea uneia noi pentru fiecare dispozitiv este mai ușor de justificat.

Pasul 2: puneți identitatea în cerere, nu în e-mail

Decideți ce autentifică de fapt VPN-ul înainte de a crea cererea, pentru că acel răspuns aparține în interiorul CSR-ului. OpenVPN leagă tradițional identitatea clientului de numele comun al certificatului, iar instrumente precum strongSwan potrivesc un șir de identitate cu subiectul sau cu un nume alternativ al subiectului. Un e-mail care spune că mă numesc alice nu este dovadă, iar o cerere al cărei subiect spune același lucru este doar puțin mai bună.

Adăugați un nume alternativ al subiectului când verificatorul dumneavoastră verifică unul, deoarece potrivirea modernă ignoră adesea vechiul CN:

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

Țineți CN-ul scurt, stabil și legat de cont, nu de un model de laptop. Un nume care conține numărul de serie al dispozitivului utilizatorului este o problemă de suport care așteaptă prima înlocuire de hardware.

Pasul 3: verificați cererea înainte de a o semna

Emitentul verifică două lucruri diferite, iar confundarea lor este greșeala clasică. În primul rând, că cererea este intern coerentă: semnătura este verificată față de cheia publică pe care o poartă. În al doilea rând, că solicitantul are dreptul la ceea ce cere cererea, iar la asta nicio verificare criptografică nu poate răspunde.

Partea mecanică este o singură comandă, și ar trebui să afișeze un rezultat al verificării împreună cu subiectul:

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

Observați ce demonstrează asta. O cerere care se verifică arată doar că expeditorul deținea cheia privată corespunzătoare la momentul depunerii; nu dovedește că expeditorul este persoana numită în subiect și nu autorizează accesul la grupul sau la ruta cerute. Revizuirea înregistrării este o poartă separată, iar o cerere pentru un grup pe care nimeni nu l-a aprobat ar trebui respinsă în loc să fie editată în tăcere.

Pasul 4: autorizați, apoi semnați cu extensii explicite

Semnarea este locul unde CA decide politica în loc să accepte cererea literal. Valabilitatea, utilizarea cheii și extensia de rol aparțin unui fișier de extensii, nu unor valori implicite pe care nu le veți ține minte șase luni mai târziu. Un certificat de client pentru autentificarea VPN are nevoie de autentificarea clientului ca scop.

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

Folosiți -CAserial cu fișierul de serie existent dacă unul este deja în uz și țineți cheia CA offline sau în depozitul protejat pe care îl numește politica dumneavoastră. Numerele de serie ale certificatelor trebuie să fie unice per emitent; recrearea fișierului de serie de la zero riscă coliziuni care fac revocarea ambiguă.

Înregistrați ce s-a emis: număr de serie, subiect, identitate solicitată, persoana care a aprobat și expirarea. Acel registru este ceea de ce depinde mai târziu o decizie de revocare și nu poate fi reconstruit doar din certificat dacă urma înregistrării trăiește doar într-o cutie poștală.

Pasul 5: instalați-l lângă cheia corespunzătoare și dovediți perechea

Clientul primește certificatul și lanțul emitentului, niciodată o cheie. Înainte de conectare, confirmați că certificatul formează într-adevăr o pereche cu cheia aflată deja pe disc, pentru că o pereche nepotrivită produce o eroare de strângere de mână confuză mult mai târziu:

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

Cele două rezumate trebuie să coincidă. Apoi conectați-vă și confirmați că identitatea pe care serverul o înregistrează este cea pe care ați autorizat-o, nu doar că tunelul a urcat. Dacă cheia se pierde sau dispozitivul este înlocuit, răspunsul este revocare plus o cerere nouă de la dispozitivul nou; a cere administratorului să trimită înapoi o cheie de altundeva nu recuperează originalul și rupe în tăcere modelul care făcea cererea sigură.