Active Directory Certificate Services n'est généralement pas un choix architectural réfléchi. C'est un héritage.
Dans la plupart des organisations, personne ne décide d'adopter ADCS après une évaluation rigoureuse de ses besoins PKI. On active ADCS parce qu'on utilise déjà Microsoft Active Directory. Le service est intégré, il semble « gratuit » et il fonctionne bien avec les GPO. Cette facilité initiale explique sa diffusion massive.
Mais ce « gratuit » a un coût que beaucoup d'organisations découvrent tardivement. Complexité opérationnelle, surface d'attaque étendue et dépendance structurelle à Active Directory.
Le problème structurel : ADCS vit dans votre Tier 0
ADCS n'est pas un service isolé. Il est profondément imbriqué dans Active Directory, c'est-à-dire dans le niveau de privilèges le plus critique de votre infrastructure.
Cela implique plusieurs conséquences.
Une compromission d'ADCS peut ouvrir la voie à une compromission d'Active Directory. Chaque template de certificat, chaque point d'enrollment et chaque agent d'inscription devient un vecteur potentiel d'attaque. Les permissions par défaut sont conçues pour fonctionner immédiatement, pas pour être sécurisées dès le départ.
Dans certains scénarios, un attaquant capable d'obtenir un certificat frauduleux peut ensuite s'authentifier comme n'importe quel utilisateur du domaine, y compris un administrateur. La PKI devient alors un chemin indirect vers le contrôle de l'infrastructure.
Les attaques ESC : un flux continu, pas un incident isolé
En 2021, les chercheurs de SpecterOps publient le rapport Certified Pre-Owned et mettent en évidence plusieurs classes d'attaques contre ADCS connues sous le nom d'ESC.
Le constat est brutal. De nombreuses configurations ADCS permettent une élévation de privilèges.
Depuis cette publication, les découvertes se succèdent.
En 2021, les attaques ESC1 à ESC8 sont décrites.
En 2022, la vulnérabilité CVE-2022-26923 révèle un nouveau scénario d'élévation de privilèges lié à la jonction machine et aux certificats.
Les années suivantes voient apparaître de nouvelles variantes et de nouveaux scénarios d'abus.
Le point fondamental est que ces problèmes ne sont pas seulement des bugs logiciels. Ils découlent en grande partie du modèle même d'ADCS. Les templates permissifs, la délégation complexe et la dépendance aux permissions Active Directory créent un terrain fertile pour les abus.
Appliquer des correctifs améliore la situation, mais ne change pas la nature du système.
Une PKI enfermée dans Active Directory
ADCS dépend intrinsèquement d'Active Directory pour fonctionner. Cette dépendance crée des limites importantes dans les environnements modernes.
Les infrastructures actuelles incluent des workloads dans le cloud, des environnements multi-cloud, des conteneurs et des identités machines éphémères.
Des plateformes comme Kubernetes ou Docker fonctionnent avec des cycles de vie très courts et des identités dynamiques. Les environnements de Amazon Web Services, Google Cloud et Microsoft Azure multiplient les workloads qui ne rejoignent jamais un domaine Active Directory.
Dans ces contextes, ADCS devient difficile à utiliser nativement. Les conteneurs ne rejoignent pas le domaine. Les ressources cloud n'ont pas toujours d'identité Active Directory classique. Les partenaires externes ne font pas partie de votre forêt.
La PKI se retrouve donc limitée au périmètre Active Directory.
Le mur de l'automatisation
L'automatisation est devenue essentielle dans les environnements DevOps.
Le protocole ACME s'est imposé comme standard pour l'émission et le renouvellement automatisés de certificats. Il est utilisé par une grande partie de l'écosystème moderne, notamment via des outils comme Certbot et cert-manager.
ADCS ne supporte pas ce protocole nativement.
Dans la pratique, plusieurs effets apparaissent. Les équipes DevOps contournent la PKI interne avec des solutions externes. Des scripts apparaissent pour automatiser les renouvellements. Certains certificats expirent simplement parce que les processus sont trop complexes.
Progressivement, une Shadow PKI se met en place en parallèle de l'infrastructure officielle.
Une faible crypto-agilité face à la transition post-quantique
Les nouveaux standards post-quantiques du NIST, notamment FIPS 203 et FIPS 204, marquent le début d'une transition importante pour la cryptographie.
Les infrastructures PKI devront progressivement évoluer vers de nouveaux algorithmes, des certificats hybrides et des stratégies de migration contrôlée.
Aujourd'hui, ADCS n'offre ni support natif pour ces algorithmes ni feuille de route claire pour leur adoption. Adapter une PKI monolithique étroitement liée à Active Directory à ces nouvelles exigences risque d'être complexe.
Dépasser ADCS sans forcément le remplacer
La conclusion n'est pas nécessairement de supprimer immédiatement ADCS.
Dans de nombreuses organisations, il reste essentiel pour certains usages historiques. L'authentification Windows, les smartcards, le Wi-Fi d'entreprise ou certains VPN reposent encore sur lui. Le retirer brutalement serait coûteux et risqué.
Le véritable enjeu est ailleurs. ADCS ne doit plus être le centre de gravité de la PKI.
Pendant longtemps, il a été utilisé pour presque tous les certificats de l'entreprise. Ce modèle correspondait à une époque où l'infrastructure était majoritairement Windows et entièrement on-premise.
Aujourd'hui, les nouveaux environnements comme le cloud, les conteneurs ou les pipelines DevOps nécessitent des infrastructures PKI conçues pour l'automatisation et l'échelle.
Une approche pragmatique consiste donc à conserver ADCS pour les usages Windows historiques tout en déployant des autorités de certification modernes pour les nouveaux environnements. La gestion du cycle de vie des certificats peut alors être orchestrée à partir d'une couche de gouvernance indépendante capable de piloter plusieurs PKI.
Dans ce modèle, ADCS continue d'exister mais il cesse d'être un point critique unique.
En limitant son périmètre et en déplaçant les nouveaux usages vers des infrastructures PKI adaptées aux environnements modernes, la dépendance à Active Directory diminue fortement et la surface d'attaque associée se réduit.
Conclusion
ADCS a rendu service pendant plus de vingt ans. Mais il a été conçu pour un monde très différent de celui d'aujourd'hui. Un environnement Windows stable, centralisé et entièrement interne.
Les infrastructures modernes reposent désormais sur le cloud hybride, l'automatisation et les identités machines. À cela s'ajoute la transition progressive vers la cryptographie post-quantique.
Dans ce contexte, la question n'est pas forcément de supprimer ADCS immédiatement.
La vraie question est de savoir combien de temps encore votre PKI restera dépendante de lui comme composant central.
