Certificat électronique et PKI : autorité de certification et chaîne de confiance

Un certificat électronique est un fichier qui associe une clé publique à une identité (un nom de domaine, une personne, une machine) et qui est signé par une autorité de certification, un tiers de confiance qui atteste ce lien. Une PKI (Public Key Infrastructure, infrastructure de gestion de clés) est l'ensemble des autorités, des règles et des outils qui délivrent, renouvellent et révoquent ces certificats. Ce chapitre explique le problème que résout un certificat, son contenu, la chaîne de confiance, la révocation, l'obtention d'un certificat public avec Let's Encrypt et le déploiement d'une autorité interne en entreprise.

Le problème : à qui appartient cette clé publique ?

La cryptographie asymétrique a un point faible : une clé publique n'est qu'une suite d'octets, sans nom dessus. Quand ton navigateur se connecte à portail.helianthe.example, le serveur lui envoie une clé publique. Rien ne prouve qu'elle appartient au laboratoire : un attaquant placé entre toi et le serveur (sur un Wi-Fi public piégé, par une fausse réponse DNS) peut envoyer sa clé publique, se faire passer pour le portail, déchiffrer ce que tu envoies et le relayer au vrai serveur. C'est l'attaque de l'homme du milieu.

Le certificat règle ce problème en faisant intervenir un tiers : une autorité de certification (AC, ou CA en anglais) vérifie que le demandeur contrôle bien le nom de domaine, puis signe un document qui dit « cette clé publique appartient à portail.helianthe.example ». Le navigateur fait confiance à l'autorité, donc au certificat qu'elle a signé.

Ce que contient un certificat X.509

Les certificats suivent la norme X.509 (version 3). Tu peux lire celui de n'importe quel site dans ton navigateur (clic sur le cadenas, puis sur les détails du certificat) ou avec OpenSSL :

openssl x509 -in intranet.crt -noout -subject -issuer -dates -ext subjectAltName
# subject=CN=intranet.helianthe.lan
# issuer=CN=intranet.helianthe.lan
# notBefore=Nov  1 18:23:34 2026 GMT
# notAfter=Nov  1 18:23:34 2027 GMT
# X509v3 Subject Alternative Name:
#     DNS:intranet.helianthe.lan

Ici, le sujet et l'émetteur sont identiques : c'est un certificat auto-signé, que personne n'a garanti. Il chiffre aussi bien qu'un autre, mais il ne prouve pas l'identité du serveur, et le navigateur affiche un avertissement.

Autorité de certification et chaîne de confiance

Les navigateurs et les systèmes d'exploitation embarquent une liste d'autorités racines de confiance, d'une centaine à quelques centaines selon le magasin : le magasin de certificats de Windows, le trousseau de macOS, celui de Mozilla (utilisé par Firefox et la plupart des distributions Linux), celui d'Android. Ces autorités sont auditées chaque année selon les règles du CA/Browser Forum, qui réunit autorités et éditeurs de navigateurs.

Une racine ne signe presque jamais directement les certificats des sites : sa clé privée est trop précieuse, gardée hors ligne dans un module matériel. Elle signe les certificats d'autorités intermédiaires, qui signent à leur tour les certificats des serveurs. On obtient une chaîne de confiance :

À chaque connexion HTTPS, le navigateur vérifie :

1. que chaque certificat de la chaîne est bien signé par le niveau au-dessus, jusqu'à une racine de son magasin ;
2. que la date du jour est comprise dans la période de validité de chaque certificat ;
3. que le nom demandé figure dans le champ SAN du certificat du serveur ;
4. que le certificat n'est pas révoqué ;
5. que l'usage prévu (authentification d'un serveur TLS) est autorisé.

Il vérifie enfin que le serveur possède bien la clé privée correspondant au certificat : pendant la poignée de main, le serveur signe les données de la session avec cette clé (chapitre 9). Un attaquant peut copier un certificat public, il ne peut pas produire cette signature.

