Construire une autorité de certification privée interne

Une autorité de certification privée permet d’émettre des certificats pour des noms, services et identités qui ne doivent jamais être reconnus par un navigateur public. Le compromis central est net : on gagne le contrôle complet des politiques et des coûts d’émission, mais on devient responsable de toute la confiance, y compris quand elle casse à 3 heures du matin.

→ Lire l’explication complète de la marmotte

Pourquoi une autorité privée pour les flux internes

Une autorité de certification (AC) publique est conçue pour rendre un certificat acceptable par les navigateurs, systèmes et appareils du grand public. Pour api.prod.interne.example, grafana.infra.local ou une identité de charge de travail, cette confiance mondiale ne sert à rien. Elle ajoute une dépendance externe, des contraintes de validation de domaine et, selon le fournisseur, un coût par certificat ou par produit annexe.

Une AC privée émet sans coût marginal par certificat, impose les durées de validité voulues et applique des politiques précises : noms autorisés, usages de clé, algorithmes, profils par environnement, authentification du demandeur. Cette liberté est la raison de l’adopter. C’est aussi la facture : distribuer le certificat racine, contrôler l’émission et organiser la reprise ne sont plus le problème de quelqu’un d’autre.

Le bon périmètre est strictement interne : réseau d’administration, services inter-applicatifs, passerelles, réseaux privés virtuels, identité machine et authentification mutuelle. Pour une interface exposée au public, une AC publique reste le choix normal. Installer une racine privée chez des clients externes pour éviter un certificat public est une dette opérationnelle déguisée en économie. Elle finit généralement dans un tableur, puis dans un incident.

Une chaîne privée ne remplace pas les mécanismes décrits dans l’architecture PKI. Elle fournit une preuve cryptographique qu’une clé appartient à une identité selon une politique locale. Elle ne décide ni si cette identité devait recevoir ce droit, ni si le service derrière le certificat est digne de confiance.

Chaîne de confiance à deux niveaux

L’architecture recommandée comporte une racine hors ligne et une ou plusieurs autorités intermédiaires en ligne. La racine signe uniquement les certificats des intermédiaires. Elle ne signe jamais un certificat serveur, client ou de charge de travail. Une racine connectée au réseau pour émettre au quotidien n’est pas une racine, c’est une intermédiaire coûteuse à remplacer.

La clé privée de la racine doit résider dans un HSM (Hardware Security Module) hors ligne ou, à défaut, dans un support chiffré conservé sous contrôle physique avec une procédure de cérémonie documentée. Le HSM protège contre l’extraction de clé, pas contre une émission autorisée par un opérateur disposant des droits requis. Les slides vendeurs aiment parfois oublier cette partie, probablement faute de place entre deux nuages bleus.

La racine porte une extension basicConstraints avec CA:TRUE et une longueur de chemin limitée à un niveau. L’intermédiaire porte aussi CA:TRUE, avec pathlen:0, ce qui interdit de créer une sous-autorité supplémentaire. Cette contrainte bloque une erreur fréquente : transformer une clé d’émission compromise en usine à chaînes parallèles.

Séparer les intermédiaires par finalité réduit le rayon d’explosion :

une intermédiaire pour les certificats serveur TLS (Transport Layer Security) ;
une intermédiaire pour les certificats clients d’authentification mutuelle, décrite dans mTLS ;
éventuellement une intermédiaire dédiée aux environnements de développement, sans aucune confiance croisée avec la production.

Chaque intermédiaire doit imposer des extensions keyUsage et extendedKeyUsage cohérentes. Un certificat serveur ne doit pas devenir certificat client par accident. Un certificat de signature de code ne doit pas émerger d’une AC TLS parce qu’un profil fourre-tout semblait pratique. Les profils universels sont très efficaces pour universaliser les dégâts.

La durée de vie de la racine peut atteindre 10 à 15 ans si la clé est correctement protégée et si la migration est préparée dès sa création. Celle d’une intermédiaire doit être plus courte, typiquement 3 à 5 ans. Les certificats finaux devraient vivre de quelques jours à 90 jours pour les services automatisés, jusqu’à un an lorsque le renouvellement reste partiellement manuel. Une longue validité ne stabilise pas une plateforme, elle reporte l’échec au prochain départ de responsable.

Distribution de la racine et validation côté client

Le certificat public de la racine doit être distribué dans chaque magasin de confiance qui validera la chaîne : postes de travail, serveurs Linux, systèmes Windows, conteneurs, passerelles, appareils mobiles, équipements réseau et runtimes applicatifs. Déposer le fichier dans un partage n’installe rien. Un certificat racine oublié produit souvent une erreur TLS générique, donc un diagnostic inutilement long.

