Root CA / Intermediate CA
generalDéfinition
La Root CA (Autorité de Certification Racine) et l'Intermediate CA (Autorité de Certification Intermédiaire) sont les deux niveaux d'une infrastructure PKI (Public Key Infrastructure) hiérarchique qui permettent d'émettre, gérer, et révoquer des certificats numériques X.509 de manière sécurisée et scalable. La Root CA est le sommet de la hiérarchie PKI — c'est l'ancre de confiance ultime. La clé privée de la Root CA est ce qu'il y a de plus précieux dans une PKI : si elle est compromise, tous les certificats émis par la Root (directement ou via des Intermediate CAs) sont compromis. Pour cette raison, la Root CA est typiquement maintenue hors ligne (air-gapped) dans un HSM (Hardware Security Module) physiquement sécurisé, et n'est utilisée que pour signer les certificats des Intermediate CAs — opération réalisée rarement (tous les 5-10 ans). La Root CA s'auto-signe son propre certificat (self-signed). L'Intermediate CA (ou Subordinate CA) reçoit son certificat signé par la Root CA, et est utilisée au quotidien pour émettre les certificats finaux (certificats serveur TLS, certificats utilisateurs, certificats de signature de code). Même si la clé privée d'une Intermediate CA est compromise, le dommage est limité : on peut révoquer le certificat de l'Intermediate CA dans la Root CA et créer une nouvelle Intermediate CA — sans compromettre la Root. Les grandes PKI commerciales (DigiCert, Sectigo) ont plusieurs Intermediate CAs pour différents usages (TLS, code signing, client certs) et différentes régions géographiques. La chaîne de certification (Certificate Chain) que présentera un serveur TLS inclura : le certificat du serveur (signé par l'Intermediate CA) + le certificat de l'Intermediate CA (signé par la Root CA). Le navigateur vérifie la chaîne en remontant jusqu'à la Root CA — si la Root CA est dans son magasin de confiance (store système ou navigateur), la chaîne est validée. Pour les PKI d'entreprise, des outils comme Microsoft ADCS (Active Directory Certificate Services), HashiCorp Vault PKI Secrets Engine, et Smallstep CA permettent de déployer une PKI interne avec Root et Intermediate CAs.
Cérémonie de la Root CA — processus de sécurité
La génération de la clé privée d'une Root CA est un événement formel appelé "Root CA Key Ceremony". Pour les CAs publiques de confiance (DigiCert, Let's Encrypt), cette cérémonie est auditée par des tiers, filmée, et documentée dans un rapport public. Les étapes incluent : activation de la salle sécurisée (sans accès réseau, caméras de surveillance, accès multiples requis), activation du HSM (module de sécurité matériel qui génère et protège la clé privée — la clé ne quitte jamais le HSM en clair), génération de la paire de clés RSA-4096 ou ECDSA P-384 dans le HSM, création du certificat Root auto-signé, et stockage du HSM dans un coffre-fort à double commande (nécessite deux personnes pour l'ouvrir). Pour les PKI d'entreprise, une procédure simplifiée mais documentée est recommandée, avec la clé Root stockée dans un HSM USB (Nitrokey HSM, YubiHSM) conservé hors ligne.
ADCS — PKI Microsoft Active Directory
Microsoft Active Directory Certificate Services (ADCS) est la solution PKI intégrée dans Windows Server. Une PKI ADCS typique comprend : une Root CA hors ligne (Windows Server avec ADCS installé, pas joint au domaine, conservé hors ligne après installation), une ou plusieurs Subordinate/Intermediate CAs (jointes au domaine, accessibles en ligne, émettent les certificats finaux). Les certificats sont distribués automatiquement via les GPOs (Computer Configuration > Windows Settings > Security Settings > Public Key Policies). ADCS supporte l'auto-enrollment : les postes et serveurs du domaine reçoivent automatiquement les certificats appropriés selon les templates. L'intégration avec Azure AD permet d'étendre la PKI ADCS aux scénarios hybrid cloud (certificats pour les appareils Intune-managed via SCEP/PKCS intégration).
Certificate Transparency et monitoring Root CA
Certificate Transparency (CT) impose que toute CA publique de confiance enregistre chaque certificat émis dans des logs CT publics (maintenant obligatoire pour Chrome depuis 2018). Ces logs permettent de monitorer les certificats émis pour vos domaines : si une CA émet un certificat pour votre domaine sans votre autorisation, vous êtes alerté via des outils de monitoring CT (crt.sh, Facebook CT Monitor, Certspotter). La fonctionnalité CAA (Certification Authority Authorization) des enregistrements DNS limite quelles CAs sont autorisées à émettre des certificats pour votre domaine : `example.com CAA 0 issue "letsencrypt.org"` indique que seul Let's Encrypt peut émettre pour ce domaine — toute émission par une autre CA violant le CAA sera rejetée par les navigateurs conformes.
Ce terme vous interpelle ?
Nos experts interviennent sur toutes les thématiques de ce glossaire — pentest, conformité NIS 2 / ISO 27001, forensics, sécurité IA. Réponse sous 24h, devis gratuit et sans engagement.