Renovar un certificado VPN sin cambiar su identidad

Una renovación de certificado que cambia la identidad no es una renovación, es una migración con un tique de mantenimiento. El cliente verifica un nombre, una cadena y a veces una clave concreta, y los tres pueden cambiar sin que cambie la fecha de caducidad. Antes de solicitar un reemplazo, anote qué comprueba realmente el cliente: el nombre de host o la identidad del par, el propósito del certificado, la política de claves y la cadena emisora. La renovación es rutinaria o coordinada según cuál de esos elementos altere el reemplazo.

Tres condiciones deciden la forma de la renovación

Las tres condiciones son si algo fija el certificado final, si cambia la cadena y quién más valida el nombre. Respóndalas desde el lado del cliente y no desde la comodidad de la CA, porque el cliente es lo que falla a las tres de la madrugada.

Empiece inspeccionando el certificado que tiene. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName imprime el sujeto, el emisor, la ventana de validez y los nombres para los que el certificado es realmente válido. Ese último campo es el más importante y el que más se da por supuesto: una solicitud de renovación que omite un SAN del que depende el cliente produce un certificado técnicamente válido y funcionalmente incorrecto. Copie la lista de SAN del certificado antiguo en la solicitud en lugar de reescribirla de memoria.

Condición uno: ¿algo fija el certificado final?

Si los clientes confían en una CA mantenida y validan el nombre, una renovación del certificado final con una clave nueva les resulta invisible. Si algún cliente fija el certificado final, su huella o su clave pública, el reemplazo es un cambio coordinado con un corte duro, porque la fijación antigua no puede validar el certificado nuevo.

Averigüe en qué caso está antes de pedir nada. Una fijación que nadie documentó sigue siendo una fijación cuando se rompe.

Condición dos: compare las fijaciones y la cadena

Las huellas hacen comprobable la fijación: openssl x509 -noout -fingerprint -sha256 -in server.crt en el certificado antiguo y en el nuevo, y openssl x509 -noout -pubkey para comparar las claves públicas. Si la configuración del cliente, un perfil móvil o un almacén de confianza de un dispositivo contiene cualquiera de los dos valores, tiene una fijación. Los perfiles VPN móviles son un escondite habitual, porque el perfil se distribuye una vez y nunca se vuelve a inspeccionar.

Si el reemplazo procede del mismo intermedio y el cliente ya lo tiene o puede obtenerlo, nada cambia en el lado de la confianza. Un intermedio nuevo, un emisor distinto o una cadena entregada en el orden incorrecto convierten una renovación en un cambio de confianza, y el fallo parece un emisor desconocido en lugar de un certificado caducado.

Compruebe la cadena que el servidor envía realmente con openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts, y verifíquela localmente con openssl verify -CAfile ca.pem -untrusted chain.pem server.crt. Hacerlo antes del cambio le da una línea base con la que comparar después.

Condición tres: quién más valida el nombre

Un concentrador VPN, un balanceador de carga, una sonda de monitorización, una integración RADIUS o SAML y un perfil móvil pueden tener cada uno su propia copia del nombre esperado o del ancla de confianza. La renovación es el momento en que esas copias divergen, porque el certificado cambia y las copias no.

Enumere cada consumidor antes del cambio y decida, para cada uno, si necesita una actualización. El que olvide es el que le avisará.

También hay una trampa temporal. Inspeccione el inicio de validez además de la caducidad, porque un certificado preparado para una activación posterior se rechaza si se instala demasiado pronto, y el error parece un problema de reloj en lugar de un problema de preparación. openssl x509 -noout -dates en el archivo nuevo antes de desplegarlo es una comprobación de dos segundos. Mantenga también una ruta de recuperación compatible y la configuración que se sabe buena, para que una renovación que salga mal sea reversible restaurando el certificado y la clave anteriores.

Despliegue, verifique con una autenticación nueva y luego retire

Un túnel establecido refleja la validación que ocurrió cuando se construyó, así que puede parecer sano mientras cada conexión nueva falla. Pruebe con una autenticación nueva usando el nombre de servicio real que utilizan los clientes.

Complete la comprobación a nivel de aplicación que importa al usuario y confirme la entrega de la cadena desde la perspectiva del cliente y no la del servidor. No suprima las comprobaciones de nombre o de certificado para que la transición pase en silencio; eso convierte un problema temporal de compatibilidad en uno permanente.

Retire el material obsoleto solo después de que el despliegue esté verificado, y trate una clave comprometida como un caso completamente distinto: una renovación por sí sola no revoca nada, así que la identidad afectada necesita el proceso de revocación y gestión de sesiones del despliegue. RFC 5280 define las reglas de certificado y de validación de ruta que hay debajo de todo esto. Mantenga una renovación rutinaria del certificado final separada de un reemplazo de CA, para que no se pida a los clientes que confíen en un emisor nuevo sin motivo.