Construction du chemin de certification

Portail > La chaîne de certification

La construction du chemin (path building) est l'étape qui, partant d'un certificat feuille, assemble la suite de certificats menant à une ancre de confiance. Elle précède la validation : on bâtit d'abord un chemin candidat, puis on le valide.

Le problème

Un client reçoit un certificat feuille (et parfois quelques intermédiaires). Il doit retrouver le chaînon manquant jusqu'à une racine qu'il connaît. La difficulté : les intermédiaires ne sont pas toujours fournis, et plusieurs chemins peuvent exister.

Indices de chaînage

Le moteur de construction relie un certificat à son parent en s'appuyant sur :

• issuer ↔ subject : le issuer de l'enfant doit égaler le subject du parent (DN).
• AKI ↔ SKI : l'Authority Key Identifier de l'enfant pointe vers le Subject Key Identifier du parent. Plus fiable que le seul DN, surtout quand plusieurs certificats partagent le même DN (renouvellements, cross-signing).

Où trouver les maillons manquants

1. Fournis par le pair : en TLS, le serveur est censé envoyer la feuille et les intermédiaires (le fullchain), sans la racine. C'est la source normale.
2. Magasin local : intermédiaires déjà présents dans le magasin/cache du client.
3. AIA – CA Issuers : l'extension AIA de la feuille indique une URL où télécharger le certificat de l'autorité émettrice. Certains clients (navigateurs notamment) complètent ainsi une chaîne incomplète ; d'autres (nombre de bibliothèques serveur, clients mTLS) ne le font pas → d'où l'importance d'envoyer le fullchain.

<mermaid> flowchart LR

   F[Feuille] -->|issuer / AKI| Q{Parent connu ?}
   Q -->|dans le flux TLS| P1[Intermédiaire reçu]
   Q -->|dans le magasin local| P2[Intermédiaire local]
   Q -->|via AIA CA Issuers| P3[Téléchargement]
   P1 --> R{Ancre atteinte ?}
   P2 --> R
   P3 --> R
   R -->|non| Q
   R -->|oui| OK[Chemin candidat complet]

</mermaid>

(Schéma en Mermaid.)

Plusieurs chemins possibles

Avec le cross-signing, un même intermédiaire peut être signé par deux racines différentes : il existe alors plusieurs chemins. Un bon moteur de construction explore ces alternatives et retient un chemin qui aboutit à une ancre de confiance et passe la validation. Les moteurs anciens, qui ne testaient qu'un seul chemin, échouaient parfois alors qu'un chemin valide existait — cause classique d'incidents lors de transitions de racines (ex. expiration d'une vieille racine).

Bonnes pratiques côté serveur

• Toujours servir le fullchain (feuille + intermédiaires), jamais la racine.
• Respecter l'ordre : feuille en premier, intermédiaires ensuite (voir Formats et encodage des certificats).
• Vérifier la chaîne servie après chaque renouvellement (cert-manager, ACME, etc.).

# Voir la chaîne réellement présentée par un serveur
openssl s_client -connect clipsy.tech:443 -servername clipsy.tech -showcerts </dev/null

# Vérifier une feuille avec des intermédiaires explicites et une racine
openssl verify -CAfile racine.pem -untrusted intermediaires.pem feuille.pem

Construction ≠ validation

• Construction : « existe-t-il un chemin de la feuille jusqu'à une ancre ? » — assemblage.
• Validation : « ce chemin est-il conforme ? » — vérification de chaque maillon (voir Validation du chemin de certification).

Un chemin peut être constructible mais invalide (maillon expiré, mauvais usage…), et inversement un chemin valide peut exister sans qu'un moteur limité sache le construire.

Points clés à retenir

• On construit un chemin avant de le valider.
• Chaînage par issuer/subject et, plus sûrement, par AKI/SKI.
• Sources des intermédiaires : flux TLS (fullchain), magasin local, AIA (CA Issuers) — mais beaucoup de clients ne suivent pas l'AIA → servir le fullchain.
• Le cross-signing crée plusieurs chemins ; il faut un moteur capable d'en explorer plusieurs.

Voir aussi

• Validation du chemin de certification
• Certification croisée et cross-signing
• Dépannage des chaînes de certificats
• Extensions X.509