Chapitre 10 — PKI, Autorités de Certification & Certificats

La PKI (Public Key Infrastructure) est l'infrastructure de confiance qui permet la communication sécurisée sur internet. Ce module couvre les CAs, les types de certificats, et leur cycle de vie.

Infrastructure PKI

Mémorisez ! Un certificat numérique lie une clé publique à une identité. L'Autorité de Certification (CA) est le tiers de confiance qui signe les certificats. La hiérarchie PKI : Root CA → Intermediate CA → End-Entity Certificate (feuille). La Root CA est hors ligne pour la protéger.

CA (Certificate Authority) : tiers de confiance qui émet et signe les certificats numériques. Exemples : DigiCert, Let's Encrypt, Comodo, GlobalSign.
Root CA : CA racine dont le certificat est auto-signé et pré-installé dans les navigateurs/OS. Doit être maintenu hors ligne (air-gapped) pour éviter sa compromission.
Intermediate CA (SubCA) : CA intermédiaire signée par la Root CA. Émet les certificats finaux. Protège la Root CA (si une Intermediate CA est compromise, seuls les certs qu'elle a signés sont révoqués).
Certificate Chain (Chaîne de confiance) : End-Entity Cert → Intermediate CA cert → Root CA cert. Le client valide chaque maillon.
RA (Registration Authority) : entité qui vérifie l'identité du demandeur avant que la CA émette le certificat. Sépare la vérification de l'émission.
CA privée vs CA publique : CA privée = interne à l'organisation, non reconnue par les navigateurs (nécessite installation manuelle). CA publique = reconnue par défaut (DigiCert, Let's Encrypt).

Types de Certificats

Type	Validation	Exemple
DV (Domain Validation)	Vérifie uniquement la propriété du domaine	Let's Encrypt — HTTPS basique, pas de vérification d'identité
OV (Organization Validation)	Vérifie domaine + existence légale de l'organisation	Sites commerciaux — nom d'organisation dans le cert
EV (Extended Validation)	Vérification approfondie (documents légaux, physique)	Banques — ancienne barre verte (abandonnée dans Chrome 77)
*Wildcard ()**	Couvre tous les sous-domaines d'un domaine	*.example.com couvre mail.example.com, www.example.com, etc.
SAN (Subject Alternative Name)	Plusieurs domaines dans un seul certificat	example.com + example.fr + www.example.com
Self-Signed	Signé par la propre clé privée du sujet (pas de CA tierce)	Tests internes uniquement — génère des avertissements navigateur

Révocation de Certificats

CRL (Certificate Revocation List) : liste publiée par la CA des certificats révoqués avant expiration. Le client télécharge la CRL et vérifie. Problème : taille de la liste, délai de mise à jour.
OCSP (Online Certificate Status Protocol) : le client interroge le serveur OCSP de la CA en temps réel pour vérifier le statut d'un certificat spécifique. Plus rapide et plus léger que la CRL.
OCSP Stapling : le serveur web inclut (staple) la réponse OCSP dans le handshake TLS. Évite que le client contacte la CA — meilleur pour la vie privée et les performances.
Raisons de révocation : clé privée compromise, changement d'organisation, mauvaise émission, cessation d'utilisation.
Certificate Pinning : l'application s'attend à un certificat ou une clé publique spécifique. Protège contre les attaques on-path même avec un certificat valide d'une CA compromise.

Astuce Examen

Question fréquente : "un certificat a expiré ET a été révoqué — quelle est la différence ?" Expiration = date normale d'expiration atteinte. Révocation = invalidé avant l'expiration par la CA (clé compromise, etc.). La révocation est consultée via CRL ou OCSP. Un certificat expiré est aussi invalide mais sans consulter la CRL/OCSP.

Cycle de Vie d'un Certificat

Génération de la paire de clés : le demandeur génère sa paire clé publique/privée (localement ou via HSM).
CSR (Certificate Signing Request) : fichier contenant la clé publique + informations du demandeur (CN, O, C) envoyé à la CA.
Vérification : la CA (ou RA) vérifie l'identité du demandeur selon le niveau de validation (DV/OV/EV).
Émission : la CA signe la clé publique du demandeur avec sa propre clé privée → certificat X.509.
Installation : le certificat est installé sur le serveur web (avec la clé privée, jamais partagée).
Renouvellement : avant expiration. Let's Encrypt = 90 jours (renouvellement automatique recommandé).
Révocation ou expiration : fin du cycle. CRL/OCSP mis à jour.

Quiz — PKI & Certificats

1. Pourquoi une Root CA doit-elle être maintenue hors ligne (air-gapped) ?

Pour économiser de l'énergie Pour protéger la clé privée de la Root CA — sa compromission invaliderait TOUS les certificats de toute la hiérarchie PKI Les Root CAs n'ont pas besoin d'émettre de certificats fréquemment Pour respecter les exigences légales

Si la clé privée de la Root CA est volée, un attaquant peut signer n'importe quel certificat frauduleux qui sera considéré comme valide par tous les navigateurs. Exemple : compromission de DigiNotar en 2011 — des certificats frauduleux *.google.com ont été émis. Solution : Root CA hors ligne, émet uniquement des certificats d'Intermediate CA.

2. Un certificat wildcard (*.example.com) couvre :

Tous les domaines contenant "example" Uniquement www.example.com example.com et tous ses sous-domaines à tous les niveaux Tous les sous-domaines directs de example.com (www, mail, shop...) mais PAS les sous-sous-domaines (api.dev.example.com)

