CA con sinatura cruzada: a clave coincide, o enlace AKI non

Dous certificados CA poden ter a mesma clave pública e o mesmo suxeito e aínda así non ser intercambiables. Un está autosinado, o outro está asinado en cruz pola raíz antiga, e os seus nomes de emisor, números de serie e sinaturas difiren. Unha folla pode vincularse especificamente a un deles mediante o seu Authority Key Identifier. Ese vínculo permanece invisible ata que un cliente escolle a cadea equivocada e o handshake falla sen motivo evidente.

Fai estas cinco comprobacións en orde: cada unha descarta un fallo distinto.

Comprobación 1: debuxa ambas as cadeas antes de tocar o modelo

Anota as rutas. A poboación antiga confía na Raíz antiga A, que emitiu a CA B, que emitiu a folla do servidor. A poboación nova confía directamente na CA B autosinada. Ambos os certificados B levan a mesma clave e o mesmo suxeito, e por iso mesmo quen le unha liña de suxeito ve unha CA onde o cliente ve dúas.

A copia con sinatura cruzada tamén debe ser un certificado CA real, con basic constraints e key usage que permitan asinar.

Comprobación 2: compara os campos AKI, non só a clave

O nome do emisor da folla debe coincidir co suxeito de B, e esa parte adoita cumprirse. O Authority Key Identifier é onde as dúas copias diverxen, porque pode levar un identificador de clave, un emisor de certificado e un número de serie. O identificador de clave coincide con ambas as copias, xa que a clave é idéntica. Os campos de emisor e serie coinciden exactamente cunha, e por iso unha cadea que se constrúe contra a copia autosinada pode fallar contra a asinada en cruz.

Inspecciona a folla en lugar de adiviñar: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier.

Despois compara ambos os candidatos con openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier", e a mesma orde contra a copia autosinada.

Se a folla leva emisor e número de serie, só o certificado que describen eses valores completa a cadea, sexa cal sexa a copia que o cliente cargase.

Comprobación 3: cambia a política de emisión, nunca os bytes asinados

As extensións viven dentro da sinatura. Engadir, quitar ou editar unha nunha folla existente non é unha reparación, é un certificado distinto e require reemisión. O cambio pertence á política de emisión: authorityKeyIdentifier = keyid,issuer:always fai que as follas novas leven o vínculo específico do certificado, mentres que keyid por si só mantén a forma máis laxa que convén a unha transición deliberada de sinatura cruzada. Decide cal quere a túa PKI antes de que se asine o seguinte lote.

Editar un modelo compartido tamén cambia todos os certificados futuros, non só o servidor que tes diante.

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

Proba a ruta antiga e a nova como execucións separadas. openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem exercita a ruta con sinatura cruzada, e a mesma orde coa raíz nova e sen ficheiro untrusted exercita a ruta autosinada. Mesturar ambas as raíces nun só paquete oculta que cadea se seleccionou. Repíteo despois con clientes reais, porque un backend VPN pode preferir unha cadea ou fixar un certificado de formas que openssl non fai.

Entrega o certificado intermedio mediante a configuración de servizo que o cliente le realmente, non mediante unha páxina wiki.

Comprobación 5: mantén a ruta antiga nun reloxo de retirada

A sinatura cruzada mantén viva por deseño unha ruta de confianza antiga, que é á vez o propósito e o risco. Non remedia unha raíz antiga comprometida nin elimina esa raíz de ningún cliente. Anota cando a ruta antiga deixa de conceder confianza e confirma que ese día chega de verdade.

Se todos os clientes poden aceptar a raíz nova antes de que se movan as follas, un despregamento sinxelo de dobre confianza é máis simple que a sinatura cruzada, e deixa unha cousa menos que retirar.