Adăugarea unui client VPN fără reconstruirea CA

Ai nevoie de încă un certificat pentru încă un laptop, dar primul tutorial din rezultate începe cu o comandă care șterge directorul PKI. Comanda aceea aparține configurării inițiale, nu înregistrării, iar rularea ei te costă CA, istoricul emiterii și fiecare profil de client care avea încredere în emitentul vechi. Decizia este mai îngustă: emitentul mai are o stare utilizabilă și noul dispozitiv se încadrează în politica ta de înregistrare? Trei condiții decid, iar doar una justifică o reconstruire.

Ce distruge de fapt o reconstruire

Reinițializarea unei PKI înlocuiește directorul cu o structură goală: cheie și certificat CA noi, bază de date de emitere goală și un contor nou de serii. Clienții nu urmează de la sine; profilurile lor fixează CA veche, așa că fiecare dispozitiv trebuie reînregistrat, iar cele inaccesibile manual.

Pierderea mai tăcută este evidența. Revocarea depinde de a ști ce numere de serie ai emis și cui. Șterge indexul și poți semna în continuare, dar nu mai poți spune cu încredere care dintre certificatele emise voiai să le revoci. Un director CA cu certificate fără starea corespunzătoare a emitentului este o copie de siguranță care restaurează jumătatea greșită a sistemului.

Copierea cheii private a CA lângă serverul care rulează este cealaltă scurtătură pe care ar trebui să o refuzi: transformă o autoritate de semnare care ar trebui să stea offline într-un alt fișier pe un host cu trafic neîncrezut.

Prima condiție: starea emitentului mai este accesibilă?

Găsește directorul în care serverul chiar are încredere înainte de a decide. Compară certificatul pe care serverul îl prezintă ca CA cu cel din directorul PKI după amprentă, nu după numele fișierului:

openssl x509 -in ca.crt -noout -fingerprint -sha256
openssl x509 -in /etc/openvpn/ca.crt -noout -fingerprint -sha256

Dacă amprentele coincid, înregistrarea este incrementală și nu reconstruiești nimic. Dacă diferă, semnezi cu o CA în care serverul nu are încredere: certificatul se instalează curat și eșuează la strângerea de mână, iar eroarea este diagnosticată ore întregi drept defect al clientului.

Apoi caută starea emiterii: fișierul index, contorul de serii și fișierul numărului CRL. Dacă indexul lipsește dar cheia supraviețuiește, poți emite, dar moștenești o problemă cu înregistrarea revocărilor. Notează asta în jurnalul de modificări, pentru că următoarea cerere de revocare o va scoate la iveală.

A doua condiție: cine deține noua cheie privată?

Este decizia pe care utilizatorii o simt, așa că ia-o explicit. O cheie generată pe client și trimisă ca cerere păstrează jumătatea privată pe dispozitiv din prima comandă, iar administratorul nu o atinge niciodată. O cheie generată pe server este mai simplă pentru dispozitivele fără unelte, dar îl face pe administrator custodele fiecărei chei și lărgește impactul unui compromis.

Cu Easy-RSA 3 împotriva unei CA existente, importarea și semnarea unei cereri sunt două comenzi:

./easyrsa import-req /tmp/alice.req alice
./easyrsa sign-req client alice

Alege tipul certificatului deliberat. O cerere semnată ca certificat de server în loc de client produce un fișier care pare în regulă și este refuzat de partener, iar mesajul de eroare spune rar de ce. Cu openssl ca, aceeași alegere stă în extensiile pe care le transmiți, nu în secțiunea implicită.

A treia condiție: serverul are nevoie de mai mult decât un certificat?

Pentru un server OpenVPN obișnuit cu autentificare prin certificat, certificatul este înregistrarea: numele comun devine identitatea clientului, iar orice director, rută împinsă sau adresă statică depinde de acel nume. Adaugă certificatul și uită configurația, tunelul se conectează dar rutele necesare nu apar.

Platformele schimbă asta. OpenVPN Access Server are propria bază de utilizatori, așa că un certificat semnat nu este un cont; contul trebuie să existe și să fie permis. Alte gateway-uri asociază un șir de identitate unui grup. Înregistrarea unui dispozitiv atinge de obicei două sisteme, iar certificatul este doar primul.

Procedura incrementală și când reconstruirea este corectă

Secvența care adaugă un dispozitiv fără daune: confirmă emitentul prin amprentă, ia o copie proaspătă a directorului PKI, importă și semnează cererea pentru rolul de client, livrează certificatul cu lanțul său pe canalul aprobat și verifică înainte ca utilizatorul să se conecteze:

openssl verify -CAfile ca.crt alice.crt
openssl x509 -in alice.crt -noout -subject -issuer -dates -purpose

Linia de scop trebuie să arate SSL client. Încheie actualizând copia CA după emitere, pentru că o copie făcută înainte de înregistrarea noii serii restaurează o stare fără dispozitivul tocmai adăugat.

Reconstruirea este corectă în trei cazuri: cheia CA este compromisă, starea emiterii este pierdută iremediabil sau schimbi deliberat algoritmul cheii ori politica de certificate. Toate trei sunt proiecte cu un plan de reînregistrare pentru fiecare client, nu pași într-o cerere pentru un singur dispozitiv. Dacă niciunul nu se aplică, înregistrează incremental și lasă emitentul în pace.