Extensions X.509 v3 Key Usage EKU et Basic Constraints

Les extensions X.509 v3 transforment un certificat d’une preuve de possession de clé en autorisation cryptographique bornée. Key Usage, Extended Key Usage et Basic Constraints doivent être traitées comme des contrôles de sécurité, pas comme des champs décoratifs ajoutés par un profil de certificat trouvé dans une slide de vendeur.

→ Lire l’explication complète de la marmotte

Key Usage : borner les opérations de clé

Key Usage, souvent abrégé KU, indique quelles opérations cryptographiques sont autorisées avec la clé publique portée par le certificat. L’extension est définie sous forme de bits : digitalSignature, keyEncipherment, keyAgreement, keyCertSign, cRLSign, entre autres.

Le compromis central est net : restreindre les usages réduit le rayon d’explosion d’une clé compromise, mais augmente la discipline nécessaire dans les profils de certificats et les chaînes de validation. La recommandation est de limiter chaque certificat à son rôle effectif. Une clé de signature d’autorité ne doit jamais servir à authentifier un serveur. Ce n’est pas du perfectionnisme de PKI (Public Key Infrastructure), c’est la différence entre une compromission contenue et une hiérarchie entière à reconstruire.

Pour un certificat serveur Transport Layer Security (TLS), digitalSignature est requis dans les déploiements modernes utilisant des échanges de clés éphémères, notamment ECDHE (Elliptic Curve Diffie-Hellman Ephemeral). keyEncipherment ne reste nécessaire que pour des suites historiques reposant sur RSA (Rivest, Shamir, Adleman) comme mécanisme d’échange de clés. Ces suites doivent être désactivées : maintenir keyEncipherment pour elles revient à conserver une sortie de secours vers un musée, avec le chauffage allumé.

Pour une autorité de certification, keyCertSign autorise la signature de certificats fils. cRLSign autorise la signature d’une liste de révocation de certificats. Une autorité qui signe des certificats sans keyCertSign est incohérente. Un client rigoureux doit rejeter cette chaîne, même si la signature mathématique est valide.

Le bit keyAgreement concerne les clés utilisées pour convenir d’un secret partagé, typiquement avec Diffie-Hellman elliptique statique. Il ne doit pas être ajouté par réflexe à un certificat TLS. Les piles actuelles utilisent généralement une clé d’authentification pour signer un échange éphémère, pas une clé serveur statique pour fabriquer le secret de session.

Une extension KU absente n’est pas une autorisation implicite universelle. La norme laisse davantage de latitude aux applications, ce qui produit des écarts entre bibliothèques. Dans une PKI interne, l’absence de KU doit être considérée comme une erreur de profil. Dans une chaîne publique ancienne, elle peut exister pour compatibilité, pas comme modèle à recopier.

Extended Key Usage : limiter le rôle applicatif

Extended Key Usage, abrégé EKU, complète KU avec un rôle applicatif identifié par un OID (Object Identifier). Les valeurs les plus courantes sont serverAuth pour l’authentification d’un serveur TLS, clientAuth pour l’authentification client TLS, codeSigning pour la signature de code et emailProtection pour la messagerie sécurisée.

KU répond à la question « quelle opération cryptographique cette clé peut-elle effectuer ? ». EKU répond à « dans quel protocole ou métier cette identité peut-elle être acceptée ? ». Les deux contraintes sont cumulatives lorsqu’elles sont présentes.

Un certificat d’agent mTLS (mutual TLS) doit porter clientAuth, avec digitalSignature, et ne doit pas recevoir serverAuth sans besoin justifié. Ajouter les deux valeurs « au cas où » rend la même clé acceptable comme client et serveur dans les composants tolérants. Cette polyvalence semble confortable jusqu’au jour où une clé extraite d’un pod devient un certificat serveur acceptable derrière un proxy mal configuré. Le raccourci coûte alors une analyse d’incident, quelques nuits, et probablement un tableau de suivi aux couleurs agressives.

Le choix dépend du modèle d’identité :

pour un serveur exposé, émettre serverAuth seulement ;
pour un client applicatif ou une charge de travail mTLS, émettre clientAuth seulement ;
pour un proxy qui termine TLS en frontal et s’authentifie comme client vers l’amont, préférer deux certificats et deux clés ;
pour un équipement qui doit réellement jouer les deux rôles sur le même endpoint, documenter ce besoin et accepter explicitement serverAuth,clientAuth.

Séparer les certificats serveur et client permet une révocation ciblée, une rotation indépendante et des règles d’accès distinctes pour les clés privées. Un module matériel HSM (Hardware Security Module) peut protéger ces clés, mais ne remplace pas cette séparation : il interdit l’export de clé, il ne devine pas quel certificat aurait dû être utilisé.

