Contraintes de chemin

Portail > La chaîne de certification

Les contraintes de chemin sont des extensions placées sur les certificats d'autorité pour limiter ce que leurs sous-autorités peuvent émettre. Elles sont vérifiées pendant la validation et permettent de déléguer une autorité de façon restreinte.

Basic Constraints : CA et pathLenConstraint

L'extension Basic Constraints porte deux informations :

• CA:TRUE / CA:FALSE : le certificat peut-il signer d'autres certificats ?
• pathLenConstraint:N : nombre maximal de CA intermédiaires pouvant encore apparaître en dessous de celle-ci dans le chemin (la feuille n'est pas comptée).

Exemple :

• pathlen:0 sur une ICA → elle ne peut signer que des feuilles, aucune sous-ICA.
• pathlen:1 → elle peut signer une ICA de plus, qui devra alors être pathlen:0.

<mermaid> flowchart TB

   R["Root (pathlen:2)"] --> I1["ICA (pathlen:1)"]
   I1 --> I2["ICA (pathlen:0)"]
   I2 --> L["Feuille (CA:FALSE)"]
   I2 -.->|interdit : sous-ICA| X["ICA supplémentaire ❌"]

</mermaid>

(Schéma en Mermaid.)

Une chaîne dont la profondeur de CA dépasse un pathlen rencontré est rejetée, même si toutes les signatures sont valides.

Name Constraints

L'extension Name Constraints (placée sur une CA) restreint les noms que ses sous-autorités ont le droit d'émettre. Elle définit des sous-arbres :

• permittedSubtrees : seuls ces espaces de noms sont autorisés ;
• excludedSubtrees : ces espaces de noms sont interdits.

Les contraintes s'appliquent à différents types de noms : DNS, adresses IP, e-mail, DN d'annuaire, URI.

Exemple : une CA déléguée avec permitted DNS:.clipsy.tech ne pourra émettre des certificats valides que pour des noms sous clipsy.tech ; un certificat qu'elle émettrait pour example.com serait rejeté à la validation, quand bien même sa signature serait correcte.

C'est un outil puissant pour déléguer une CA à un tiers ou à une entité sans lui donner le pouvoir d'émettre pour n'importe quel domaine. Extension idéalement marquée critique.

Pourquoi ces contraintes

• Limiter le rayon de confiance : une CA compromise ne peut nuire qu'à l'intérieur de ses contraintes (sous-domaines autorisés, profondeur permise).
• Déléguer sans tout céder : confier une ICA à une filiale/partenaire en bornant ses noms.
• Appliquer une politique : forcer une organisation à rester dans son périmètre de noms.

Limites pratiques

• Le support de Name Constraints a longtemps été inégal selon les implémentations ; il s'est nettement amélioré mais reste à tester dans chaque magasin/runtime visé.
• Les contraintes ne remplacent pas la révocation : elles bornent a priori, elles ne corrigent pas après coup.

Vérifier en pratique

# Lire Basic Constraints et Name Constraints d'une CA
openssl x509 -in ica.pem -noout -text | grep -A2 -E "Basic Constraints|Name Constraints"

Points clés à retenir

• pathLenConstraint borne la profondeur de CA sous une autorité (feuille non comptée).
• Name Constraints borne les noms qu'une sous-CA peut émettre (permitted/excluded), par type de nom.
• Ces contraintes sont vérifiées à la validation : un dépassement rejette la chaîne malgré des signatures valides.
• Elles servent à déléguer une autorité de façon limitée et à confiner une compromission.

Voir aussi

• Validation du chemin de certification
• Extensions X.509
• Autorités de certification