Les applications Java utilisent fréquemment leur propre magasin de confiance. Les images de conteneurs minimales peuvent n’embarquer aucun paquet de certificats. Les appliances réseau ont parfois un magasin distinct de celui du système d’exploitation. Un inventaire des consommateurs de confiance est donc un prérequis, pas une tâche de finition.

La distribution doit être gérée comme une configuration de sécurité : paquet signé, stratégie de poste, gestion de configuration ou image de base contrôlée. Vérifier l’empreinte SHA-256 du certificat racine pendant le déploiement évite qu’un fichier homonyme devienne une racine de confiance. La confiance implicite est le chemin le plus court vers une belle enquête de compromission.

Le nom présenté par le serveur doit correspondre à une entrée SAN (Subject Alternative Name), pas seulement au champ historique Common Name. Les clients récents ignorent ou dépriorisent ce dernier. Pour les noms internes, définir une zone DNS (Domain Name System) réellement contrôlée et stable. Émettre des certificats pour des adresses IP est possible, mais complique la mobilité, les répartiteurs et les migrations. Une identité de service vaut mieux qu’une topologie gravée dans du silicium.

Émission contrôlée et exemple OpenSSL

L’émission quotidienne doit passer par une interface authentifiée, journalisée et limitée par profils. EST (Enrollment over Secure Transport), présenté dans le guide EST, convient aux équipements et agents capables de s’authentifier. Une API interne peut convenir si elle vérifie l’identité du demandeur, applique un modèle d’autorisation et ne prend jamais les champs d’une demande comme parole d’évangile.

Une CSR (Certificate Signing Request) contient une clé publique et les attributs demandés. Elle ne prouve pas que le demandeur a le droit d’utiliser les noms indiqués. L’autorité doit reconstruire les SAN autorisés depuis l’inventaire ou l’identité authentifiée. Accepter les SAN fournis par le demandeur sans contrôle permet à n’importe quel service authentifié de demander vault.prod.interne.example. C’est rarement l’objectif, même dans les organisations qui apprécient le chaos créatif.

L’exemple suivant signe une CSR serveur avec une intermédiaire déjà créée. Il montre les extensions minimales, mais ne remplace ni la politique d’autorisation ni le registre d’émission.

# extensions-server.cnf : le nom est imposé par la politique, pas lu depuis la CSR.
cat > extensions-server.cnf <<'EOF'
basicConstraints = critical,CA:FALSE
keyUsage = critical,digitalSignature,keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = DNS:api.prod.interne.example
authorityKeyIdentifier = keyid,issuer
subjectKeyIdentifier = hash
EOF

# Signature par l'intermédiaire, dont la clé reste idéalement dans un HSM.
openssl x509 -req \
  -in api-prod.csr \
  -CA intermediate-ca.crt \
  -CAkey intermediate-ca.key \
  -CAcreateserial \
  -out api-prod.crt \
  -days 30 \
  -sha256 \
  -extfile extensions-server.cnf

# Vérification de chaîne avec racine et intermédiaire.
openssl verify -CAfile root-ca.crt -untrusted intermediate-ca.crt api-prod.crt

Dans une plateforme réelle, intermediate-ca.key ne doit pas apparaître sur le système qui prépare une commande OpenSSL. L’accès doit passer par PKCS#11 (Public-Key Cryptography Standards #11) ou par le protocole du produit d’autorité. Une clé exportable dans un répertoire d’administration transforme la protection de l’intermédiaire en vœu pieux avec permissions Unix.

Révocation, rotation et reprise après compromission

La révocation répond à un besoin précis : déclarer qu’un certificat encore valide ne doit plus être accepté. Une liste de révocation de certificats, ou CRL (Certificate Revocation List), doit être publiée à une adresse atteignable par les validateurs concernés. OCSP (Online Certificate Status Protocol) peut réduire la latence de statut, mais sa disponibilité devient une dépendance de connexion. Pour des services internes à certificats courts, privilégier une durée brève et un renouvellement automatisé plutôt qu’une dépendance massive à la révocation temps réel.

La révocation ne ferme pas les sessions TLS déjà établies. Elle ne supprime pas une clé privée volée. Elle ne répare pas un client qui ne consulte ni CRL ni OCSP. Ces limites doivent orienter la réponse à incident : couper l’accès réseau, remplacer le certificat, réémettre si nécessaire, puis invalider les identifiants associés.

La rotation de racine doit être conçue avant l’émission du premier certificat. La procédure consiste à distribuer une nouvelle racine tout en conservant l’ancienne dans les magasins de confiance, à créer une nouvelle intermédiaire, à réémettre les certificats finaux, puis à retirer l’ancienne racine après expiration ou migration complète. Une rotation précipitée sans double confiance casse les clients non inventoriés. Et il y en a toujours un, tapi dans une image de conteneur oubliée, comme une marmotte avec accès production.

