La revocación de certificados falla: qué host no alcanza qué

Los certificados pueden estar dentro de su periodo de validez mientras la VPN sigue informando de un fallo de autenticación, y alguien concluye que el certificado está revocado. Son tres hechos distintos. Los datos de revocación los debe obtener el dispositivo que realiza la validación, desde un punto de publicación indicado dentro del propio certificado. Cuando ese dispositivo no puede alcanzar el punto, la comprobación falla por motivos que nada tienen que ver con el estado del certificado.

El validador es dueño de la ruta de descarga

Empiece identificando al validador. Cuando un portátil comprueba el certificado de la puerta de enlace, la descarga la hace el portátil; cuando la puerta de enlace comprueba un certificado de cliente, la hace la puerta de enlace. Un servicio de autenticación en segundo plano puede añadir un tercer validador con su propia posición de red. Cada uno tiene una ruta distinta a internet y una configuración de proxy distinta. Las pruebas recogidas en la estación de trabajo de un administrador no dicen nada sobre un servidor dentro de una DMZ.

Anote el certificado, el validador, la hora del intento y el código de estado exacto antes de cambiar nada.

Lea el punto de publicación del certificado

El certificado indica dónde vive su estado. Lea esos campos en lugar de adivinar una dirección de CA.

openssl x509 -in gateway.cer -noout -text | grep -A3 "CRL Distribution Points"
openssl x509 -in gateway.cer -noout -text | grep -A2 "Authority Information Access"

La primera extensión enumera puntos de distribución de CRL, y la segunda enumera métodos de acceso a la información de la autoridad, que pueden cubrir el estado OCSP y la obtención del certificado del emisor. Son mecanismos distintos, y un respondedor OCSP no es un archivo CRL. El host de publicación suele ser un servidor web corriente y no la máquina de la CA, porque un emisor sin conexión puede firmar una CRL que distribuye otro servidor. Por eso, una regla de cortafuegos descrita como acceso a la CA es demasiado vaga para implementarla o revisarla.

Pruebe la descarga desde el dispositivo que valida

Ejecute la prueba de descarga en el entorno que realmente realiza la validación, con material de certificado aprobado y sin claves privadas.

certutil -urlfetch -verify .\client-test.cer
curl -sS -o /dev/null -w "%{http_code}\n" http://crl.example.com/ca.crl

La ejecución de certutil verifica la cadena e informa de qué descargas de URL tuvieron éxito o fallaron, mientras que la llamada a curl prueba una dirección de publicación desde el mismo host y solo devuelve un código de estado. Una descarga fallida desde una dirección accesible apunta a problemas de contenido o de firma; un error de conexión apunta a enrutamiento, DNS o proxy. Conserve ambos resultados, porque una descarga correcta no demuestra que toda la cadena sea utilizable. Cambie el host y la ruta del ejemplo por el punto de distribución encontrado en el certificado.

Separe los datos ausentes del estado revocado

Cuatro resultados parecen iguales desde fuera: el punto no es accesible, la lista está obsoleta, la lista está firmada por el emisor equivocado o el certificado realmente está revocado. Solo el último es un resultado de estado, y solo ese justifica retirar el acceso. El almacenamiento en caché complica aún más el panorama, porque los datos obtenidos antes pueden ocultar una ruta de publicación rota hasta el siguiente refresco. Desactivar la comprobación de revocación, borrar certificados no relacionados o reiniciar la puerta de enlace sustituyen el diagnóstico por actividad.

Tras la corrección, fuerce una autenticación nueva y confirme que la descarga de estado prevista tiene éxito. Donde exista una identidad de prueba controlada, confirme que sigue siendo rechazada, porque una disponibilidad que elimina la comprobación no es una reparación.