Révocation, durée de vie et automatisation

Quand une clé privée est compromise (serveur piraté, sauvegarde perdue), il faut révoquer le certificat avant son expiration. Deux mécanismes existent :

• la liste de révocation (CRL, Certificate Revocation List), publiée et signée régulièrement par l'autorité, qui donne les numéros de série révoqués ;
• le protocole OCSP, qui interroge l'autorité en temps réel sur un certificat précis.

En pratique, la révocation fonctionne mal : les navigateurs ne bloquent pas la connexion si le service de vérification ne répond pas, et ils ont développé leurs propres mécanismes. Le CA/Browser Forum a rendu OCSP facultatif en 2023 et les CRL obligatoires, et Let's Encrypt a retiré OCSP de ses certificats en 2025. La réponse retenue par le secteur est de raccourcir la durée de vie des certificats : une clé compromise ne sert plus longtemps. Le CA/Browser Forum a voté en avril 2025 un calendrier de réduction de la durée maximale des certificats publics TLS :

Avec 47 jours, le renouvellement manuel devient impossible : il faut automatiser. C'est le rôle du protocole ACME, popularisé par Let's Encrypt.

Les types de certificats

D'autres certificats servent à autre chose qu'aux serveurs web : certificat client pour s'authentifier sur un VPN ou un réseau Wi-Fi, certificat de signature de code, certificat de messagerie S/MIME, certificat de signature électronique d'une personne.

Obtenir un certificat public avec Let's Encrypt

Let's Encrypt est une autorité de certification gratuite et automatisée, gérée par une association à but non lucratif (ISRG), qui délivre des certificats DV valables 90 jours ; cette durée passera à 64 jours en février 2027, puis à 45 jours en février 2028. Le client certbot demande le certificat, prouve le contrôle du domaine, installe le certificat et le renouvelle automatiquement :

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d portail.helianthe.example
# certbot prouve le contrôle du domaine (défi HTTP-01 sur le port 80),
# récupère le certificat et la chaîne, et modifie la configuration de nginx

sudo certbot renew --dry-run      # tester le renouvellement automatique

Le défi HTTP-01 demande que le port 80 du serveur soit joignable depuis Internet. Le défi DNS-01 (créer un enregistrement TXT _acme-challenge) fonctionne pour un serveur interne et il est obligatoire pour un certificat générique. Sous Windows, des clients ACME comme win-acme font le même travail pour IIS.

Une PKI interne : AD CS et autorités privées

Les noms internes (intranet.helianthe.lan, srv-ad01.helianthe.lan) ne peuvent pas recevoir de certificat public : aucune autorité publique ne certifie un domaine .lan. L'organisation monte donc sa propre autorité de certification.

Sous Windows Server, le rôle AD CS (Active Directory Certificate Services) fournit une autorité intégrée à l'annuaire :

• elle délivre des certificats aux serveurs (LDAPS, sites intranet, Bureau à distance), aux postes et aux utilisateurs (authentification Wi-Fi 802.1X par EAP-TLS, VPN, signature de courriels) ;
• l'inscription automatique (autoenrollment), activée par stratégie de groupe, délivre et renouvelle les certificats sans intervention ;
• une stratégie de groupe déploie le certificat de la racine interne dans le magasin « Autorités de certification racines de confiance » de tous les postes du domaine.

Les bonnes pratiques : une racine hors ligne (une machine éteinte, sortie du coffre seulement pour signer les intermédiaires et publier les listes de révocation), une ou plusieurs autorités intermédiaires en ligne qui délivrent les certificats, des modèles de certificats limités au strict nécessaire, et une surveillance des demandes. Une autorité interne mal configurée est une cible de choix : un attaquant qui peut s'y faire délivrer un certificat au nom d'un administrateur prend le contrôle du domaine.

Sous Linux, les outils easy-rsa (livré avec OpenVPN) ou step-ca jouent le même rôle pour des besoins plus simples.

