Qué ocurre cuando sustituye una autoridad de certificación VPN

Sustituir una autoridad de certificación VPN no es cambiar un archivo. En el momento en que la nueva CA firma su primer certificado, cada validador que aún solo confía en la antigua tiene que decidir, y los hosts que nunca reciben la nueva ancla siguen rechazando pares buenos. Lo he visto fallar en ambos sentidos: la puerta de enlace aprendió la nueva CA y los clientes no, así que las conexiones nuevas fallaban, mientras que los túneles ya levantados seguían en pie y hacían que la avería pareciera un problema de enrutamiento. Esto es lo que cambia, en el orden en que aparecen los fallos.

Una sustitución, dos cambios separados

Una autoridad de certificación es un nombre, una clave pública y la clave privada que firma. Los validadores nunca confían en «la CA» en abstracto. Confían en un certificado concreto que ya está en un almacén de confianza, y aceptan un emisor solo si una cadena de firmas llega hasta esa copia guardada. Por eso sustituir la CA cambia dos cosas que fallan de forma independiente: qué anclas se aceptan y qué identidades de par se emitieron bajo ellas.

La mayoría de despliegues VPN validan en ambos sentidos. El cliente autentica el certificado de la puerta de enlace, y la puerta autentica el del cliente. Una renovación que solo refresca el paquete del cliente deja al servidor rechazando a todo cliente que aún presente una identidad de la CA antigua, y lo contrario es igual de habitual. Inventaríe primero los puntos de aplicación: almacenes de confianza de los clientes, el archivo ca de la puerta, cualquier proxy que termine TLS delante y la sonda que comprueba el extremo desde fuera.

Qué comprueba un validador, por orden

La validación de ruta sube desde el certificado del par por los intermedios hasta alcanzar un ancla de confianza. En cada paso verifica la firma, comprueba que cada certificado está dentro de su ventana de validez y confirma que las restricciones básicas y el uso de clave permiten al emisor firmar. Solo entonces la aplicación mira el certificado hoja: los nombres alternativos del sujeto deben cubrir el nombre marcado, y el uso extendido de clave debe permitir la autenticación de servidor o de cliente.

Para repetir ese recorrido sin red, apunte -CAfile al paquete exacto que desplegará y no al almacén del sistema. Si no, está probando el host, no el cambio:

openssl verify -CAfile new-ca.crt gateway.crt
openssl verify -CAfile new-ca.crt -untrusted intermediate.crt client.crt
openssl x509 -in gateway.crt -noout -subject -issuer -dates
openssl s_client -connect gw.example.net:443 -CAfile new-ca.crt

Ese comando solo funciona contra un escucha TLS simple como la página de administración HTTPS de la puerta; el canal de control de OpenVPN precede a TLS, así que s_client no puede inspeccionar el saludo del túnel.

Las reglas de construcción de ruta que hay detrás de esos errores están en RFC 5280 sección 6. Explican los fallos que de otro modo parecen arbitrarios: un intermedio caducado que nadie recordaba, un certificado cuyo uso de clave prohíbe firmar o una restricción de nombre que excluye el host que prueba.

Por qué el túnel antiguo sigue funcionando

TLS y OpenVPN mantienen viva una sesión establecida después de que termine el saludo. Nada revalida el certificado del par por paquete, así que un cliente que se conectó antes del cambio sigue pasando tráfico hasta que renegocia, se reconecta o el túnel cae. Ese hueco es la razón de que una sustitución de CA parezca correcta durante una hora y luego falle en el peor momento: un portátil despierta, una asignación NAT caduca, una puerta se reinicia.

La reanudación de sesión estira la ilusión todavía más. Un ticket de sesión TLS permite al cliente volver sin reenviar certificados, y la reanudación se salta la validación de ruta porque el primer saludo ya la hizo. Así que la prueba honesta es un saludo completo en un proceso nuevo. Reinicie el cliente en lugar de reconectar el túnel, y en un perfil de prueba considere desactivar los tickets para que la ruta de reanudación no pueda ocultar una cadena rota.

Mantenga la capa de clave estática separada de esto. tls-auth añade un HMAC al canal de control, tls-crypt lo cifra y lo autentica, y ninguno de los dos transporta material de certificado, así que rotar cualquiera de ellos es un cambio aparte con su propio modo de fallo. Los despliegues que confunden ambos acaban con un cliente cuya clave estática está bien, cuyo certificado está obsoleto y cuyo mensaje de error no menciona ninguno de los dos.

La trampa de reutilizar el nombre del sujeto

Es tentador reutilizar el nombre distinguido del predecesor para que nada aguas abajo tenga que cambiar. Eso mantiene estable la línea del emisor en la interfaz y destruye la única señal que necesita. Dos certificados con sujetos idénticos y claves distintas no se pueden distinguir por nombre, así que un paquete con ambas anclas da al validador dos candidatos y ninguna regla para elegir.

La construcción de ruta puede entonces elegir el equivocado, informar «no se puede obtener el certificado del emisor local» mientras el ancla correcta está presente, o tener éxito en un host y fallar en otro con el mismo paquete, porque el orden de candidatos era distinto. Si el nombre debe reutilizarse, mantenga ambas anclas en archivos separados durante la transición y cárguelas explícitamente, y físelas solo cuando cada par presente el nuevo emisor. De lo contrario, dé a la sustitución un nombre común distinto — un sufijo de generación o de fecha basta — para que los registros y los textos de error digan bajo qué autoridad se emitió el par que falla.

Una renovación que no tumba la red

Para una sustitución planificada, acepte ambas anclas durante una ventana limitada en lugar de cambiar en un solo paso. Emita la nueva CA y sus intermedios, ponga el nuevo ancla en el paquete de cada validador junto a la antigua y solo entonces empiece a emitir certificados de par desde ella. Los pares con identidades antiguas validan contra el ancla antigua; los nuevos funcionan contra la nueva.

Hecho en ese orden, cada paso es reversible. El fallo que evita es el cambio simultáneo, donde un cliente que se perdió la actualización del paquete se encuentra con una puerta que ya retiró el ancla antigua, el saludo muere y ningún registro dice qué lado está desfasado.

Retire en la dirección opuesta. Vuelva a emitir cada identidad que deba sobrevivir, confirme que cada una presenta la cadena nueva y luego quite el ancla antigua de los paquetes. Retire la clave privada de la CA antigua de servicio, porque un emisor que aún puede firmar significa que la renovación no ha terminado. Guarde los certificados y los registros de emisión para auditoría. Un emisor perdido se restaura a la misma confianza; una exposición exige identidades nuevas y ningún retorno al ancla antigua.

Verifique el resultado, no la lista de archivos

Un archivo de confianza en el directorio esperado demuestra poco. La aplicación puede leer otra ruta, otro formato o una copia dentro de un paquete que una actualización sustituye. Compruebe el comportamiento en ambos extremos, no que exista un archivo.

Confirme que una conexión nueva con una identidad nueva tiene éxito y luego confirme que se rechaza una identidad emitida por la CA retirada. Esa segunda prueba es la que la gente se salta, y la única que demuestra que la autoridad antigua ya no concede acceso. Donde el despliegue dependa de CRL u OCSP, compruebe que los puntos de distribución de los certificados nuevos se resuelven y que los pares que consultan alcanzan al respondedor.

Termine con un cliente que nunca se haya conectado: borre el estado de su perfil, conéctelo y lea la cadena negociada. Un par que reanuda una sesión en caché informará alegremente de que la migración funcionó cuando no ha validado nada.