CA con firma cruzada: la clave coincide, el enlace AKI no

Dos certificados CA pueden tener la misma clave pública y el mismo sujeto y aun así no ser intercambiables. Uno está autofirmado, el otro está firmado en cruz por la raíz antigua, y sus nombres de emisor, números de serie y firmas difieren. Una hoja puede vincularse específicamente a uno de ellos mediante su Authority Key Identifier. Ese vínculo permanece invisible hasta que un cliente elige la cadena equivocada y el handshake falla sin motivo evidente.

Realiza estas cinco comprobaciones en orden: cada una descarta un fallo distinto.

Comprobación 1: dibuja ambas cadenas antes de tocar la plantilla

Anota las rutas. La población antigua confía en la Raíz antigua A, que emitió la CA B, que emitió la hoja del servidor. La población nueva confía directamente en la CA B autofirmada. Ambos certificados B llevan la misma clave y el mismo sujeto, y por eso mismo quien lee una línea de sujeto ve una CA donde el cliente ve dos.

La copia con firma cruzada también debe ser un certificado CA real, con basic constraints y key usage que permitan firmar.

Comprobación 2: compara los campos AKI, no solo la clave

El nombre del emisor de la hoja debe coincidir con el sujeto de B, y esa parte suele cumplirse. El Authority Key Identifier es donde las dos copias divergen, porque puede llevar un identificador de clave, un emisor de certificado y un número de serie. El identificador de clave coincide con ambas copias, ya que la clave es idéntica. Los campos de emisor y serie coinciden exactamente con una, y por eso una cadena que se construye contra la copia autofirmada puede fallar contra la firmada en cruz.

Inspecciona la hoja en lugar de adivinar: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier.

Luego compara ambos candidatos con openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier", y la misma orden contra la copia autofirmada.

Si la hoja lleva emisor y número de serie, solo el certificado que describen esos valores completa la cadena, sea cual sea la copia que el cliente haya cargado.

Comprobación 3: cambia la política de emisión, nunca los bytes firmados

Las extensiones viven dentro de la firma. Añadir, quitar o editar una en una hoja existente no es una reparación, es un certificado distinto y requiere reemisión. El cambio corresponde a la política de emisión: authorityKeyIdentifier = keyid,issuer:always hace que las hojas nuevas lleven el vínculo específico del certificado, mientras que keyid por sí solo mantiene la forma más laxa que conviene a una transición deliberada de firma cruzada. Decide cuál quiere tu PKI antes de que se firme el siguiente lote.

Editar una plantilla compartida también cambia todos los certificados futuros, no solo el servidor que tienes delante.

Comprobación 4: verifica cada población de confianza por separado

Prueba la ruta antigua y la nueva como ejecuciones separadas. openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem ejercita la ruta con firma cruzada, y la misma orden con la raíz nueva y sin fichero untrusted ejercita la ruta autofirmada. Mezclar ambas raíces en un solo paquete oculta qué cadena se seleccionó. Repítelo después con clientes reales, porque un backend VPN puede preferir una cadena o fijar un certificado de formas que openssl no hace.

Entrega el certificado intermedio mediante la configuración de servicio que el cliente lee realmente, no mediante una página wiki.

Comprobación 5: mantén la ruta antigua en un reloj de retirada

La firma cruzada mantiene viva por diseño una ruta de confianza antigua, que es a la vez el propósito y el riesgo. No remedia una raíz antigua comprometida ni elimina esa raíz de ningún cliente. Anota cuándo la ruta antigua deja de conceder confianza y confirma que ese día llega de verdad.

Si todos los clientes pueden aceptar la raíz nueva antes de que se muevan las hojas, un despliegue sencillo de doble confianza es más simple que la firma cruzada, y deja una cosa menos que retirar.