Créer une demande de certificat avec OpenSSL

Pour obtenir un certificat d'une autorité (interne ou commerciale) sans client ACME, on génère une clé privée et une demande de signature de certificat (CSR), qu'on transmet à l'autorité. La clé privée ne quitte pas le serveur :

# Clé privée et demande de certificat (CSR)
openssl req -new -newkey rsa:3072 -nodes -keyout portail.key -out portail.csr \
  -subj "/C=FR/O=Laboratoires Helianthe/CN=portail.helianthe.example" \
  -addext "subjectAltName=DNS:portail.helianthe.example"

# Certificat auto-signé pour un test (clé P-256, valable un an)
openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -days 365 -nodes \
  -keyout intranet.key -out intranet.crt \
  -subj "/CN=intranet.helianthe.lan" -addext "subjectAltName=DNS:intranet.helianthe.lan"

# Regrouper certificat et clé privée dans un fichier PKCS#12 (.pfx) pour Windows
openssl pkcs12 -export -inkey portail.key -in portail.crt -out portail.pfx

L'option -nodes laisse la clé privée non chiffrée, ce qui permet au service web de démarrer sans saisie de mot de passe ; la clé doit alors être protégée par les droits du système de fichiers (lisible par le seul compte du service).

Lire une erreur de certificat

Les autorités publiques doivent publier chaque certificat émis dans des journaux publics, les registres de transparence des certificats (Certificate Transparency). Un site comme crt.sh permet de rechercher tous les certificats émis pour ton domaine : c'est un moyen simple de détecter un certificat frauduleux à ton nom, une menace pour l'identité numérique de l'organisation.

À l'E7 : comment la notion est demandée

• Une autorité interne à faire reconnaître. Le dossier documentaire du sujet SISR 2025 (cas Blanca) précise que le portail captif du pare-feu « présente un certificat qui doit être approuvé par les utilisateurs finaux (l'autorité de certification qui émet le certificat doit être présente dans le magasin racine de confiance sur l'ordinateur client) » et que ce certificat « émane d'une autorité de certification de confiance interne ». À savoir expliquer : sur les postes gérés, on déploie la racine par stratégie de groupe ; sur les machines personnelles des visiteurs, elle est inconnue, d'où un avertissement, et un certificat public pour le nom du portail serait préférable.
• Une authentification par certificat. Le sujet SLAM 2024 (cas Gsic) prévoit que « seuls les utilisateurs habilités pourront utiliser les vues via une authentification par certificat ». Un certificat client prouve l'identité de son porteur par la possession de la clé privée.
• Justifier HTTPS (cas Kirassur, 2025) : le certificat authentifie le serveur, ce qui empêche l'homme du milieu de se faire passer pour lui.

En SISR, attends-toi à déployer une autorité interne, à lire une chaîne ou une erreur de certificat, à choisir un certificat pour un VPN ou un réseau Wi-Fi d'entreprise. En SLAM, à configurer HTTPS pour une application, à vérifier un certificat côté client (ne jamais désactiver la vérification, CURLOPT_SSL_VERIFYPEER à false ou rejectUnauthorized: false, même « pour tester »), ou à authentifier un service par certificat.

Pour aller plus loin. Le déploiement des certificats dans une infrastructure (serveurs web, VPN, Wi-Fi 802.1X) est vu côté SISR dans le chapitre Chiffrement, certificats SSL/TLS et PKI du cours Cybersécurité des infrastructures.

Exercices

subject=CN=www.helianthe.example
issuer=C=FR, O=Exemple Certification, CN=Exemple TLS RSA CA 2026
notBefore=Apr  1 00:00:00 2026 GMT
notAfter=Oct 17 23:59:59 2026 GMT
X509v3 Subject Alternative Name: DNS:www.helianthe.example, DNS:helianthe.example
X509v3 Extended Key Usage: TLS Web Server Authentication