Qué comprueba tu cliente VPN antes de confiar en un certificado

Tu cliente VPN dice que el certificado no se pudo verificar, y el diálogo termina ahí. El archivo está, el servidor funciona, y el mismo perfil funcionó en otro portátil el mes pasado. Bajo ese aviso de una línea, el cliente pasó el certificado del par por cuatro puertas: una autoridad de certificación que configuraste avala la ruta de firma, esa ruta llega a la autoridad, el nombre del par es el que pediste, y el certificado es utilizable ahora para este propósito. Encuentra la puerta que se cerró y la reparación suele ser un archivo; salta ese paso y reimportarás paquetes toda la tarde.

Lee el diálogo antes de editar el perfil

Los errores de certificado los redacta la biblioteca de debajo, no el producto VPN que instalaste, así que la cadena exacta es tu primera prueba. «No se puede obtener el certificado del emisor local» apunta a la ruta o al ancla de confianza. «El certificado ha caducado o aún no es válido» apunta al tiempo. «Propósito del certificado no admitido» apunta al uso extendido de la clave. Un desajuste de nombre te dice qué nombre quería. Ninguno de los cuatro se repara reinstalando el cliente.

Sube el nivel de registro antes de cambiar nada. OpenVPN informa del fallo de verificación en torno al saludo cuando lo ejecutas con --verb 4, y strongSwan escribe sus decisiones de identidad y cadena en el registro charon. Después confirma qué certificado estás inspeccionando, porque la gente suele probar el archivo del disco mientras el perfil incrusta una copia más antigua. Cuando el perfil incrusta bloques PEM, el certificado incrustado es el que se prueba.

Una autoridad de certificación firma identidades, no permisos

La autoridad guarda un nombre y una clave de firma. Emite certificados que vinculan una clave pública a ese nombre según su propia política, con una ventana de validez y restricciones de uso adjuntas. Tu cliente solo necesita el certificado de la autoridad para reconocer al emisor; nunca necesita la clave de firma, y enviar esa clave a los clientes les daría la capacidad de acuñar cualquier identidad en la que confíe el despliegue.

Confiar en una autoridad convierte en candidato todo certificado que firmó, no en el par correcto. Un certificado de servidor web de la misma CA interna también es candidato. Por eso existen las puertas de nombre y propósito, y por eso una clave de CA comprometida importa más que cualquier servidor individual: alcanza cada identidad que la autoridad emitió alguna vez. Entrega certificados de cliente por dispositivo, para que un portátil perdido sea una revocación y no una regeneración de claves en todo el despliegue.

Reconstruye la ruta que el cliente intenta construir

La ruta va del certificado del par, a través de cero o más intermedios, hasta una raíz en tu almacén de confianza. Un intermedio ausente es el fallo de cadena más común, y desde el lado del cliente se ve idéntico a una raíz no confiable. Lee primero la hoja y luego deja que OpenSSL construya la ruta con el material que piensas enviar.

openssl x509 -in server.crt -noout -subject -issuer -dates
openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt
openssl verify -show_chain -CAfile root.crt -untrusted intermediate.crt server.crt

Un estado de salida cero significa que la ruta se construyó con esos archivos; un fallo nombra el certificado que no pudo alcanzar. Si openssl verify tiene éxito mientras el cliente sigue negándose, la diferencia está en lo que el servidor envía realmente o en qué archivo de confianza carga el perfil. En OpenVPN, los intermedios pueden viajar con el archivo del certificado del servidor o entregarse por separado con --extra-certs, y un paquete con dos raíces escritas bajo el mismo nombre de sujeto enviará a uno de tus clientes por la rama equivocada.

El nombre y el propósito son puertas separadas

La construcción de la cadena nunca pregunta si el nombre es tuyo. OpenVPN solo lo comprueba cuando el perfil define --verify-x509-name, y la vieja costumbre de cotejar solo el nombre común se rompe con certificados cuyas identidades viven en subjectAltName. Los despliegues IKEv2 cotejan la identidad configurada con las entradas SAN o con el nombre distinguido, según el cliente, y un valor comodín o %any desactiva en silencio la comparación que creías tener.

Después vienen el tiempo y el propósito. Un portátil cuyo reloj va unas horas adelantado rechaza un certificado que aún no es válido, y un intermedio caducado hace fallar la ruta mientras la hoja está vigente. Los fallos de propósito vienen de un certificado sin serverAuth en el uso extendido de la clave, o con un keyUsage que no permite la firma del saludo, lo que OpenSSL informa como propósito de certificado no admitido. Reemite desde la plantilla correcta; nada en ese mensaje es motivo para desactivar la verificación.

La revocación solo funciona si alguien la configuró

Una CRL o una respuesta OCSP no se consultan automáticamente. En un servidor OpenVPN, los certificados de cliente se comprueban contra una lista solo cuando --crl-verify apunta a una. La comprobación del certificado del servidor por parte del cliente depende de la implementación y a menudo no existe. strongSwan necesita su complemento de revocación y una política antes de mirar una CRL para un par.

Eso explica el ticket que acabarás recibiendo: un certificado de cliente revocado sigue conectándose, y todos concluyen que la revocación está rota. Nada estaba comprobando. Publica y refresca la CRL, o mantén los certificados de cliente tan efímeros que una revocación obsoleta importe poco tiempo, y ensaya la ruta de revocación con un certificado de laboratorio antes de necesitarla durante un incidente.

Un orden de reparación que mantiene la verificación activa

Ordena por síntoma antes de tocar archivos, porque cada fila de la tabla te envía a un objeto distinto.

Recorre la lista de una pasada: confirma el archivo que carga el perfil, construye la ruta tú mismo, comprueba que el servidor envía el intermedio, compara el reloj, lee el SAN, lee el EKU, y luego reconecta y observa cómo desaparece la misma línea de registro. Si a un dispositivo no se le puede dar ninguna CA, el pinning es la alternativa honesta, porque OpenVPN 2.6 acepta --peer-fingerprint y reduce la confianza a una clave en lugar de eliminar la comprobación. RFC 5280 es la referencia de qué significa cada uno de esos campos.