IREX - Autorité de certification privée : comparatif, risques et passage à la confiance publique

1. Introduction

Dans de nombreuses organisations, les besoins de sécurisation des communications internes, des API, des microservices ou des équipements dépassent le périmètre des certificats publics délivrés par les autorités de certification traditionnelles. Les certificats publics ne permettent notamment pas de couvrir certains besoins internes, tels que les noms de domaine non publics ou les adresses IP réservées. Pour les environnements générant de nombreux certificats ou nécessitant des certificats à courte durée de vie, le choix entre une CA publique et une CA privée dépend plutôt du périmètre de confiance, des exigences d'identification et des besoins d'automatisation.

Une autorité de certification privée (CA privée) répond à ces besoins en permettant à l'organisation de générer, gérer et révoquer ses propres certificats au sein d'une infrastructure de confiance qu'elle contrôle. Cette approche apporte de la flexibilité, mais introduit également des responsabilités opérationnelles et des risques spécifiques.

Cet article présente les motivations pour déployer une CA privée, un comparatif des principales solutions disponibles, les risques associés à leur mise en œuvre, les bonnes pratiques pour les limiter, ainsi que la distinction fondamentale entre confiance privée et confiance publique.

2. Pourquoi mettre en place une CA privée ?

Plusieurs situations justifient le déploiement d'une autorité de certification privée :

Noms internes et adresses privées. Les CA publiques ne délivrent pas de certificats pour des noms de domaine non publics (par exemple *.internal) ni pour des adresses IP privées. Une CA privée permet de sécuriser ces ressources.

Volumes et automatisation. Les environnements cloud-native, Kubernetes ou microservices génèrent un grand nombre de certificats à durée de vie courte. Une CA privée, associée à des protocoles comme ACME, permet d'automatiser l'émission et le renouvellement à grande échelle.

Contrôle et confidentialité. L'organisation conserve la maîtrise de sa chaîne de confiance, de ses politiques d'émission et de ses clés. Cela peut répondre à des exigences de souveraineté ou de conformité interne.

Cas d'usage spécifiques. Authentification mutuelle (mTLS), certificats SSH, identité des charges de travail, équipements IoT ou réseaux privés font partie des cas d'utilisation pour lesquels une CA privée peut être pertinente.

Une CA privée n'est cependant pas un substitut universel aux certificats publics. Elle s'inscrit dans un périmètre de confiance interne défini et géré par l'organisation.

3. Comparatif des solutions pour une CA privée

Plusieurs solutions permettent de mettre en place une CA privée. Elles diffèrent par leur complexité, leur modèle de licence, leur support de l'automatisation et leur orientation (DevOps, entreprise traditionnelle, plateformes cloud).

step-CA est une autorité de certification open source (licence Apache 2.0) conçue pour les environnements modernes. Elle propose un support natif d'ACME, l'émission de certificats X.509 et SSH, et une architecture à deux niveaux (racine hors ligne + intermédiaire en ligne). Elle s'intègre bien avec Kubernetes et les outils DevOps. step-CA privilégie un modèle de révocation passive : un certificat révoqué n'est notamment plus renouvelable, tandis que les mécanismes de révocation active comme CRL ou OCSP sont plus limités. Le support HSM/KMS est disponible. Elle est particulièrement adaptée aux équipes qui privilégient la simplicité opérationnelle et l'automatisation.

Le moteur PKI de Vault s'inscrit dans une plateforme plus large de gestion des secrets. Il permet l'émission dynamique de certificats à durée de vie courte via API, avec support ACME depuis la version 1.14. Les versions concernées de Vault sont distribuées sous licence Business Source License (BSL 1.1), ce qui les positionne comme logiciels « source disponibles » plutôt qu'open source au sens classique. Vault PKI est pertinent lorsque Vault est déjà déployé dans l'organisation.

Ces outils permettent de construire manuellement une PKI (génération de clés, signature de certificats, CRL). Ils ne fournissent pas de serveur ACME intégré comparable à celui de solutions spécialisées. Ils permettent néanmoins d'automatiser certaines opérations à l'aide de scripts et de modes non interactifs (Easy-RSA propose notamment un mode batch). Ils restent particulièrement adaptés aux laboratoires, aux environnements contrôlés ou aux PKI dont les besoins d'automatisation restent limités.