Sauvegarder les clés d’autorité exige un chiffrement séparé, des contrôles d’accès distincts et des essais de restauration. Une sauvegarde jamais restaurée est un récit de fiction technique. Documenter aussi les numéros de série émis, les journaux d’approbation, les profils, les certificats d’autorité et les points de publication de révocation. Sans ces éléments, une reprise restaure un fichier, pas une autorité de confiance.

La supervision doit alerter sur l’expiration des racines, intermédiaires et certificats finaux, l’échec de publication des CRL, les refus d’émission anormaux et les volumes d’émission inattendus. Une hausse soudaine de CSR pour des noms sensibles mérite une investigation avant d’être appelée automatisation.

Surface d’attaque et garanties absentes

La compromission de l’intermédiaire permet d’émettre des certificats acceptés par tous les clients qui font confiance à sa racine. La contre-mesure est la séparation des rôles, la clé non exportable, l’authentification forte des opérateurs, des profils contraints et un journal d’audit inviolable. La compromission de la racine impose généralement de redistribuer une nouvelle ancre de confiance partout. C’est l’incident que l’architecture à deux niveaux cherche précisément à rendre exceptionnel.

Une AC privée ne garantit pas que le client vérifie le nom du serveur, qu’il vérifie la révocation, qu’il refuse les algorithmes faibles ou qu’il protège sa propre clé privée. Elle ne remplace pas la segmentation réseau, le contrôle d’accès, la surveillance des identités ni le durcissement TLS décrit dans TLS expliqué.

Elle ne fournit pas non plus de transparence publique comparable à Certificate Transparency. Pour une infrastructure interne, un journal d’émission append-only, horodaté et réconcilié avec l’inventaire des actifs apporte une détection suffisante, à condition d’être réellement consulté. Un audit qui dort dans un stockage objet est parfaitement intègre, et parfaitement inutile.

🐝 Ce qui arrive si on s’en passe

Sans autorité privée, les flux internes basculent vers deux impasses. Première impasse : les certificats autosignés, que chaque client doit accepter un par un ; la pratique dérive vers la désactivation de la vérification (options du type verify=false ou InsecureSkipVerify), et tout poste capable d’intercepter le trafic interne (usurpation ARP, DNS interne détourné) présente alors n’importe quel certificat sans déclencher d’erreur. Aucune révocation ni inventaire central n’existe pour ces certificats isolés. Deuxième impasse : les certificats publics pour des noms internes, qui publient chaque nom d’hôte dans les journaux Certificate Transparency et offrent une cartographie gratuite de l’infrastructure à la reconnaissance. Faute d’identité machine émise à grande échelle, l’authentification entre services retombe aussi sur des secrets partagés, rejouables une fois copiés.

🦫 Explication de la marmotte 🍫

Une autorité de certification privée fabrique des certificats numériques pour les machines et applications d’une organisation. Un certificat contient une clé publique, un nom autorisé et une date de fin. Quand une application se connecte à un service, elle vérifie que le certificat a été signé par une autorité qu’elle connaît déjà, que le nom demandé correspond, et que le certificat est encore valable.

La clé la plus sensible appartient à l’autorité racine. Elle reste hors ligne et ne sert qu’à autoriser des autorités intermédiaires. Ces autorités intermédiaires sont connectées et délivrent les certificats utilisés chaque jour. Si une intermédiaire est volée, on peut la remplacer sans devoir remplacer immédiatement toute la racine. Si la racine est volée, tous les appareils doivent recevoir une nouvelle racine : c’est beaucoup plus grave.

Avant de l’utiliser, chaque poste, serveur et application doit recevoir le certificat public de la racine. Si cette installation manque, la connexion échoue car le client ne reconnaît pas le signataire. Les certificats doivent aussi être renouvelés avant leur expiration, et les clés privées ne doivent pas être copiées librement.

Lorsqu’un certificat ou une clé est compromis, le certificat peut être révoqué et remplacé. Mais une connexion déjà ouverte peut continuer : il faut alors aussi couper l’accès concerné. L’autorité prouve une identité technique, elle ne protège pas seule les comptes, le réseau ou les applications.

Pages voisines

La citent

Construire une autorité de certification privée interne

Elle cite

Construire une autorité de certification privée interne

Construire une autorité de certification privée interne

Pourquoi une autorité privée pour les flux internes

Chaîne de confiance à deux niveaux

Distribution de la racine et validation côté client

Émission contrôlée et exemple OpenSSL

Révocation, rotation et reprise après compromission

Surface d’attaque et garanties absentes

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines