Mantenga la clave de firma de la CA de OpenVPN fuera de /etc/openvpn

Dos directorios que en un tutorial parecen iguales hacen trabajos completamente distintos. Uno contiene la autoridad de certificación: su clave privada, su contador de números de serie y el registro de todo lo que ha firmado. El otro contiene lo que el demonio necesita para arrancar y atender clientes. Poner ambos en el mismo host bajo la misma cuenta es cómodo durante una tarde y caro durante el resto de la vida del despliegue, porque el demonio pasa a ejecutarse junto a la única clave que puede acuñar cualquier identidad que desee.

Qué contiene el espacio de trabajo de la CA

Un directorio PKI es estado del emisor, no configuración. Contiene la clave privada y el certificado de la CA, un archivo de número de serie, un índice de los certificados emitidos y el material por identidad que se ha producido a partir de ellos.

Firmar una solicitud cambia ese estado, y por eso el espacio de trabajo pertenece a una cuenta controlada por el administrador en un host donde el servicio VPN no se ejecuta. Cualquiera que pueda leer la clave privada de la CA puede emitir un certificado en el que el servidor confiará, así que la protección de la clave es todo el modelo de confianza en un solo archivo. Copiarla a un segundo lugar para ahorrar un paso crea una segunda cosa que proteger y una segunda cosa que olvidar. Cada firma también incrementa el número de serie y añade una entrada al índice, y por eso el espacio de trabajo es una copia de estado y no una carpeta de archivos.

El certificado público de la CA es distinto. Está pensado para distribuirse, y es lo que clientes y servidores usan para verificarse mutuamente.

Qué lee el demonio al arrancar

Un servidor en funcionamiento consume un conjunto pequeño: su propio certificado, su propia clave privada, el certificado de la CA para verificar a los pares y el material de claves que exija el modo elegido. Lee esas rutas al arrancar y de nuevo al recargar.

La propiedad debe evaluarse contra la unidad que realmente se inicia, no contra un shell de root interactivo. El aislamiento declarado puede hacer que parte del sistema de archivos sea de solo lectura o invisible incluso cuando una prueba manual como root tiene é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 tercera línea es la que la gente se salta. Pregunta a la propia cuenta del demonio si puede leer la clave, que es la única versión de la pregunta que importa una vez que se han cedido los privilegios. Una salida cero como root no dice nada sobre lo que ocurre tras la cesión.

Merece la pena separar las dos rutas de fallo antes de cambiar cualquier permiso. Un fallo de firma apunta al directorio PKI, al permiso de búsqueda en sus directorios padre y a la cuenta que ejecuta el emisor. Un fallo de arranque apunta a la unidad, a su directorio de trabajo y a las rutas nombradas en la configuración del servidor. Hacer que todo el árbol sea legible por todos no arregla ninguna de las dos y elimina la frontera de la que dependen ambas.

Por qué copiar la clave de la CA al servidor falla más adelante

La copia suele empezar como un movimiento de depuración: alguien quiere renovar un cliente en el host de VPN, así que la clave de la CA acaba en /etc/openvpn y la renovación funciona. La tarea inmediata tiene éxito y la frontera ha desaparecido.

Luego se hace una copia de seguridad del servidor, y la autoridad de firma se une a las copias. Una instantánea, un paquete de soporte o una copia del directorio de configuración ahora conlleva la capacidad de emitir identidades de confianza mientras la CA sea válida. Quien tenga esa copia puede acuñar un certificado para cualquier nombre que el servidor acepte, incluidos nombres que nunca se emitieron. El único registro de esa emisión es el que ellos decidan conservar.

Recuperarse de ese estado no es cuestión de borrar un archivo. Hay que decidir si la clave quedó expuesta, rotar la CA si fue así y redistribuir la confianza a cada par. Un espacio de trabajo separado evita toda la conversación.

Cuentas, directorios, copias de seguridad

Dé al emisor su propia cuenta y directorio personal, fuera del host de VPN cuando sea práctico. Dé al demonio una cuenta distinta, con acceso de lectura al material desplegado y acceso de escritura a nada que emita certificados. Despliegue copiando certificados públicos hacia fuera y nunca atrayendo estado privado del emisor hacia dentro. Haga copias de seguridad de los dos roles por separado, porque su sensibilidad y sus historias de restauración difieren.

Tras una revocación, actualice el archivo CRL que nombra la configuración del servidor y luego recargue el servicio para que las conexiones nuevas lo lean. La documentación de Easy-RSA cubre la estructura del espacio de trabajo y el flujo de firma; las reglas de propiedad en torno a él siguen siendo una decisión sobre su host. Confirme qué cargó el servicio con openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate en lugar de suponer que la recarga lo recogió.

Una prueba que demuestra la separación

Compruebe el caso negativo, no solo el que funciona. Firme un certificado desde la cuenta del emisor según lo diseñado y luego confirme que esa misma cuenta no puede iniciar el servicio ni leer la clave privada del servidor. Después confirme que la cuenta del demonio no puede leer la clave privada de la CA.

Esas tres comprobaciones tardan unos minutos y sobreviven a los cambios de personal, porque son afirmaciones sobre permisos y no sobre costumbres. Escriba el resultado con las rutas y cuentas que cubrió, además de la fecha en que las ejecutó. La siguiente persona que herede este despliegue, si no, volverá a deducir la frontera a partir de un tutorial que nunca la tuvo. Un registro fechado es también lo que hace que la próxima revisión tarde minutos en lugar de una tarde.