¿El certificado VPN revocado sigue conectando? Comprueba la aplicación de la CRL

Revocaste el certificado, generaste una lista nueva y el perfil antiguo sigue levantando un túnel. La revocación en sí no está rota: una CRL es una declaración firmada de que un número de serie ya no es válido, y solo cambia el acceso cuando el componente que termina TLS la carga, para el emisor correcto, antes de tomar la decisión de aceptación. Ahí está la mayoría de estos casos, y por eso revocación y denegación son dos hechos distintos.

Recorre las cinco comprobaciones siguientes en orden y detente en la primera que no se cumpla, porque cada comprobación posterior da por ciertas las anteriores.

Comprueba qué componente toma la decisión de aceptación

Identifica el proceso que valida el certificado del cliente, porque solo ese proceso puede aplicar una lista. En un servidor OpenVPN es el propio daemon, configurado con crl-verify. En ocserv es la línea crl de ocserv.conf. En strongSwan las entradas son las CRL cargadas junto con strictcrlpolicy. Un proxy o dispositivo que termina TLS delante de la VPN también puede ser el verificador real, y si lo es, el daemon que está detrás nunca ve el certificado del cliente.

WireGuard pertenece a otra categoría. No tiene certificados ni lista de revocación; un par se admite por su clave pública en la configuración, así que cortar el acceso significa eliminar esa clave. Si buscas una CRL en un despliegue solo de WireGuard, ese mecanismo no existe.

Ojo también con la trampa del lado del cliente. Un cliente que se niega a conectar porque no le gusta el certificado del servidor está aplicando la cadena del servidor, no revocando su propia credencial. Un certificado de usuario solo se revoca donde se valida ese certificado de usuario, y eso casi siempre es el lado del servidor.

Comprueba para qué emisor se firmó la lista

Una CRL está limitada a una CA emisora. Con una raíz y una intermedia, los certificados hoja vienen de la intermedia, así que la lista que importa es la CRL de la intermedia; la lista de la raíz no dice nada de esas hojas. Un verificador apuntado al archivo equivocado la analiza tan contento, no encuentra ninguna entrada coincidente y acepta todo.

Confirma el emparejamiento antes de tocar el daemon. El emisor del certificado debe coincidir con el subject de la lista:

openssl x509 -in client.crt -noout -issuer -serial
openssl crl  -in intermediate.crl -noout -issuer -lastupdate -nextupdate

Cuando ambos vienen de la misma CA, el número de serie impreso para el certificado es el valor que debe aparecer en la lista. Si no coinciden, tienes la CRL equivocada o la copia equivocada de ella.

La validez pertenece a la misma comprobación. Un nextUpdate en el pasado deja la lista obsoleta, y un verificador que falla en cerrado rechazará entonces a todos los clientes en lugar de solo al revocado.

Comprueba que el número de serie esté en la copia que cargó el daemon

Revocar escribe una entrada en la base de datos de la CA, y regenerar escribe un archivo nuevo. Ninguna de las dos acciones llega a un daemon en ejecución que cargó la copia antigua al arrancar. Volca la lista y busca el número de serie:

openssl crl -in intermediate.crl -noout -text | grep -i -A2 'Serial Number'
openssl ca -revoke client.crt
openssl ca -gencrl -out intermediate.crl

Después comprueba cómo recoge el archivo tu implementación. OpenVPN lee una ruta dada a crl-verify una vez al arrancar, así que una lista nueva necesita un reinicio o una señal de reinicio; la misma opción apuntada a un directorio se relee en cada conexión, y por eso existe el modo de directorio. strongSwan necesita recargar sus credenciales, por ejemplo con swanctl --load-creds. Que el archivo en disco sea correcto y que el verificador lo use son dos hechos distintos.

Comprueba la política para una lista ausente o caducada

Esta es la decisión que muchos despliegues nunca toman de forma explícita, y decide si la revocación te protege o deja a todos fuera. Fail-closed significa que ninguna información de revocación utilizable produce un rechazo; fail-open significa que el verificador continúa sin ella. strongSwan expone la elección como strictcrlpolicy. OpenVPN con crl-verify se niega a arrancar con un archivo que no puede leer o analizar, y una lista caducada aparece como un error de verificación TLS sobre una CRL caducada en lugar de como una aceptación silenciosa.

Elijas la dirección que elijas, la automatización importa más que la elección: una tarea que regenere la CRL antes de nextUpdate y una alerta cuando la copia desplegada envejezca evitan que cualquiera de las dos políticas se convierta en un incidente. La comprobación en línea con OCSP traslada la frescura a un respondedor, pero se aplica la misma regla, porque un verificador que no está configurado para comprobar la respuesta no cambia nada.

Comprueba la sesión activa y luego las copias de la clave

La revocación se evalúa durante la validación del certificado, que ocurre al conectar y al renegociar. Una sesión establecida sigue funcionando hasta que renegocia, y el valor predeterminado de OpenVPN es una vez por hora con reneg-sec 3600. Si la persona debe salir de la red ahora, termina la sesión además de publicar la lista, y luego confirma que se rechaza la reconexión.

Separa la credencial de sus copias. Borrar un perfil en un portátil no impide que otra copia de la misma clave privada se autentique; la revocación es lo que hace inútil cada copia, y solo cuando se cumplen las comprobaciones anteriores. Da a un dispositivo de sustitución su propio certificado para poder revocar uno sin tocar el otro.

Antes de darlo por terminado: el componente validador está identificado, el emisor de la lista coincide con el emisor de la hoja, el número de serie revocado está en la copia que el daemon cargó realmente, la política para listas ausentes o caducadas es deliberada y está monitorizada, y la sesión activa se terminó en lugar de esperar. Los formatos que hay detrás de todo esto se especifican en RFC 5280.