Manteña a clave de sinatura da CA de OpenVPN fóra de /etc/openvpn

Dous directorios que nun titorial parecen iguais fan traballos completamente distintos. Un contén a autoridade de certificación: a súa clave privada, o seu contador de números de serie e o rexistro de todo o que asinou. O outro contén o que o daemon necesita para arrincar e atender clientes. Poñer ambos no mesmo host baixo a mesma conta é cómodo durante unha tarde e caro durante o resto da vida do despregamento, porque o daemon pasa a executarse xunto á única clave que pode acuñar calquera identidade que queira.

Que contén o espazo de traballo da CA

Un directorio PKI é estado do emisor, non configuración. Contén a clave privada e o certificado da CA, un ficheiro de número de serie, un índice dos certificados emitidos e o material por identidade que se produciu a partir deles.

Asinar unha solicitude cambia ese estado, e por iso o espazo de traballo pertence a unha conta controlada polo administrador nun host onde o servizo VPN non se executa. Calquera que poida ler a clave privada da CA pode emitir un certificado no que o servidor confiará, así que a protección da clave é todo o modelo de confianza nun só ficheiro. Copiala a un segundo lugar para aforrar un paso crea unha segunda cousa que protexer e unha segunda cousa que esquecer. Cada sinatura tamén incrementa o número de serie e engade unha entrada ao índice, e por iso o espazo de traballo é unha copia de estado e non un cartafol de ficheiros.

O certificado público da CA é distinto. Está pensado para distribuírse, e é o que clientes e servidores usan para verificarse mutuamente.

Que le o daemon ao arrincar

Un servidor en funcionamento consume un conxunto pequeno: o seu propio certificado, a súa propia clave privada, o certificado da CA para verificar os pares e o material de claves que exixa o modo elixido. Le esas rutas ao arrincar e de novo ao recargar.

A propiedade debe avaliarse contra a unidade que realmente se inicia, non contra un shell de root interactivo. O illamento declarado pode facer que parte do sistema de ficheiros sexa de só lectura ou invisible mesmo cando unha proba manual como root ten éxito.

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

Esa terceira liña é a que a xente salta. Pregunta á propia conta do daemon se pode ler a clave, que é a única versión da pregunta que importa unha vez cedidos os privilexios. Unha saída cero como root non di nada sobre o que ocorre tras a cesión.

Paga a pena separar as dúas rutas de fallo antes de cambiar calquera permiso. Un fallo de sinatura apunta ao directorio PKI, ao permiso de busca nos seus directorios pai e á conta que executa o emisor. Un fallo de arrinque apunta á unidade, ao seu directorio de traballo e ás rutas nomeadas na configuración do servidor. Facer toda a árbore lexible por todos non arranxa ningunha das dúas e elimina a fronteira da que dependen ambas.

Por que copiar a clave da CA ao servidor falla máis adiante

A copia adoita comezar como un movemento de depuración: alguén quere renovar un cliente no host de VPN, así que a clave da CA acaba en /etc/openvpn e a renovación funciona. A tarefa inmediata ten éxito e a fronteira desapareceu.

Logo faise unha copia de seguridade do servidor, e a autoridade de sinatura únese ás copias. Unha instantánea, un paquete de soporte ou unha copia do directorio de configuración agora leva a capacidade de emitir identidades de confianza mentres a CA sexa válida. Quen teña esa copia pode acuñar un certificado para calquera nome que o servidor acepte, incluídos nomes que nunca se emitiron. O único rexistro desa emisión é o que eles decidan conservar.

Recuperarse dese estado non é cuestión de borrar un ficheiro. Hai que decidir se a clave quedou exposta, rotar a CA se foi así e redistribuír a confianza a cada par. Un espazo de traballo separado evita toda a conversa.

Contas, directorios, copias de seguridade

Dea ao emisor a súa propia conta e directorio persoal, fóra do host de VPN cando sexa práctico. Dea ao daemon unha conta distinta, con acceso de lectura ao material despregado e acceso de escritura a nada que emita certificados. Desprege copiando certificados públicos cara a fóra e nunca atraendo estado privado do emisor cara a dentro. Faga copias de seguridade dos dous roles por separado, porque a súa sensibilidade e as súas historias de restauración difiren.

Tras unha revocación, actualice o ficheiro CRL que nomea a configuración do servidor e logo recargue o servizo para que as conexións novas o lean. A documentación de Easy-RSA cobre a estrutura do espazo de traballo e o fluxo de sinatura; as regras de propiedade ao seu redor seguen sendo unha decisión sobre o seu host. Confirme o que cargou o servizo con openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate en lugar de supor que a recarga o recolleu.

Unha proba que demostra a separación

Comprobe o caso negativo, non só o que funciona. Asine un certificado desde a conta do emisor segundo o deseño e logo confirme que esa mesma conta non pode iniciar o servizo nin ler a clave privada do servidor. Despois confirme que a conta do daemon non pode ler a clave privada da CA.

Eses tres controis levan uns minutos e sobreviven aos cambios de persoal, porque son afirmacións sobre permisos e non sobre costumes. Escriba o resultado coas rutas e contas que cubriu, ademais da data en que os executou. A seguinte persoa que herde este despregamento, se non, volverá deducir a fronteira a partir dun titorial que nunca a tivo. Un rexistro datado é tamén o que fai que a próxima revisión tarde minutos en lugar dunha tarde.