Certains validateurs acceptent une EKU absente pour des usages variés, d’autres la traitent différemment selon le contexte. Une application critique ne doit pas déléguer sa politique à ces divergences. La vérification applicative doit exiger l’EKU attendue, surtout pour le mTLS inter-services.

Basic Constraints : empêcher une feuille de devenir autorité

Basic Constraints déclare si un certificat est une autorité de certification, via le booléen CA, et peut fixer une longueur maximale de chemin de certification avec pathLenConstraint.

Un certificat d’autorité porte CA:TRUE. Un certificat terminal, aussi appelé certificat feuille, porte CA:FALSE ou omet l’extension selon certains profils de compatibilité. Dans une PKI maîtrisée, CA:FALSE doit être explicite sur chaque feuille. L’ambiguïté n’est pas une fonctionnalité de sécurité.

La contre-mesure essentielle est double : exiger Basic Constraints critique sur toutes les autorités, puis vérifier que chaque autorité possède aussi KU keyCertSign. Marquer CA:TRUE sans keyCertSign crée une identité d’autorité bancale. Marquer keyCertSign sans CA:TRUE doit conduire au rejet. Les deux extensions décrivent le même privilège sous deux angles et doivent converger.

pathLenConstraint:0 sur une autorité intermédiaire interdit la création d’une autre autorité intermédiaire sous celle-ci, tout en lui permettant de signer des certificats feuilles. Cette contrainte est fortement recommandée pour les intermédiaires d’émission : elle empêche qu’une délégation prévue pour émettre des identités machines serve à créer une sous-hiérarchie durable.

Attention au piège habituel : pathLenConstraint ne compte pas les certificats feuilles. Il limite le nombre d’autorités subordonnées. Une valeur 0 ne bloque donc pas l’émission de certificats serveur ou client, elle bloque seulement les intermédiaires supplémentaires.

La racine hors ligne peut conserver une contrainte plus large si plusieurs niveaux sont prévus et gouvernés. Toute latitude non nécessaire doit disparaître. Une PKI n’a pas besoin d’options d’extension créatives, elle a besoin de certificats qui refusent de faire autre chose que leur métier.

Pour le cycle de vie global des autorités, des intermédiaires et de la confiance distribuée, consulter l’explication de la PKI. Les extensions ne compensent ni une racine compromise, ni une procédure d’émission sans contrôle d’identité.

Exemple OpenSSL : profil serveur et profil intermédiaire

OpenSSL permet de vérifier le contenu d’un certificat existant et de générer une demande de signature avec des extensions demandées. La demande ne crée aucune autorisation : l’autorité de certification doit imposer son propre profil à la signature. Faire confiance aux extensions fournies par le demandeur revient à demander au détenu quel régime de sortie lui paraît raisonnable.

# Afficher les extensions effectivement présentes dans un certificat serveur.
openssl x509 -in serveur.pem -noout -text \
  | sed -n '/X509v3 extensions:/,/Signature Algorithm:/p'

# Créer une demande pour un serveur TLS.
# L'autorité doit ensuite contrôler et imposer ces extensions à l'émission.
openssl req -new -newkey rsa:3072 -nodes \
  -keyout serveur.key \
  -out serveur.csr \
  -subj "/CN=api.interne.example" \
  -addext "subjectAltName=DNS:api.interne.example" \
  -addext "basicConstraints=critical,CA:FALSE" \
  -addext "keyUsage=critical,digitalSignature" \
  -addext "extendedKeyUsage=serverAuth"

Le Subject Alternative Name, souvent abrégé SAN, porte les noms DNS (Domain Name System) ou adresses IP (Internet Protocol) réellement validés par TLS. Le champ CN (Common Name) n’est plus une base suffisante pour la vérification de nom. Une pile récente doit vérifier le SAN, sinon le certificat devient un permis de circulation pour des noms qui ne lui appartiennent pas.

Pour une autorité intermédiaire, le profil minimal comprend basicConstraints=critical,CA:TRUE,pathlen:0 et keyUsage=critical,keyCertSign,cRLSign. La clé d’une autorité ne doit pas être générée sur un hôte d’émission généraliste si un HSM est disponible. La sauvegarde chiffrée de la clé racine, les procédures de cérémonie et la restauration testée restent nécessaires : un HSM en panne sans plan de reprise est juste une boîte très chère qui dit non.

Attaques, limites et exploitation des extensions

Les extensions réduisent les abus par confusion de rôle, mais elles ne prouvent pas que le sujet du certificat est légitime. Cette preuve vient du processus d’enrôlement, de l’autorisation d’émission et de la validation de nom. Elles ne révoquent pas non plus un certificat compromis. La révocation doit être distribuée et vérifiée, avec ses limites de disponibilité et de fraîcheur.

