Țineți cheia de semnare a CA OpenVPN în afara /etc/openvpn

Două directoare care într-un tutorial arată la fel fac treburi complet diferite. Unul conține autoritatea de certificare: cheia sa privată, contorul de numere de serie și evidența a tot ce a semnat. Celălalt conține ce are nevoie daemonul ca să pornească și să deservească clienți. Să le pui pe amândouă pe același host sub același cont este comod pentru o după-amiază și costisitor pentru restul vieții implementării, pentru că daemonul rulează atunci lângă singura cheie care poate crea orice identitate dorește.

Ce conține spațiul de lucru al CA

Un director PKI este stare a emitentului, nu configurație. Conține cheia privată și certificatul CA, un fișier cu numărul de serie, un index al certificatelor emise și materialul pe identitate produs din ele.

Semnarea unei cereri schimbă această stare, de aceea spațiul de lucru aparține unui cont controlat de administrator pe un host pe care serviciul VPN nu rulează. Oricine poate citi cheia privată a CA poate emite un certificat în care serverul va avea încredere, așa că protecția cheii este întregul model de încredere într-un singur fișier. Copierea ei într-un al doilea loc pentru a economisi un pas creează un al doilea lucru de protejat și un al doilea de uitat. Fiecare semnătură crește și numărul de serie și adaugă o intrare în index, de aceea spațiul de lucru este o singură copie de stare, nu un dosar de fișiere.

Certificatul public al CA este diferit. Este destinat distribuirii și este ceea ce folosesc clienții și serverele pentru a se verifica reciproc.

Ce citește daemonul la pornire

Un server în funcțiune consumă un set mic: propriul certificat, propria cheie privată, certificatul CA pentru verificarea partenerilor și orice material de chei cere modul ales. Citește aceste căi la pornire și din nou la reîncărcare.

Proprietatea trebuie evaluată față de unitatea care pornește efectiv, nu față de un shell root interactiv. Izolarea declarată poate face o parte a sistemului de fișiere doar-citire sau invizibilă chiar și atunci când un test manual ca root reușește.

systemctl show -p User -p Group -p ReadOnlyPaths [email protected]
stat -c '%a %U:%G' /etc/openvpn/server/server.key
runuser -u openvpn -- test -r /etc/openvpn/server/server.key; echo $?

A treia linie este cea pe care oamenii o sar. Întreabă contul propriu al daemonului dacă poate citi cheia, și aceasta este singura versiune a întrebării care contează după ce privilegiile au fost abandonate. O ieșire zero ca root nu spune nimic despre ce se întâmplă după abandon.

Merită să separați cele două căi de eșec înainte de a schimba vreo permisiune. O eroare de semnare indică directorul PKI, permisiunea de căutare pe directoarele sale părinte și contul care rulează emitentul. O eroare de pornire indică unitatea, directorul ei de lucru și căile numite în configurația serverului. A face tot arborele citibil de toți nu repară niciuna și elimină granița de care depind amândouă.

De ce copierea cheii CA pe server eșuează mai târziu

Copia începe de obicei ca o mișcare de depanare: cineva vrea să reînnoiască un client pe hostul VPN, așa că cheia CA ajunge în /etc/openvpn și reînnoirea funcționează. Sarcina imediată reușește, iar granița a dispărut.

Apoi serverul este salvat, iar autoritatea de semnare intră în copiile de siguranță. Un instantaneu, un pachet de suport sau o copie a directorului de configurare poartă acum capacitatea de a emite identități de încredere cât timp CA este validă. Cine deține acea copie poate crea un certificat pentru orice nume acceptat de server, inclusiv nume care nu au fost niciodată emise. Singura evidență a acelei emiteri este cea pe care aleg să o păstreze.

Recuperarea din acea stare nu este o chestiune de ștergere a unui fișier. Trebuie să decideți dacă cheia a fost expusă, să rotiți CA dacă a fost, și să redistribuiți încrederea către fiecare partener. Un spațiu de lucru separat evită toată conversația.

Conturi, directoare, copii de siguranță

Dați emitentului propriul cont și director home, ținute departe de hostul VPN unde este practic. Dați daemonului un cont diferit, cu acces de citire la materialul implementat și acces de scriere la nimic care emite certificate. Implementați copiind certificate publice spre exterior și niciodată trăgând starea privată a emitentului spre interior. Faceți copii de siguranță ale celor două roluri separat, pentru că sensibilitatea și poveștile lor de restaurare diferă.

După o revocare, actualizați fișierul CRL pe care îl numește configurația serverului, apoi reîncărcați serviciul pentru ca noile conexiuni să îl citească. Documentația Easy-RSA acoperă structura spațiului de lucru și fluxul de semnare; regulile de proprietate din jurul lui rămân o decizie despre hostul dumneavoastră. Confirmați ce a încărcat serviciul cu openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate în loc să presupuneți că reîncărcarea l-a preluat.

Un test care dovedește separarea

Verificați cazul negativ, nu doar pe cel funcțional. Semnați un certificat din contul emitentului conform proiectării, apoi confirmați că același cont nu poate porni serviciul și nu poate citi cheia privată a serverului. Apoi confirmați că contul daemonului nu poate citi cheia privată a CA.

Cele trei verificări durează câteva minute și supraviețuiesc schimbărilor de personal, pentru că sunt afirmații despre permisiuni, nu despre obiceiuri. Scrieți rezultatul cu căile și conturile pe care le-a acoperit, plus data la care le-ați rulat. Următoarea persoană care moștenește această implementare va deriva altfel din nou granița dintr-un tutorial care nu a avut niciodată una. O evidență datată este și ceea ce face ca următoarea revizuire să dureze minute în loc de o după-amiază.