Certification croisée et cross-signing

Portail > Sujets avancés et opérationnels

Le cross-signing (signature croisée) consiste à faire signer une même clé/autorité par plusieurs parents. Il permet d'introduire une nouvelle racine, de relier deux PKI ou d'assurer la compatibilité pendant une transition — au prix de chemins multiples.

Principe

Une autorité est définie par sa clé, pas par un unique certificat. On peut donc émettre deux certificats différents pour la même clé d'ICA, signés par deux racines distinctes. Il existe alors deux chemins valides menant à deux ancres différentes :

<mermaid> flowchart TB

   R1["Ancienne racine
(largement déployée)"] --> I["ICA (clé K)"]
   R2["Nouvelle racine"] --> I
   I --> L["Feuille"]

</mermaid>

(Schéma en Mermaid.)

Selon le magasin de confiance du client, l'un ou l'autre chemin aboutira. Un client récent connaît la nouvelle racine ; un ancien ne connaît que l'ancienne — les deux fonctionnent.

Cas d'usage

Adoption d'une nouvelle racine

Une nouvelle racine n'est pas immédiatement présente partout (les programmes racine et les vieux systèmes mettent du temps à l'intégrer). En faisant aussi signer l'intermédiaire par une ancienne racine déjà déployée, on reste compatible pendant la transition. C'est le mécanisme qu'a utilisé Let's Encrypt (intermédiaire signé par sa propre racine ISRG et croisé par une racine plus ancienne) pour fonctionner sur les anciens appareils.

Pontage de deux PKI (bridge / cross-certification)

Deux organisations ayant chacune leur racine peuvent se cross-certifier : la racine A émet un certificat pour la racine B (et/ou l'inverse), de sorte que les entités de A fassent confiance à celles de B sans installer la racine de B. Une bridge CA centralise ces relations entre plusieurs PKI.

Migration / rotation de racine

Pour remplacer une racine en fin de vie sans casser l'existant, on croise temporairement l'ancienne et la nouvelle, le temps que la nouvelle se diffuse dans les magasins.

Conséquence : la construction de chemin doit gérer le choix

Le cross-signing rend plusieurs chemins possibles. Le moteur de construction doit pouvoir explorer ces alternatives et retenir un chemin qui aboutit à une ancre de confiance pour ce client précis. Les implémentations anciennes qui ne testaient qu'un seul chemin ont provoqué des pannes lors d'expirations de racines croisées : un chemin valide existait, mais le client tentait l'autre. Côté serveur, il faut servir l'intermédiaire menant à la racine la plus largement reconnue par la base de clients visée.

Précautions

• Documenter quel intermédiaire est servi et vers quelle racine il mène.
• Tester la chaîne sur les magasins/clients les plus anciens du parc.
• Surveiller les échéances des deux racines impliquées (Cycle de vie d'un certificat).

Points clés à retenir

• Une autorité = une clé ; on peut signer cette clé avec plusieurs parents → plusieurs chemins.
• Sert à : adopter une nouvelle racine, ponter deux PKI, migrer une racine — en préservant la compatibilité.
• Impose un moteur de construction capable d'explorer plusieurs chemins.
• Servir l'intermédiaire qui mène à la racine la plus largement reconnue, et surveiller les deux racines.

Voir aussi

• Construction du chemin de certification
• Ancres de confiance et magasins de confiance
• Autorités de certification
• Dépannage des chaînes de certificats