Wildcard *.example.com = un seul niveau de sous-domaine. Couvre : www.example.com, mail.example.com, shop.example.com. Ne couvre PAS : example.com (lui-même), api.dev.example.com (deux niveaux). Pour plusieurs domaines différents : SAN (Subject Alternative Name). Pour les sous-sous-domaines : certificat dédié ou SAN.

3. OCSP Stapling est une amélioration d'OCSP qui :

Stocke les CRLs directement dans le certificat Empêche la révocation des certificats Permet au serveur web d'inclure la réponse OCSP dans le handshake TLS, évitant que le client contacte la CA Prolonge automatiquement les certificats expirés

Sans OCSP Stapling : le navigateur contacte le serveur OCSP de la CA pour chaque connexion (lent, vie privée — la CA sait quel site vous visitez). Avec OCSP Stapling : le serveur web récupère lui-même la réponse OCSP de la CA (valide ~24h) et l'inclut dans le handshake TLS. Plus rapide, meilleure vie privée.

4. Un CSR (Certificate Signing Request) contient :

La clé publique du demandeur et ses informations d'identité, signé avec la clé privée du demandeur La clé privée du demandeur chiffrée La signature numérique de la CA Le certificat émis par la CA

CSR = fichier généré par le demandeur contenant : clé publique + informations (CN=example.com, O=Ma Société, C=FR). Signé avec la clé privée du demandeur (prouve qu'il possède la clé privée correspondante). Envoyé à la CA qui vérifie, puis signe la clé publique avec sa propre clé privée pour créer le certificat X.509.

5. La CRL (Certificate Revocation List) présente quel inconvénient principal ?

Elle ne peut pas révoquer les certificats wildcard Elle peut être volumineuse et son téléchargement peut être lent ; elle n'est pas mise à jour en temps réel Elle n'est pas supportée par les navigateurs modernes Elle révoque uniquement les certificats EV

CRL = liste complète de tous les certificats révoqués émis par une CA. Problèmes : 1) La liste grossit avec le temps (peut être volumineuse). 2) Doit être téléchargée périodiquement → pas temps réel. 3) En cas de ca offline, les CRLs ne peuvent pas être mises à jour. OCSP résout ces problèmes avec des vérifications en temps réel d'un certificat spécifique.

6. Un certificat "self-signed" (auto-signé) est signé :

Par une CA publique reconnue Par la CA intermédiaire de l'organisation Par les navigateurs web Par la propre clé privée du sujet — sans tiers de confiance externe

Self-signed = le certificat est signé par la même entité qu'il identifie (pas de CA tierce). Les navigateurs affichent un avertissement de sécurité car ils ne peuvent pas vérifier l'identité via une chaîne de confiance. Usage légitime : tests internes, CA privée d'entreprise (racine auto-signée installée manuellement dans les appareils gérés).

7. La différence entre un certificat DV et OV est :

DV utilise RSA, OV utilise ECC OV offre un chiffrement plus fort OV vérifie l'existence légale de l'organisation en plus du domaine ; DV vérifie uniquement le contrôle du domaine DV est gratuit, OV est toujours payant

DV (Domain Validation) = preuve que vous contrôlez le domaine (fichier HTTP ou enregistrement DNS). Rapide, automatisable (Let's Encrypt). OV (Organization Validation) = DV + vérification que l'organisation existe légalement (base de données commerciales). Plus long. EV = OV + vérification approfondie (documents légaux, présence physique). Le chiffrement est identique dans les trois cas.

8. Une CA intermédiaire (SubCA) est utilisée dans la hiérarchie PKI pour : Protéger la Root CA en la maintenant hors ligne — si une SubCA est compromise, seuls ses certificats sont révoqués, pas toute la hiérarchie Émettre des certificats de durée de vie plus longue Accélérer l'émission des certificats Réduire le coût des certificats

Hiérarchie PKI : Root CA (hors ligne, rarement utilisée) → Intermediate CAs (opérationnelles, émettent les certs finaux). Si une Intermediate CA est compromise : seuls les certificats qu'elle a émis sont révoqués. La Root CA reste intacte et peut émettre une nouvelle Intermediate CA. Sans cette structure, toute compromission nécessiterait de refaire toute la PKI.

9. Le "Certificate Pinning" protège contre : L'expiration des certificats Les attaques par force brute sur la clé privée Les attaques on-path même avec un certificat valide émis par une CA compromise — l'application n'accepte que le certificat ou la clé publique spécifique qu'elle connaît La révocation des certificats

Pinning = l'application mobile/web "épingle" un certificat ou une clé publique spécifique. Même si un attaquant obtient un certificat valide (via CA compromise ou rogue CA) pour le même domaine, le pinning le rejettera. Utilisé par les applications bancaires, Gmail. Inconvénient : difficile à mettre à jour (renouvellement de cert = mise à jour app).

10. Un certificat SAN (Subject Alternative Name) permet de : Définir plusieurs niveaux de sous-domaines wildcards Inclure plusieurs noms de domaine différents dans un seul certificat Signer plusieurs fois le même certificat Prolonger la durée de validité d'un certificat expiré

SAN = champ du certificat X.509 listant des noms alternatifs. Un seul certificat peut couvrir : example.com, www.example.com, example.fr, api.example.com, 192.168.1.1. Les navigateurs modernes utilisent uniquement le SAN (et ignorent le CN). Let's Encrypt émet par défaut des certificats SAN (domaine + www.domaine). Remplace l'ancien champ Common Name pour les noms alternatifs.