EJBCA est une plateforme CA complète (Community en LGPL, Enterprise commerciale). Elle offre un large éventail de protocoles (ACME, SCEP, EST, CMP, REST) et des profils de certificats riches. EJBCA propose des fonctionnalités et une architecture adaptées aux environnements soumis à des exigences de conformité et d'audit, notamment dans des contextes utilisant des référentiels tels que WebTrust ou ETSI. Elle est plus lourde à opérer (stack Java) et s'adresse principalement aux organisations ayant des besoins d'entreprise ou de conformité élevés.

Microsoft AD CS reste répandu dans les environnements Windows. Les services managés (AWS Private CA, Google Certificate Authority Service) externalisent l'exploitation de la CA tout en conservant le contrôle des politiques. Ces solutions peuvent réduire la charge opérationnelle au prix d'une dépendance au fournisseur cloud.

La complexité indiquée est indicative et dépend du contexte de déploiement, du niveau d'automatisation recherché et des exigences de sécurité.

4. Risques liés à l'implémentation d'une CA privée

Déployer une CA privée transfère à l'organisation des responsabilités qui, dans le modèle public, sont assumées par des acteurs spécialisés et audités. Les principaux risques sont les suivants.

La compromission de la clé privée d'une CA peut permettre à un attaquant d'émettre des certificats frauduleux qui seront susceptibles d'être acceptés par les systèmes faisant confiance à cette CA, selon les politiques et contrôles appliqués. Pour une racine, le risque est évidemment particulièrement grave : usurpation d'identité, interception de communications, accès non autorisés.

Une CA en ligne indisponible empêche l'émission et le renouvellement automatisés des certificats. Les certificats déjà émis restent valides jusqu'à leur expiration, mais les services dont les certificats arrivent à terme peuvent devenir inaccessibles. L'absence de haute disponibilité ou de procédures de bascule constitue un risque opérationnel réel.

L'oubli de renouvellement, l'absence d'inventaire des certificats ou des processus manuels augmentent le risque d'expirations non anticipées et d'interruptions. Une mauvaise gestion du cycle de vie peut ainsi provoquer des expirations non anticipées et des interruptions de service.

Des politiques d'émission trop permissives, des contrôles d'identité insuffisants ou des erreurs de configuration peuvent conduire à l'émission de certificats pour des identités non autorisées. Cela affaiblit la confiance interne.

Le certificat racine doit être distribué aux systèmes qui doivent faire confiance aux certificats émis par cette PKI. Une distribution incomplète ou des mises à jour manquées entraînent des erreurs de validation difficiles à diagnostiquer.

L'exploitation d'une PKI exige des compétences spécifiques (cérémonies de clés, protection des clés, politiques, journalisation). Une dépendance à un nombre limité de personnes ou l'absence de documentation formelle constitue un risque organisationnel.

5. Bonnes pratiques pour limiter ces risques

Les pratiques suivantes permettent de réduire les principaux risques associés à l'exploitation d'une CA privée.

Utiliser une racine hors ligne, idéalement avec une protection cryptographique appropriée pouvant notamment s'appuyer sur un HSM et/ou une infrastructure hors ligne, qui ne signe que des certificats d'autorités intermédiaires. Les intermédiaires en ligne émettent les certificats d'entité finale. En cas de compromission d'un intermédiaire, la racine reste intacte et peut signer un nouvel intermédiaire.

Stocker les clés de CA dans des modules matériels de sécurité (HSM) ou des services de gestion de clés cloud (KMS) qui empêchent l'export de la clé privée. Restreindre strictement les accès administratifs et journaliser toutes les opérations sensibles.

Lorsque le contexte le permet, privilégier des certificats à durée de vie courte, par exemple de quelques heures à quelques jours, afin de réduire la fenêtre d'exposition en cas de compromission d'une clé d'entité finale et la dépendance à des mécanismes de révocation active complexes.

Mettre en place des mécanismes d'émission et de renouvellement automatisés (ACME, API, agents). L'automatisation réduit les erreurs humaines et les risques d'expiration non anticipée.

Concevoir la CA pour la haute disponibilité (réplication, bascule) lorsque l'émission et le renouvellement sont critiques. Prévoir des procédures de récupération documentées en cas d'incident.

