Añadir un cliente VPN sin reconstruir la CA

Necesitas otro certificado para otro portátil, pero el primer tutorial de los resultados empieza con una orden que borra el directorio PKI. Esa orden pertenece a la instalación inicial, no a la inscripción, y ejecutarla te cuesta la CA, el historial de emisión y todos los perfiles de cliente que confiaban en el emisor antiguo. La decisión es más estrecha: conserva tu emisor un estado utilizable y encaja el nuevo dispositivo en la política de inscripción? Tres condiciones lo deciden y solo una justifica reconstruir.

Qué destruye realmente una reconstrucción

Reinicializar una PKI sustituye el directorio por una estructura vacía: nueva clave y certificado de CA, base de emisión vacía y contador de series nuevo. Los clientes no siguen en silencio; sus perfiles fijan la CA antigua, así que cada dispositivo debe reinscribirse, y los inaccesibles a mano.

La pérdida más silenciosa es la contabilidad. La revocación depende de saber qué números de serie emitiste y a quién. Borra el índice y aún puedes firmar, pero no afirmar con confianza cuáles de los certificados pendientes querías revocar. Un directorio de CA con certificados sin el estado del emisor restaura la mitad equivocada.

Copiar la clave privada de la CA junto al servidor en marcha es el otro atajo que conviene rechazar: convierte una autoridad de firma que debe estar fuera de línea en otro archivo de un host que termina tráfico no confiable.

Condición uno: sigue accesible el estado del emisor?

Localiza el directorio en el que el servidor confía de verdad antes de decidir. Compara el certificado que presenta como CA con el del directorio PKI por huella, no por nombre de archivo:

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

Si las huellas coinciden, la inscripción es incremental y no debes reconstruir nada. Si difieren, vas a firmar con una CA en la que el servidor no confía: el certificado se instala limpio y falla en el saludo, y ese error se diagnostica durante horas como un fallo del cliente.

Después busca el estado de emisión: el índice, el contador de series y el archivo del número de CRL. Si falta el índice pero sobrevive la clave, puedes emitir, pero heredas un problema de registro de revocaciones. Anótalo en el registro de cambios, porque la próxima revocación lo revelará.

Condición dos: quién custodia la nueva clave privada?

Es la decisión que sienten los usuarios, así que tómala explícitamente. Una clave generada en el cliente y enviada como solicitud deja la mitad privada en el dispositivo desde la primera orden y el administrador nunca la toca. Una clave generada en el servidor es más fácil para dispositivos sin herramientas, pero convierte al administrador en custodio de todas las claves y amplía el impacto de un compromiso.

Con Easy-RSA 3 contra una CA existente, importar y firmar una solicitud son dos órdenes:

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

Elige el tipo de certificado a propósito. Una solicitud firmada como certificado de servidor en lugar de cliente produce un archivo que parece correcto y el par rechaza, y el error rara vez dice por qué. Si firmas con openssl ca, la misma elección vive en las extensiones que pasas, no en la sección por defecto.

Condición tres: necesita el servidor más que un certificado?

Para un servidor OpenVPN normal con autenticación por certificado, el certificado es la inscripción: el nombre común pasa a ser la identidad del cliente, y cualquier directorio, ruta empujada o dirección estática depende de ese nombre. Añade el certificado y olvida la configuración y el túnel conecta mientras las rutas necesarias no aparecen.

Las plataformas cambian esto. OpenVPN Access Server mantiene su propia base de usuarios, así que un certificado firmado no es una cuenta; la cuenta debe existir y estar permitida. Otras puertas de enlace asocian una cadena de identidad a un grupo. Inscribir un dispositivo suele tocar dos sistemas, y el certificado es solo el primero.

El procedimiento incremental y cuándo reconstruir

La secuencia que añade un dispositivo sin daños: confirma el emisor por huella, toma una copia nueva del directorio PKI, importa y firma la solicitud para el rol de cliente, entrega el certificado con su cadena por el canal aprobado y verifica antes de que el usuario conecte:

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

La línea de propósito debe mostrar SSL client. Termina actualizando la copia de la CA después de la emisión, porque una copia anterior al nuevo número de serie restaura un estado sin el dispositivo que acabas de añadir.

Reconstruir es correcto en tres casos: la clave de la CA está comprometida, el estado de emisión se perdió sin remedio o cambias deliberadamente el algoritmo o la política. Los tres son proyectos con un plan de reinscripción para cada cliente, no pasos de una solicitud de un dispositivo. Si no aplica ninguno, inscribe de forma incremental.