Certificado VPN renovado: algunos clientes siguen rechazándolo

La mitad del parque se reconecta tras la renovación y tres dispositivos rechazan, cada uno con un aviso sobre la identidad de la puerta de enlace. La renovación en sí es rutina. Lo que esos tres dispositivos guardan es un pin al objeto antiguo, y un pin no es una lista de CA, una comprobación de nombre ni una entrada en un almacén de confianza. Compare los tres mecanismos antes de tocar cualquier cliente.

Una renovación, dos comportamientos

Los clientes que se reconectan tienen una decisión de confianza que todavía pasa, y los que rechazan tienen un requisito que el nuevo certificado no satisface. Esa diferencia es información, no ruido. Lea el mensaje del cliente que falla con precisión. Una discrepancia de nombre, un emisor desconocido y una huella cambiada son tres veredictos distintos, y solo el último apunta a un pin.

Compruebe también qué perfil seleccionó el cliente que falla. Una copia importada que vive en su propio almacén no cambia cuando el administrador edita el archivo original en otro lugar.

La renovación sustituye el objeto, no solo la fecha

Una huella identifica el contenido codificado del certificado. La renovación produce un certificado nuevo, así que la huella cambia incluso cuando el nombre del sujeto y la clave pública siguen idénticos. Eso es esperable e inofensivo para los clientes que confían en una CA y verifican el nombre. Es fatal para un cliente configurado para aceptar exactamente un certificado, y también es fatal para un cliente cuyo almacén de confianza nunca recibió al nuevo emisor.

openssl x509 -in server.pem -noout -subject -issuer -dates -fingerprint -sha256
openssl x509 -in server.pem -noout -pubkey | openssl sha256

La segunda línea responde a otra pregunta: si el par de claves sobrevivió. Una renovación que reutilizó la clave conserva ese valor y solo cambia el certificado, que es justo el caso en el que un administrador se siente tentado a suponer que nada cambió. Inspeccione el certificado que está desplegado, no el del host de compilación. Comparar un archivo en un repositorio demuestra qué se generó, no qué está presentando ahora un oyente.

Lea qué está fijando el cliente

Algunos clientes guardan una huella en su perfil y la comparan en cada conexión. Otros la almacenan en un almacén de confianza de la plataforma, y otros se apoyan solo en una CA. La reparación difiere en cada caso, así que identifique primero el mecanismo.

grep -n 'peer-fingerprint' /etc/openvpn/client/*.conf
openssl s_client -connect gw.lab.example.net:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -fingerprint -sha256

El primer comando muestra un pin en un perfil convencional; el segundo muestra la huella que el punto final sirve realmente ahora mismo. Cuando esos dos difieren, ha localizado el fallo sin adivinar. No pegue el valor nuevo en cada cliente que se queja. Un cliente que rechaza por motivos de emisor seguirá rechazando, y habrá aprendido que la huella era el problema cuando no lo era.

Compare el certificado que sirve cada backend

Los resultados intermitentes suelen significar más de un punto final, y una renovación aplicada a un nodo deja a los demás presentando el objeto antiguo. Compare cada backend por dirección en lugar de por el nombre compartido.

for h in 10.30.0.11 10.30.0.12; do echo "$h"; openssl s_client -connect $h:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -subject -dates -fingerprint -sha256; done

Un grupo donde un nodo va retrasado explica un cliente que se conecta al segundo intento y falla al primero. También explica una comprobación de monitorización que pasa mientras los usuarios se quejan. Corrija primero el retraso. Desplegar la configuración de confianza antes de que cada nodo sirva el certificado nuevo crea una ventana en la que nada funciona, y desplegarla después deja a los clientes fallando de forma impredecible.

Cambie la confianza por la vía gestionada

Confirme la sustitución por un canal administrativo ya fiable antes de aceptarla en cualquier sitio. Una fecha de caducidad plausible no es prueba de propiedad. Actualice la configuración gestionada mediante el proceso que la posee, con cualquier solapamiento planificado de identidades aceptables, y mantenga la verificación de nombre que exige el despliegue. Un pin sin comprobación de nombre es un diseño más débil que la confianza de CA que sustituyó.

Luego verifique por cliente: conéctese, confirme la identidad que aceptó y anote la versión de certificado en la que ahora confía. Un aviso descartado una vez tiene la costumbre de volver en la próxima renovación.