Mismo nombre de archivo ca.crt, certificado distinto: qué comparar

Dos perfiles traen ambos un archivo llamado ca.crt, un túnel se levanta y el otro falla con un error de cadena. Abrir los dos archivos uno al lado del otro rara vez lo resuelve, y desactivar la verificación lo resuelve en la dirección equivocada. La pregunta que el error plantea en realidad es más estrecha: ¿qué certificado carga cada proceso como su ancla de confianza, y son los dos el mismo objeto? Responda eso primero y el resto del diagnóstico cobra dirección. El nombre del archivo es una etiqueta de empaquetado, y la ruta escrita en el perfil tampoco es autoritativa, así que todo depende de lo que el proceso lee en realidad.

Encuentre el certificado que el cliente carga en realidad

OpenVPN acepta la autoridad en dos formas, y la forma decide qué bytes importan. Un perfil puede apuntar a un archivo externo con ca, o incrustar el certificado dentro de un bloque <ca> en el propio perfil. Cuando existen ambos, gana el bloque incrustado y el archivo que está junto al perfil nunca se abre.

Lea el perfil que falla y averigüe qué forma usa antes de comparar nada. Una copia tomada de un directorio vecino, o del paquete del que salió el otro perfil, no le dice nada sobre lo que confía este proceso. Lo mismo vale para la ruta en la configuración: se resuelve respecto de donde se inició el cliente, que no siempre es el directorio que está mirando. Lea el perfil, no la carpeta.

Los certificados se identifican por su contenido: la clave pública, el sujeto y el emisor, la ventana de validez y la firma sobre todo ello. Dos archivos con bytes idénticos son el mismo certificado se llamen como se llamen, y dos archivos con el mismo nombre pueden ser autoridades sin relación. El nombre es una etiqueta de empaquetado, no una identidad.

Tome la huella de ambas copias con openssl

Una huella es un hash sobre la codificación DER del certificado, la forma que cubre la firma, así que los finales de línea y el texto de la cabecera no pueden afectarla. Calcúlela para cada archivo y tendrá dos cadenas hexadecimales separadas por dos puntos que o coinciden o no. No hace falta leer nada más del certificado para responder la pregunta de la comparación.

openssl x509 -in /etc/openvpn/office/ca.crt -noout -fingerprint -sha256
openssl x509 -in ~/profiles/lab-ca.pem -noout -fingerprint -sha256

Es tentador apuntar openssl al propio perfil, pero lee el primer bloque de certificado que aparece en el archivo, y un perfil suele llevar <cert> antes de <ca>. Extraiga el bloque de la autoridad y luego tome la huella del archivo extraído, porque esa es la copia que el cliente usará en realidad.

sed -n '/^<ca>$/,/^<\/ca>$/p' office.ovpn | sed '1d;$d' > /tmp/office-ca.pem
openssl x509 -in /tmp/office-ca.pem -noout -fingerprint -sha256

Huellas idénticas significan que el material de confianza es el mismo y que el error de cadena tiene otra causa, lo que es otra investigación. Huellas distintas significan certificados distintos, y ahí empieza la sección siguiente.

Lea una discrepancia antes de suponer un ataque

Huellas distintas significan certificados distintos y nada más. Una reemisión, una rotación, una autoridad renombrada o un paquete obsoleto producen todos archivos distintos con historias por completo legítimas. Cuál pertenece al despliegue es una pregunta para el operador o para el registro de despliegue, no para la hora de modificación del archivo. Los archivos de archivo copian marcas de tiempo, así que un archivo más nuevo no es automáticamente el ancla correcta.

Una raíz que se firma a sí misma es normal, así que encontrar una no es prueba de un problema. La tarea del verificador es construir una ruta desde el certificado del servidor hasta el ancla que se le entregó, y un error de cadena suele significar que esa ruta no se pudo completar.

Compruebe si el ancla del perfil que falla es una autoridad de la que el despliegue sigue emitiendo. Si la huella no coincide con nada del registro de despliegue, el perfil simplemente está desactualizado, y ningún ajuste del lado del cliente lo arreglará.

Repare la confianza sin desactivar la verificación

La solución a corto plazo es desactivar la verificación o añadir cada certificado de la cadena como ancla. Ambas hacen desaparecer el mensaje, y ambas cambian qué servidores aceptará el cliente a partir de entonces. Vuelva a activar la verificación, instale el ancla prevista y vuelva a probar.

Si la cadena ahora se construye pero aparece otro error, eso es progreso: la verificación del nombre, las fechas de validez y la revocación son comprobaciones separadas con mensajes separados. Mantenga el par de huellas y el texto original del error juntos en el ticket, para que la siguiente persona vea qué ancla se cargó y cuál se esperaba. Un par de huellas es lo bastante pequeño para pegarlo en una nota de traspaso, y la siguiente ocurrencia entonces lleva cinco minutos en lugar de una tarde.

Obtenga la autoridad correcta por el mismo canal autenticado que entregó el perfil. Sacar un certificado del servidor porque su sujeto parece familiar es un acto distinto, y amplía en silencio aquello en lo que el cliente confiará.