Documenter les politiques d'émission, les procédures de cérémonie de clés, les rôles et responsabilités, ainsi que les plans de réponse aux incidents. Maintenir un inventaire des certificats et surveiller les métriques d'émission, de renouvellement et d'expiration.

Limiter les droits d'émission aux seules identités et usages nécessaires. Utiliser des profils ou des politiques de certificats restrictifs.

6. De la confiance privée à la confiance publique : principes et démarche

Il est essentiel de distinguer clairement la confiance privée de la confiance publique. Ces deux modèles reposent sur des mécanismes et des exigences fondamentalement différents.

Dans une CA privée, la confiance est établie par l'organisation elle-même. Le certificat racine est déployé explicitement dans les magasins de confiance des systèmes internes (serveurs, postes de travail, conteneurs, équipements). Seuls les systèmes configurés pour faire confiance à cette racine valideront les certificats émis. La portée de la confiance est donc limitée au périmètre contrôlé par l'organisation.

Dans le modèle public (WebPKI), les certificats sont reconnus automatiquement par les navigateurs, systèmes d'exploitation et applications grand public. Cela repose sur l'inclusion préalable du certificat racine de la CA dans les programmes de confiance et magasins de certificats racines des fournisseurs de systèmes d'exploitation, navigateurs et applications concernés (Mozilla, Google Chrome, Microsoft, Apple, etc.).

Pour obtenir cette inclusion, une CA doit notamment :

• Se conformer aux Baseline Requirements du CA/Browser Forum (exigences techniques, organisationnelles et de validation d'identité) ;
• Passer des audits indépendants réguliers (WebTrust, ETSI ou équivalents) ;
• Respecter les exigences applicables en matière de Certificate Transparency (CT) pour les certificats concernés ;
• Respecter des politiques strictes de protection des clés, de journalisation et de gestion des incidents ;
• Suivre les processus d'inclusion propres à chaque programme racine (Mozilla, Chrome Root Program, Microsoft, Apple…).

Ces exigences sont exigeantes, coûteuses et soumises à un contrôle continu. Ces exigences du WebPKI ne s'appliquent pas de la même manière aux PKI strictement internes dont les certificats ne sont pas destinés à être publiquement approuvés.

Une CA privée ne se « transforme » pas en CA publique par simple reconfiguration technique. L'accès à la confiance publique implique de satisfaire un ensemble d'exigences externes, d'audits et de processus d'inclusion et exigences de gouvernance qui vont bien au-delà de l'exploitation d'une CA interne. La plupart des organisations n'ont d'ailleurs aucun besoin de rendre leur CA privée de confiance publique.

Lorsqu'une organisation souhaite disposer à la fois de certificats internes et de certificats publics, la pratique courante consiste à utiliser une CA privée pour le périmètre interne et des certificats délivrés par une CA publique reconnue pour les services exposés sur Internet.

7. Conclusion

Une autorité de certification privée apporte une flexibilité précieuse pour sécuriser les communications et les identités au sein d'une organisation. Elle permet de répondre à des besoins que les CA publiques ne couvrent pas, notamment les noms non publics ou les adresses IP réservées, tout en offrant à l'organisation un contrôle plus important sur ses politiques de confiance et d'émission.

Ce choix s'accompagne toutefois de responsabilités importantes : protection des clés, disponibilité, gouvernance, automatisation et distribution de la confiance. Les solutions disponibles (step-CA, Vault PKI, EJBCA, outils manuels ou services managés) offrent des compromis différents en termes de complexité, de fonctionnalités et de modèle de licence.

Enfin, la distinction entre confiance privée et confiance publique est structurante. La confiance publique repose sur des exigences externes strictes et des processus d'inclusion dans les magasins de confiance des éditeurs. Elle ne constitue pas une simple évolution d'une CA privée.

Une CA privée bien conçue, opérée selon les bonnes pratiques et limitée à son périmètre de confiance, reste un outil puissant et pertinent pour de nombreuses organisations.

8. Voir aussi

• Simplifiez la gestion des accès avec Keycloak
• Configurer une fédération d'identité OIDC avec Keycloak
• Blockchain et les cryptomonnaies