Los inicios de sesión nuevos de VPN fallan con certificados válidos: revise la CRL

Certificados con meses por delante e inicios de sesión que fallan de inmediato apuntan a dos objetos distintos con dos relojes distintos. El servidor rechaza conexiones porque la lista de certificados revocados que consulta ha superado su propia fecha de caducidad, no porque los certificados de los usuarios se hayan quedado obsoletos. Renovar un certificado de usuario no hace nada por esa lista.

Separar los dos calendarios es todo el diagnóstico, y cambia cómo debe ser la solución.

Dos relojes, y solo uno de ellos es el certificado

Un certificado lleva una ventana de validez. Una lista de revocación de certificados lleva su propia ventana, además de un emisor y una firma, y los verificadores se niegan a confiar en una lista cuya hora de próxima actualización ya pasó. Cuando eso ocurre, el cliente presenta un certificado perfectamente válido y el servidor aun así corta la conexión con un mensaje sobre la lista. Los usuarios leen ese mensaje como «el certificado caducó», lo que envía la solicitud de renovación al lugar equivocado.

Los dos objetos también tienen propietarios distintos: el certificado procede de la CA que lo emitió, mientras que la lista la genera según un calendario quien opera esa CA. Un usuario no puede refrescarla, y reemitir certificados no puede prolongarla.

Lea la lista que el servicio carga realmente

Empiece por la configuración en ejecución en lugar de por el archivo que espera. La ruta de crl-verify puede ser absoluta, relativa al perfil o una copia incrustada en una imagen, y el verificador lee esa copia. Inspecciónela en su sitio con openssl crl -in /etc/openvpn/crl.pem -noout -issuer -lastupdate -nextupdate y compare las fechas con el reloj del servidor.

Luego confirme que el archivo es realmente el que se usa: compruebe su firma con openssl crl -in /etc/openvpn/crl.pem -CAfile /etc/openvpn/ca.crt -noout, que informa un resultado de verificación en lugar de imprimir los campos en silencio. Una lista firmada por otra CA, o una copia antigua dejada en un segundo directorio, falla exactamente igual que una caducada.

Vuelva a generar desde la base de datos de revocación, no desde cero

La lista nueva tiene que venir de la base de datos de revocación actual de la CA, mediante el proceso de firma aprobado. Generar una lista vacía, o regenerarla desde una copia de seguridad antigua del índice, deshace en silencio la revocación de cada identidad añadida desde esa copia. Eso convierte una caída de inicio de sesión en una regresión de seguridad, y nadie se da cuenta porque el síntoma desaparece.

Mantenga el paso de generación bajo control de versiones junto con el resto de las herramientas de la CA, para que el intervalo y la clave de firma queden documentados en lugar de recordados. Una entrada de runbook que nombre el comando, el firmante y el destino de publicación es suficiente. Así cualquiera de guardia puede regenerar sin adivinar qué archivo de índice es el autoritativo. Guarde el número de serie de la lista y la hora de próxima actualización junto con el registro de despliegue.

Despliegue donde mira el verificador

Copie la lista nueva a la ruta que lee el servicio, ajuste la propiedad y el modo para que la cuenta del servicio pueda leerla pero otros no, y recargue o reinicie según el comportamiento documentado. Si el daemon almacena la lista al arrancar, reemplazar el archivo sin recargar no cambia nada que el proceso en ejecución vaya a notar. Confirme la marca de tiempo que el proceso informa tras la recarga.

Si varios servicios verifican clientes, despliegue en cada uno de ellos. Actualizar un extremo y dejar otro con la copia antigua produce un fallo que solo aparece en los usuarios que aterrizan en el segundo. Mantenga una lista corta de esos extremos en el mismo runbook. Después del despliegue, compruebe la fecha de lista informada por cada uno en lugar de suponer que la copia llegó.

Haga visible la próxima fecha límite antes de que pase

Un intervalo de publicación más largo reduce la frecuencia de este incidente sin crear un proceso. Elija el intervalo según la política del operador y luego alerte sobre el campo de próxima actualización de la lista desplegada con suficiente antelación para regenerar y desplegar. Alerte sobre la copia desplegada, no sobre el host de la CA, porque la copia desplegada es la que falla.

Tras el despliegue, verifique ambas direcciones: un usuario permitido se conecta y una identidad revocada conocida sigue fallando. La segunda comprobación es la que atrapa una regeneración incompleta, y requiere un solo comando contra un perfil de prueba que usted mantiene justo para este propósito.