Une attaque classique consiste à obtenir un certificat de client possédant une EKU trop large, puis à l’employer sur un endpoint qui n’impose pas le rôle attendu. La défense exige une validation côté serveur de la chaîne, de l’EKU clientAuth, du SAN ou d’un identifiant de sujet autorisé, et d’une politique d’accès applicative. Le certificat authentifie une clé liée à une identité, pas le droit métier complet de cette identité.

La substitution d’intermédiaire devient possible si les clients n’exigent pas Basic Constraints et KU lors de la construction de chaîne. Les bibliothèques modernes le font généralement, mais un validateur maison contourne vite vingt années de correctifs. Ne jamais réimplémenter la validation X.509 avec trois comparaisons de chaînes et une confiance cosmique dans le champ Issuer.

L’exploitation impose aussi :

inventorier chaque profil de certificat et les OID autorisés ;
séparer les clés d’autorité, serveur et client ;
journaliser l’émission, le renouvellement, la révocation et les échecs de validation ;
surveiller les dates d’expiration avec une alerte antérieure à la fenêtre de rotation ;
tester la reconstruction de chaîne depuis un client vierge ;
sauvegarder les clés d’autorité selon une procédure distincte des certificats publics ;
renouveler avant expiration, car une révocation ne se propage pas aux sessions TLS déjà établies.

L’automatisation d’émission via EST réduit les manipulations manuelles, mais ne doit jamais permettre à un demandeur de choisir librement ses EKU ou son statut d’autorité. L’agent demande une identité, le serveur d’enrôlement applique un profil. L’ordre inverse est un générateur de certificats surprises.

🐝 Ce qui arrive si on s’en passe

Sans Key Usage limité à digitalSignature, une clé RSA de serveur reste utilisable en déchiffrement PKCS#1 v1.5. Un oracle de padding exposé par n’importe quel composant partageant cette clé permet alors de produire des signatures valides avec elle, sans jamais l’extraire : la brèche « la question qui rend le module bavard » illustre ce type d’oracle. Sans CA:FALSE vérifié, une feuille compromise peut émettre des certificats qui n’apparaissent dans aucun journal d’émission de l’autorité ni dans ses listes de révocation. L’inventaire et la détection ne les voient donc pas. Seule la révocation de la feuille elle-même invalide cette sous-hiérarchie, à condition que les clients consultent cette révocation. Sans EKU, un certificat TLS peut aussi être présenté à un vérificateur de signature de code tolérant.

🦫 Explication de la marmotte 🍫

Un certificat numérique contient une clé publique et des informations sur son détenteur. Il est signé par une autorité de certification, qui affirme avoir contrôlé certaines conditions avant de l’émettre. Les extensions ajoutent des règles que les logiciels doivent vérifier avant d’accepter ce certificat.

La règle Key Usage indique quelles actions cryptographiques la clé peut réaliser. Une clé peut être autorisée à signer une preuve, à participer à la création d’un secret partagé ou à signer d’autres certificats. Une clé autorisée à signer d’autres certificats possède un pouvoir beaucoup plus dangereux qu’une clé de serveur.

La règle Extended Key Usage précise le rôle attendu. Un certificat peut être accepté pour identifier un serveur, un client, ou signer un programme. Lors d’une connexion, le logiciel doit chercher le rôle correspondant. Si le certificat annonce seulement un rôle de client, il doit être refusé pour identifier un serveur.

Basic Constraints indique si le certificat peut devenir une autorité de certification. Un certificat ordinaire doit être marqué comme non autorisé à signer d’autres certificats. Une autorité peut aussi recevoir une limite sur le nombre de niveaux supplémentaires qu’elle peut créer.

Si ces règles sont absentes, trop larges ou ignorées, une clé volée peut être utilisée dans davantage de situations. Elles ne suffisent toutefois pas à empêcher le vol de clé, à vérifier les droits métier ou à arrêter une session déjà ouverte. Ces protections dépendent de la gestion des clés, de la révocation, de la surveillance et des contrôles de l’application.

Pages voisines

La citent

Extensions X.509 v3 Key Usage EKU et Basic Constraints

Elle cite

Extensions X.509 v3 Key Usage EKU et Basic Constraints

Extensions X.509 v3 Key Usage EKU et Basic Constraints

Key Usage : borner les opérations de clé

Extended Key Usage : limiter le rôle applicatif

Basic Constraints : empêcher une feuille de devenir autorité

Exemple OpenSSL : profil serveur et profil intermédiaire

Attaques, limites et exploitation des extensions

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines