Qu'est-ce qu'une autorité de certification ?

Introduction

Imaginez que vous devez acheter une maison. Avant que la banque ne remette l'hypothèque, un notaire vérifie l'identité du vendeur, s'assure que les documents de la propriété sont légitimes, et appose un sceau officiel sur tout. Sans le notaire, ni vous ni la banque ne pourraient faire confiance à la validité de la transaction.

A Autorité de certification (CA) joue le même rôle dans le monde numérique. C’est la tierce partie de confiance qui vérifie l’identité d’une entité (un site web, une organisation, un appareil) et délivre un certificat numérique confirmant cette identité. Le certificat lie une clé publique à l’identité vérifiée, et la signature numérique de la CA's sur le certificat est le sceau qui le rend fiable.

Chaque fois que votre navigateur établit une connexion HTTPS, il vérifie si le certificat du serveur a été émis par une autorité de certification (CA) qu’il reconnaît. Si la CA est fiable, la connexion se poursuit. Sinon, vous voyez un avertissement de sécurité. Ce mécanisme simple (vérifier l’émetteur, faire confiance au certificat) constitue la base de la confiance en ligne.

Types de CAs

Toutes les autorités de certification ne remplissent pas le même rôle ni n'opèrent au même niveau. Comprendre les distinctions est important lors de la conception ou de l'évaluation d'une PKI.

CAs publics

Les CA publics sont approuvés par les navigateurs, les systèmes d'exploitation et les appareils du monde entier. Des entreprises comme DigiCert, Let's Encrypt et Sectigo exploitent des CA publics. Leurs certificats racine sont préinstallés dans magasins de confiance, les listes sélectionnées de CA de confiance qui sont livrées avec chaque navigateur et système d'exploitation. Les CA publics sont nécessaires lorsque vous avez besoin de certificats que les utilisateurs externes ou le grand public valideront, comme les certificats TLS pour les sites web accessibles au public.

CA privés

Les CA privés (ou internes) sont exploités par les organisations pour leur propre usage. Ils délivrent des certificats pour les services internes, l'authentification des employés, l'identité des appareils et la communication entre microservices. Parce qu'ils ne figurent pas dans les magasins de confiance publics, leurs certificats ne sont fiables que par les systèmes que l'organisation configure. Les CA privés vous donnent un contrôle complet sur les politiques de certificats, les périodes de validité et les règles d'émission.

CA racine vs CA intermédiaires

Une Autorité de certification racine se situe au sommet de la hiérarchie de confiance. Son certificat est auto‑signé et stocké hors ligne dans des environnements hautement sécurisés, souvent dans modules de sécurité matérielle (HSM) à l'intérieur de coffres verrouillés. Les autorités de certification racine émettent rarement des certificats directement. Au lieu de cela, elles signent les certificats des autorités de certification intermédiaires, qui gèrent l'émission au quotidien. Cette conception en couches limite l'exposition : si une autorité de certification intermédiaire est compromise, seuls ses certificats doivent être révoqués, pas toute la racine. Cette architecture forme la chaîne de confiance.

Comment une AC délivre un certificat

Le processus d'émission suit une séquence bien définie. Que vous demandiez un certificat à une AC publique pour votre site web ou à une AC privée pour une API interne, les étapes sont fondamentalement les mêmes.

Génération de paire de clés

Le demandeur génère un paire de clés publique/privée. La clé privée reste secrète et ne quitte jamais le système du demandeur. La clé publique sera incluse dans le certificat.

Demande de signature de certificat (CSR)

Le demandeur crée une CSR, un message structuré contenant la clé publique, le nom de sujet souhaité (par ex., www.example.com), et d'autres détails d'identification. La CSR est signée numériquement avec la clé privée du demandeur, prouvant qu'il possède la clé correspondante.

Vérification d'identité

L'AC vérifie l'identité du demandeur's. Pour un certificat TLS public, cela peut impliquer de prouver le contrôle du domaine via un enregistrement DNS ou un défi HTTP. Pour un certificat validé par l'organisation, cela signifie vérifier les documents d'enregistrement légal. Pour une AC privée, la vérification peut suivre les politiques internes, comme la vérification d'un enregistrement Active Directory ou d'un flux d'approbation.

Signature de certificat

Une fois l'identité vérifiée, la CA construit le certificat, en intégrant la clé publique, les informations du sujet, les dates de validité et les extensions, et le signe avec la clé privée de la CA's. Cette signature est ce que les clients vérifieront pour établir la confiance.

Livraison du certificat

Le certificat signé est renvoyé au demandeur, qui l'installe sur le serveur, l'appareil ou l'application concerné. À partir de ce moment, tout client qui fait confiance à la CA émettrice acceptera le certificat comme valide.

La confiance CA Modèle

La confiance dans le système CA n'est pas aveugle. Elle est délibérément conçue à travers magasins de confiance et chaînes de certificats.

Navigateurs & Magasins de confiance du système d'exploitation

Chaque navigateur et système d'exploitation est fourni avec une liste préconfigurée de certificats d'autorité de certification racine de confiance. Apple, Google, Mozilla et Microsoft maintiennent chacun leurs propres programmes de magasin de confiance avec des exigences strictes que les AC doivent respecter, y compris des audits réguliers, la conformité aux normes de l'industrie et des rapports transparents. Si une AC ne respecte pas ces exigences, son certificat racine peut être retiré, rendant instantanément tous les certificats qu'elle a émis non fiables.

Chaîne de confiance

Lorsque votre navigateur reçoit un certificat, il ne se contente pas de vérifier si le certificat lui‑même est fiable. Il suit la chaîne de certificats, du certificat d’entité finale, en passant par un ou plusieurs CAs intermédiaires, jusqu’à un CA racine dans le magasin de confiance. Chaque maillon de la chaîne est vérifié en contrôlant la signature numérique du certificat qui le précède. Si chaque signature est valide et que la racine est fiable, toute la chaîne est fiable.

Certification croisée

Parfois, une nouvelle autorité de certification (CA) doit gagner la confiance avant que sa propre racine ne soit ajoutée aux magasins de confiance. Grâce à la cross‑certification, une CA déjà fiable signe le certificat de la nouvelle CA's, créant ainsi un chemin de confiance alternatif. Cette technique a été utilisée par Let's Encrypt dans ses premières années, lorsque sa racine était cross‑signée par IdenTrust.

Magasins de confiance privés

Les organisations qui exploitent des AC privées distribuent leurs certificats racine d'AC aux systèmes internes via des stratégies de groupe, des profils MDM ou des outils de gestion de configuration. Cela crée un magasin de confiance privé qui coexiste avec le magasin public, permettant aux certificats internes d'être validés sans impliquer d'AC publique.

Compromission d'AC & Révocation

Parce que les AC sont centrales dans le modèle de confiance, une AC compromise est l'un des événements les plus graves en cybersécurité. Si un attaquant obtient l'accès à la clé privée d'une AC, il peut délivrer des certificats frauduleux pour n'importe quel domaine, permettant des attaques de type homme du milieu invisibles pour les utilisateurs finaux.

Violations d'AC réelles

L'Histoire fournit des exemples frappants. En 2011, DigiNotar, une autorité de certification néerlandaise, a été compromise, et les attaquants ont émis des certificats frauduleux pour Google, Yahoo et d'autres grands domaines. L'incident a conduit à la suppression de la racine de DigiNotar des principaux magasins de confiance et à la faillite de l'entreprise. Comodo a subi une brèche similaire la même année. Ces événements ont souligné la nécessité de pratiques de sécurité robustes pour les AC et ont conduit à des initiatives comme Certificate Transparency.

Comment fonctionne la révocation

