Manteniu la clau de signatura de la CA d’OpenVPN fora de /etc/openvpn

Dos directoris que en un tutorial semblen iguals fan feines completament diferents. Un conté l’autoritat de certificació: la seva clau privada, el comptador de sèrie i el registre de tot el que ha signat. L’altre conté el que el dimoni necessita per arrencar i servir clients. Posar tots dos al mateix amfitrió sota el mateix compte és convenient per a una tarda i car per a la resta de la vida del desplegament, perquè el dimoni passa a córrer al costat de l’única clau que pot encunyar qualsevol identitat que vulgui.

Què conté l’espai de treball de la CA

Un directori PKI és estat de l’emissor, no configuració. Conté la clau privada i el certificat de la CA, un fitxer de sèrie, un índex dels certificats emesos i el material per identitat que se n’ha produït.

Signar una sol·licitud canvia aquest estat, i per això l’espai de treball pertany a un compte controlat per l’administrador en un amfitrió on el servei VPN no s’executa. Qualsevol que pugui llegir la clau privada de la CA pot emetre un certificat que el servidor confiarà, de manera que la protecció de la clau és tot el model de confiança en un sol fitxer. Copiar-la a un segon lloc per estalviar un pas crea una segona cosa a protegir i una segona cosa a oblidar. Cada signatura també incrementa el número de sèrie i afegeix una entrada a l’índex, i per això l’espai de treball és una còpia d’estat i no una carpeta de fitxers.

El certificat públic de la CA és diferent. Està pensat per distribuir-se, i és el que clients i servidors fan servir per verificar-se mútuament.

Què llegeix el dimoni quan arrenca

Un servidor en funcionament consumeix un conjunt petit: el seu propi certificat, la seva pròpia clau privada, el certificat de la CA per verificar els parells i el material de claus que requereixi el mode triat. Llegeix aquests camins en arrencar i de nou en recarregar.

La propietat s’ha d’avaluar contra la unitat que realment s’inicia, no contra un shell root interactiu. L’aïllament declarat pot fer que part del sistema de fitxers sigui només de lectura o invisible fins i tot quan una prova manual com a root té èxit.

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 $?

Aquesta tercera línia és la que la gent s’estalvia. Pregunta al propi compte del dimoni si pot llegir la clau, que és l’única versió de la pregunta que importa un cop s’han deixat anar els privilegis. Una sortida zero com a root no diu res sobre què passa després de deixar-los anar.

Val la pena separar les dues vies de fallada abans de canviar cap permís. Una fallada de signatura apunta al directori PKI, al permís de cerca dels seus directoris pares i al compte que executa l’emissor. Una fallada d’arrencada apunta a la unitat, al seu directori de treball i als camins que nomena la configuració del servidor. Fer tot l’arbre llegible per tothom no arregla cap de les dues i elimina la frontera de la qual depenen totes dues.

Per què copiar la clau de la CA al servidor falla més tard

La còpia sol començar com un moviment de depuració: algú vol renovar un client a l’amfitrió VPN, així que la clau de la CA acaba a /etc/openvpn i la renovació funciona. La tasca immediata té èxit i la frontera ha desaparegut.

Llavors es fa una còpia de seguretat del servidor, i l’autoritat de signatura s’uneix a les còpies. Una instantània, un paquet de suport o una còpia del directori de configuració ara porta la capacitat d’emetre identitats de confiança mentre la CA sigui vàlida. Qui tingui aquesta còpia pot encunyar un certificat per a qualsevol nom que el servidor accepti, incloent-hi noms que mai no es van emetre. L’únic registre d’aquesta emissió és el que ells decideixin conservar.

Recuperar-se d’aquest estat no és qüestió d’esborrar un fitxer. Heu de decidir si la clau va quedar exposada, rotar la CA si és el cas i redistribuir la confiança a cada parell. Un espai de treball separat evita tota la conversa.

Comptes, directoris, còpies de seguretat

Donau a l’emissor el seu propi compte i directori personal, fora de l’amfitrió VPN quan sigui pràctic. Donau al dimoni un compte diferent, amb accés de lectura al material desplegat i accés d’escriptura a res que emeti certificats. Desplegueu copiant certificats públics cap a fora i mai estirant estat privat de l’emissor cap a dins. Feu còpies de seguretat de les dues funcions per separat, perquè la seva sensibilitat i les seves històries de restauració difereixen.

Després d’una revocació, actualitzeu el fitxer CRL que nomena la configuració del servidor i després recarregueu el servei perquè les connexions noves el llegeixin. La documentació d’Easy-RSA cobreix l’estructura de l’espai de treball i el flux de signatura; les regles de propietat al voltant continuen sent una decisió sobre el vostre amfitrió. Confirmeu què ha carregat el servei amb openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate en lloc de suposar que la recàrrega ho ha recollit.

Una prova que demostra la separació

Comproveu el cas negatiu, no només el que funciona. Signeu un certificat des del compte de l’emissor tal com està dissenyat, i després confirmeu que el mateix compte no pot iniciar el servei ni llegir la clau privada del servidor. Després confirmeu que el compte del dimoni no pot llegir la clau privada de la CA.

Aquestes tres comprovacions triguen uns minuts i sobreviuen als canvis de personal, perquè són afirmacions sobre permisos i no sobre hàbits. Escriviu el resultat amb els camins i els comptes que ha cobert, més la data en què les vau executar. La propera persona que hereti aquest desplegament, si no, tornarà a derivar la frontera d’un tutorial que mai no n’havia tingut. Un registre datat també és el que fa que la propera revisió trigui minuts en lloc d’una tarda.