CA contre-signée : la clé correspond, la liaison AKI non

Deux certificats CA peuvent porter la même clé publique et le même sujet sans être interchangeables pour autant. L'un est auto-signé, l'autre est contre-signé par l'ancienne racine, et leurs noms d'émetteur, numéros de série et signatures diffèrent. Une feuille peut se lier spécifiquement à l'un des deux via son Authority Key Identifier. Cette liaison reste invisible jusqu'à ce qu'un client choisisse la mauvaise chaîne et que la poignée de main échoue sans raison évidente.

Effectuez ces cinq vérifications dans l'ordre : chacune écarte une défaillance différente.

Vérification 1 : dessinez les deux chaînes avant de toucher au modèle

Notez les chemins. L'ancienne population fait confiance à l'Ancienne racine A, qui a émis la CA B, qui a émis la feuille du serveur. La nouvelle population fait directement confiance à la CA B auto-signée. Les deux certificats B portent la même clé et le même sujet, et c'est précisément pourquoi une personne qui lit une ligne de sujet voit une CA là où le client en voit deux.

La copie contre-signée doit aussi être un véritable certificat CA, avec basic constraints et key usage qui autorisent la signature.

Vérification 2 : comparez les champs AKI, pas seulement la clé

Le nom d'émetteur de la feuille doit correspondre au sujet de B, et cette partie tient généralement. L'Authority Key Identifier est l'endroit où les deux copies divergent, car il peut porter un identifiant de clé, un émetteur de certificat et un numéro de série. L'identifiant de clé correspond aux deux copies, puisque la clé est identique. Les champs émetteur et série ne correspondent qu'à une seule, et c'est pourquoi une chaîne construite contre la copie auto-signée peut échouer contre la contre-signée.

Inspectez la feuille au lieu de deviner : openssl x509 -in server.pem -noout -ext authorityKeyIdentifier.

Comparez ensuite les deux candidats avec openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier", et la même commande contre la copie auto-signée.

Si la feuille porte émetteur et numéro de série, seul le certificat que décrivent ces valeurs complète la chaîne, quelle que soit la copie que le client a chargée.

Vérification 3 : changez la politique d'émission, jamais les octets signés

Les extensions vivent à l'intérieur de la signature. En ajouter, en retirer ou en modifier une sur une feuille existante n'est pas une réparation, c'est un autre certificat, et cela exige une réémission. Le changement relève de la politique d'émission : authorityKeyIdentifier = keyid,issuer:always fait porter aux nouvelles feuilles la liaison propre au certificat, tandis que keyid seul conserve la forme plus souple qui convient à une transition délibérée de contre-signature. Décidez ce que votre PKI veut avant que le lot suivant soit signé.

Modifier un modèle partagé change aussi chaque futur certificat, pas seulement le serveur devant vous.

Vérification 4 : vérifiez chaque population de confiance séparément

Testez l'ancien chemin et le nouveau comme des exécutions distinctes. openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem exerce la route contre-signée, et la même commande avec la nouvelle racine et sans fichier untrusted exerce la route auto-signée. Mélanger les deux racines dans un seul paquet cache quelle chaîne a été sélectionnée. Répétez ensuite avec de vrais clients, car un backend VPN peut préférer une chaîne ou épingler un certificat de façons qu'openssl ne fait pas.

Livrez le certificat intermédiaire via la configuration de service que le client lit réellement, pas via une page wiki.

Vérification 5 : gardez l'ancien chemin sur une horloge de retrait

La contre-signature maintient un ancien chemin de confiance en vie par conception, ce qui est à la fois le but et le risque. Elle ne corrige pas une ancienne racine compromise et ne retire pas cette racine d'un seul client. Notez quand l'ancien chemin cesse d'accorder sa confiance, et confirmez que ce jour arrive vraiment.

Si chaque client peut accepter la nouvelle racine avant que les feuilles bougent, un déploiement simple à double confiance est plus simple que la contre-signature, et il laisse une chose de moins à retirer.