Lorsque qu'un certificat doit être invalidé avant sa date d'expiration, que ce soit en raison d'une compromission de clé, d'un changement de propriétaire, ou d'une violation de la CA, la CA révoque le. Les certificats révoqués sont publiés dans Listes de révocation de certificats (CRL) ou vérifiées en temps réel via le Protocole de statut de certificat en ligne (OCSP). Les navigateurs et les clients interrogent ces mécanismes pour s'assurer qu'ils ne font pas confiance à un certificat qui a été révoqué.

Protéger contre la compromission de la CA

Les autorités de certification modernes protègent contre les compromissions grâce à des clés racines hors ligne stockées dans des HSM, des contrôles de sécurité physique stricts, des audits réguliers WebTrust ou ETSI, et la participation aux journaux de transparence des certificats. Pour les autorités de certification privées, les organisations doivent appliquer les mêmes principes : garder les autorités racines hors ligne, utiliser des autorités intermédiaires pour l’émission, et surveiller toute l’activité des certificats.

Public vs Private CA : Quand utiliser Lequel

Choisir entre une autorité de certification publique et une privée dépend de qui doit faire confiance au certificat et du niveau de contrôle dont vous avez besoin sur les politiques d'émission.

Sites Web publics

Utilisez un CA public

Services internes & API

Utilisez un CA privé. Vous contrôlez le magasin de confiance de tous les systèmes internes, il n’est pas nécessaire d’impliquer une CA publique. Cela évite également les coûts par certificat et vous donne un contrôle total sur les politiques.

Authentification des employés

Utilisez un CA privé. Les certificats clients pour l’accès VPN, l’authentification Wi‑Fi ou la connexion par carte à puce doivent être émis par une CA interne dont la racine est déployée sur les appareils de l’entreprise.

IoT & Identité des appareils

Utilisez un CA privé. Les appareils que vous fabriquez ou gérez s'authentifient à votre infrastructure à l'aide de certificats que vous contrôlez. Un CA privé vous permet de définir des périodes de validité personnalisées, des algorithmes de clé et des politiques de révocation adaptées à vos appareils.

Signature de code

Utilisez un CA public pour les logiciels distribués aux clients externes. Utilisez un CA privé pour les scripts et outils internes où vous contrôlez les points de terminaison.

Microservices & mTLS

Utilisez un CA privé. La communication de service à service au sein de votre infrastructure doit utiliser des certificats d'un CA interne. C’est la base des architectures zéro‑confiance où chaque service prouve son identité à chaque autre service.

De nombreuses organisations utilisent les deux. Les CA publics gèrent les certificats destinés à l'extérieur, tandis qu'un CA privé, souvent géré via une plateforme comme Evertrust PKI, gère tout en interne. L’essentiel est de comprendre les limites de confiance et de choisir en conséquence.

Evertrust & Gestion de CA privé

Exécutez votre propre CA privé: Evertrust PKI vous permet de déployer une autorité de certification privée entièrement fonctionnelle avec des hiérarchies de CA racine et intermédiaires, des profils de certificats personnalisables et une délivrance basée sur les politiques, le tout via une plateforme moderne et auditable.

Automatisez l'émission à grande échelle: La prise en charge d'ACME, SCEP, EST et des API REST signifie que les certificats peuvent être demandés et déployés automatiquement par les serveurs, les appareils et les pipelines CI/CD, sans intervention manuelle requise.

Appliquer la gouvernance: Définir les politiques de certificats, les flux d'approbation, les contraintes de nommage et les exigences d'algorithmes de clé. Chaque émission est enregistrée et auditable, répondant aux attentes de gouvernance de PKI d'entreprise déploiements.

Visibilité unifiée: Que vos certificats proviennent d'autorités de certification publiques, privées, ou les deux, Evertrust fournit un tableau de bord unique pour surveiller, alerter et rendre compte de l'ensemble de votre parc de certificats.

PKI

CLM

Cas d’utilisation

Secteurs

Conformité

Apprendre

Outils & analyses

Événements & Communauté

Qu'est-ce qu'un certificat Autorité?

Faits rapides