PKI expliquée - Public Key Infrastructure de A à Z

La PKI (Public Key Infrastructure) est l'ensemble des technologies, processus et organisations qui permettent d'utiliser la cryptographie asymétrique à grande échelle, en répondant à la question fondamentale : "comment sait-on à qui appartient cette clé publique ?". Sans PKI, TLS serait impossible, HTTPS n'existerait pas, mTLS ne marcherait pas, le code signing n'aurait aucune valeur. Ce guide couvre la PKI de A à Z : composants, chaîne de confiance, cycle de vie des certificats, révocation (CRL/OCSP), Web PKI et automation ACME, PKI interne enterprise, workload identity SPIFFE, incidents historiques, transition post-quantum.

1. Pourquoi la PKI existe

1.1 Le problème de la cryptographie asymétrique

Voir qu'est-ce que la cryptographie pour le rappel : en asymétrique, chaque partie possède une paire clé privée + clé publique. La clé publique est partageable, la privée reste secrète.

Problème fondamental : quand Alice reçoit une clé publique qui prétend être celle de Bob, comment sait-elle que c'est vraiment celle de Bob ? Un attaquant peut générer sa propre paire et prétendre être Bob.

1.2 Les approches possibles

Trois solutions historiques à ce problème d'authenticité des clés publiques :

• TOFU (Trust On First Use) : on accepte la clé la première fois et on alerte si elle change après. Utilisé par SSH.
• Web of Trust : les utilisateurs signent mutuellement leurs clés. Utilisé par PGP/GPG. Complexe à grande échelle.
• PKI hiérarchique : des autorités de confiance signent les clés. Utilisé par TLS, S/MIME, code signing. Dominante en 2026.

La PKI hiérarchique est devenue le standard de facto parce qu'elle scale : pas besoin que chaque paire d'acteurs se connaisse, seulement que les deux fassent confiance à une autorité commune.

1.3 Définition

Une PKI est un système de rôles, politiques, matériels, logiciels et procédures qui permet de créer, gérer, distribuer, utiliser, stocker et révoquer des certificats numériques, pour gérer la relation entre une identité et sa clé publique.

2. Les composants d'une PKI

2.1 Certificate Authority (CA)

Organisation ou service qui émet des certificats en signant avec sa clé privée.

• Root CA : CA racine, autosignée, au sommet de la hiérarchie. Sa clé privée est l'actif le plus sensible d'une PKI.
• Intermediate CA : signée par un Root CA ou un autre intermediate. Permet la délégation sans exposer la Root CA.
• Issuing CA : intermediate CA qui émet les certificats finaux (leaf certificates).

2.2 Registration Authority (RA)

Fonction qui valide les demandes de certificats avant émission. Peut être intégrée à la CA ou séparée. Gère :

• Validation d'identité (vérification de documents, contrôle du domaine).
• Approbation des demandes.
• Transmission à la CA pour signature.

Dans les CAs modernes (Let's Encrypt), la RA est automatisée via le protocole ACME.

2.3 Certificate (X.509)

Fichier qui lie une clé publique à une identité, signé par une CA.

Contient :

• Version (typiquement v3).
• Serial number unique.
• Signature algorithm (ex. sha256WithRSAEncryption, ecdsa-with-SHA256).
• Issuer (la CA qui a signé).
• Validity (notBefore, notAfter).
• Subject (identité du propriétaire).
• Subject Public Key Info (clé publique + algorithme).
• Extensions : SAN, Key Usage, Extended Key Usage, CRL Distribution Point, Authority Info Access (OCSP), Basic Constraints, SKI/AKI.
• Signature de la CA.

2.4 Certificate Revocation List (CRL)

Liste signée par la CA de tous les certificats révoqués avant leur expiration. Publiée périodiquement (horaires ou quotidien).

Problèmes :

• Taille grandissante (potentiellement des MB).
• Latence de mise à jour (checks en moyenne 1 fois par jour).
• Clients doivent télécharger la CRL régulièrement.

Usage : en décroissance, remplacée progressivement par OCSP.

2.5 OCSP (Online Certificate Status Protocol)

Protocole interactif : le client interroge un serveur OCSP en temps réel pour savoir si un certificat spécifique est révoqué.

• Avantage : réponse en temps réel, taille constante.
• Inconvénients : chaque connexion TLS ajoute une requête OCSP → latence + exposition metadata (CA voit quels sites l'utilisateur visite) → problèmes de confidentialité et disponibilité.

2.6 OCSP Stapling

Solution élégante : le serveur TLS obtient périodiquement une réponse OCSP signée de la CA, et l'inclut dans le handshake TLS. Le client n'a plus à interroger la CA.

• Latence réduite.
• Pas d'exposition metadata.
• Déployé largement depuis 2013+.

2.7 Trust Stores

Liste de CAs root auxquelles un système fait confiance, pré-installée dans :

• Systèmes d'exploitation : Windows Trust Store, macOS Keychain, Linux ca-certificates.
• Navigateurs : Chrome (délégué à OS + sa propre liste), Firefox (liste Mozilla dédiée), Safari.
• Langages : Java cacerts, .NET, Python certifi.

Ces trust stores contiennent 100-200 CAs en moyenne en 2026. Chaque CA de confiance peut émettre des certificats reconnus valides pour n'importe quel domaine internet.

3. La chaîne de confiance

3.1 Principe

Un certificat final (pour api.example.com) est signé par un intermediate CA, qui est lui-même signé par un intermediate supérieur ou un root CA.

Root CA (ISRG Root X1)
  └── Intermediate CA (R10, Let's Encrypt)
        └── Certificate for api.example.com

Pour vérifier le certificat de api.example.com :

1. Le client télécharge le certificat + la chaîne d'intermediates.
2. Il vérifie que la signature du cert final est valide avec la clé publique de l'intermediate.
3. Il vérifie que la signature de l'intermediate est valide avec la clé publique du Root.
4. Il vérifie que le Root CA est dans son trust store.

Si toute la chaîne est valide et que le Root est de confiance, le certificat est accepté.

3.2 Pourquoi des intermediates

• Sécurité : le Root CA est gardé offline, dans un HSM, avec des procédures physiques strictes. Ne signe qu'occasionnellement les intermediates. Si un intermediate est compromis, on révoque et on en émet un nouveau, sans toucher au Root.
• Délégation : un groupe peut avoir son propre intermediate.
• Rotation : intermediates peuvent être rotés (Let's Encrypt a par exemple roté R3 → R10 en 2023).

3.3 Serveurs TLS et chaîne

Règle : le serveur TLS doit présenter la chaîne complète (certificat + intermediates) dans le handshake. Si seul le cert final est envoyé, certains clients ne pourront pas valider.

Outils pour vérifier :

• OpenSSL : openssl s_client -connect api.example.com:443 -showcerts.
• SSL Labs : site web qui analyse la configuration TLS.
• testssl.sh : script de test complet.

4. Cycle de vie d'un certificat

4.1 Les 6 phases

1. Génération de la clé privée et de la CSR par le demandeur.
2. Validation par la RA/CA.
3. Émission : CA signe le certificat.
4. Déploiement : installation sur le serveur / client.
5. Utilisation : TLS handshakes, signatures, etc.
6. Révocation ou expiration : fin de vie.

4.2 Durées de validité en 2026

Tendance à des durées de plus en plus courtes :

• 2000 : 5-10 ans de validité.
• 2015 : 3 ans max imposés par CA/Browser Forum.
• 2018 : 2 ans max.
• 2020 : 13 mois max (398 jours).
• 2024 : discussion pour passer à 90 jours voire 45 jours.
• 2026 : Let's Encrypt 90 jours, tendance vers moins.

Motivation : révocation devient inutile si le cert expire vite. Approche short-lived certificates favorisée par la communauté sécurité.

4.3 Renouvellement

Avant expiration (typiquement 30 jours avant), renouveler :

• Même clé privée : possible mais déconseillé (une fuite passée compromet le nouveau cert).
• Nouvelle clé privée : recommandé, meilleure hygiène.

Automation ACME + cert-manager par défaut : nouvelle clé à chaque renouvellement.

4.4 Révocation

Causes :

• Clé privée compromise.
• Information incorrecte dans le cert.
• Changement de propriétaire du domaine.
• Employé ayant accès parti.
• Subordinate CA compromise (cas lourd).

Mécanismes :

• CRL.
• OCSP / OCSP Stapling.
• Short-lived certs (révocation implicite par expiration rapide).

5. Web PKI - l'écosystème TLS public

5.1 L'histoire en 4 époques

1994-2000 - les débuts : Netscape introduit SSL, Verisign pionnier de la PKI commerciale. Certificats chers (plusieurs centaines de dollars par an), adoption limitée aux grandes orgs.

2000-2015 - la lente croissance : HTTPS progresse lentement. Multiples CAs commerciales (Verisign, Symantec, Comodo, GoDaddy). Problèmes : CAs compromises périodiquement (DigiNotar 2011), transparence zéro.

2015-2020 - la révolution Let's Encrypt : ACME + certificats gratuits + automation → HTTPS passe de 50 % à 80 %+ du web en 5 ans. CAs commerciales en crise.

2020-2026 - la consolidation et la maturité : HTTPS universel (95+ % du web), Certificate Transparency généralisée, short-lived certs, post-quantum prepared.

5.2 Let's Encrypt

Fondée par ISRG (Internet Security Research Group) en 2015, gratuite, automatisée via ACME. En 2026 :

• Émet plus de 400 millions de certificats actifs.
• Couvre environ 50-60 % du web HTTPS mondial.
• Root ISRG Root X1 dans tous les trust stores majeurs.
• Validité 90 jours, renouvellement automatisé.

Impact structurel sur l'écosystème : élimine l'excuse "HTTPS coûte trop cher", oblige le secteur à se réorganiser autour de l'automation.

5.3 Certificate Transparency (CT)

Mise en place de logs publics immuables de tous les certificats émis. Toute CA qui émet un cert doit le soumettre à au moins 2 logs CT.

Bénéfices :

• Détection d'abus : si une CA émet un cert pour google.com sans autorisation, Google le détecte via monitoring CT.
• Transparence : toute personne peut consulter CT pour voir les certs émis pour son domaine.
• Pression sur les CAs : erreurs publiquement auditables.

Chrome a imposé CT en 2018, Firefox et Safari ont suivi. Tous les certs TLS modernes doivent être dans CT.

5.4 CA/Browser Forum

Organisation qui réunit CAs et éditeurs de navigateurs, définit les règles auxquelles les CAs doivent se conformer (Baseline Requirements). Exemples de décisions :

• Interdiction des algorithmes faibles.
• Réduction progressive de la validité.
• Obligation CT.
• Procédures de révocation.

Une CA qui ne respecte pas peut être retirée des trust stores → fin de son business.

5.5 Les incidents marquants de Web PKI

• DigiNotar (2011) : CA hollandaise compromise, émission de certs frauduleux pour google.com utilisés en Iran. DigiNotar retiré de tous les trust stores, faillite.
• Symantec (2017) : CA massive, mauvaises pratiques répétées. Chrome/Firefox ont annoncé le retrait graduel, Symantec a vendu son business à DigiCert.
• WoSign/StartCom (2016) : CAs chinoises avec pratiques douteuses, retirées.
• Camerfirma (2021) : CA espagnole, retirée pour non-conformités multiples.

Leçon : la confiance publique est difficile à gagner, facile à perdre. Le CA/Browser Forum a des dents.

6. Private PKI - PKI interne d'entreprise

6.1 Pourquoi une PKI interne

• Coûts : émettre des millions de certs internes chez CA publique serait cher.
• Privacy : certs internes ne devraient pas transiter par des CAs publiques ni apparaître dans CT logs publics.
• Noms internes : api.internal.example.com ou service.prod.local ne sont pas de vrais domaines publics.
• Politiques custom : validité courte, algorithmes spécifiques, intégration SSO.
• mTLS massif : chaque workload a son cert, millions d'émissions.

6.2 Outils pour opérer une PKI interne

Choix selon contexte :

• Kubernetes, cloud-native : Vault PKI ou step-ca avec cert-manager.
• Windows AD : ADCS naturel (déjà déployé).
• AWS-first : AWS Private CA.
• Petite taille, simplicité : step-ca.

6.3 Intégration avec cert-manager

cert-manager supporte des Issuer multiples : Let's Encrypt (public), Vault, HashiCorp Vault, AWS PCA, smallstep, etc. Un workload K8s peut avoir plusieurs certs émis par différentes sources.

6.4 Trust distribution

Les clients internes doivent faire confiance au Root CA interne :

• Root CA installé dans le trust store des machines managées.
• Workloads K8s : Root CA distribué via ConfigMaps ou DaemonSets.
• Clients mobiles internes : distribué via MDM.
• Pipeline CI : Root CA dans image de base ou Secret.

Sans distribution du Root interne, les clients rejettent les certs internes.

6.5 Root CA offline et HSM

Pour une PKI interne sérieuse :

• Root CA : clé privée générée et stockée dans un HSM (Hardware Security Module) offline. Activée seulement lors des rotations d'intermediates.
• Intermediate CA : clé privée dans HSM online accessible par l'issuing CA.
• Procédures : key ceremonies documentées, multi-control (4 yeux).

Exemples HSM :

• AWS CloudHSM, Azure Dedicated HSM, GCP Cloud HSM.
• YubiHSM 2 : HSM compact pour petites PKIs.
• Thales Luna, Entrust nShield : HSM enterprise.

7. mTLS et workload identity

7.1 mTLS - authentification mutuelle

En mTLS (mutual TLS), serveur ET client présentent des certificats. Chacun vérifie l'autre.

Usage :

• Services backend-to-backend authentifiés de façon forte.
• APIs B2B avec partenaires.
• Accès VPN personnels.

PKI pour mTLS :

• Root CA interne dédié mTLS (peut être commun ou séparé de la PKI TLS publique).
• Intermediate par domaine : workforce, service, IoT.
• Certs clients courts : 1-24 heures pour services, plus longs pour users.

7.2 SPIFFE / SPIRE

SPIFFE (Secure Production Identity Framework For Everyone) est un standard CNCF pour identité workload portable :

• SPIFFE ID : URI spiffe://trust-domain/path qui identifie un workload.
• SVID (SPIFFE Verifiable Identity Document) : certificat X.509 ou JWT qui porte le SPIFFE ID.
• Trust domain : périmètre d'une PKI.

SPIRE est l'implémentation de référence. Architecture :

• SPIRE Server : CA interne, émet les SVIDs courts.
• SPIRE Agent : sur chaque node, demande des SVIDs pour les workloads locaux.
• Attestation : le server vérifie que le workload est bien celui qu'il prétend (via AWS IID, K8s projected token, process attributes).

Bénéfices :

• Identité workload portable multi-cloud.
• Rotation automatique très courte (5-60 min).
• mTLS automatique (Istio, Linkerd peuvent utiliser SPIFFE).
• Standard ouvert.

Adopté par Pinterest, Bloomberg, Uber, ByteDance et beaucoup d'autres.

7.3 Service mesh et PKI

Les service meshes modernes incluent une PKI interne pour mTLS automatique :

• Istio Citadel : CA interne, rotation auto.
• Linkerd : PKI minimaliste avec rotation courte.
• Consul Connect : PKI HashiCorp intégrée.
• Cilium avec mTLS.

Le mesh gère entièrement : émission, rotation, distribution, révocation. Les workloads n'ont rien à faire.

8. Automation PKI - ACME et au-delà

8.1 ACME - Automated Certificate Management Environment

ACME (RFC 8555) est le protocole qui a rendu la PKI opérationnelle à l'échelle :

• Client demande un cert pour example.com.
• Serveur ACME envoie un challenge (HTTP-01, DNS-01, TLS-ALPN-01).
• Client prouve le contrôle du domaine.
• Serveur émet le cert.

Clients ACME modernes : certbot, acme.sh, lego, cert-manager, Caddy, Traefik.

8.2 ACME pour PKI interne

step-ca, Vault PKI, Smallstep acceptent ACME. Conséquence : même workflow automation que Let's Encrypt, mais avec PKI interne. Développeurs ne distinguent pas.

8.3 EST - Enrollment over Secure Transport (RFC 7030)

Alternative à ACME pour PKI enterprise, plus mature en environnements télécoms et IoT.

8.4 Le mouvement short-lived certs

Tendance claire 2024-2026 :

• Certificats TLS publics : vers 45-90 jours.
• Certificats internes : 1-24 heures voire minutes.
• mTLS workload : 5-60 minutes.

Justifications :

• Pas besoin de révocation : expiration rapide = fenêtre d'exploitation limitée.
• Forced rotation : discipline opérationnelle permanente.
• Automation testée en continu : si ça casse, on le voit vite.

Conséquence : la PKI est entièrement logicielle, pas plus un projet IT manuel.

9. PKI post-quantum

9.1 Impact des standards NIST 2024

Les CAs commencent à évaluer l'intégration de :

• ML-DSA (Dilithium, FIPS 204) : signature post-quantum.
• SLH-DSA (SPHINCS+, FIPS 205) : signature hash-based PQ.

Les certificats PQ sont plus grands (plusieurs KB vs 64 octets Ed25519 ou 256 octets ECDSA P-256). Impact sur taille de chaîne, performance handshake.

9.2 Certificats hybrides

Approche de transition :

• Un certificat contient deux clés publiques (classique + PQ).
• Deux signatures (classique + PQ) par la CA.
• Validé comme classique par clients legacy, comme PQ par clients modernes.

Permet une migration sans big bang.

9.3 Timing réaliste

• 2024-2026 : expérimentations chez CAs majeures (Let's Encrypt, DigiCert, Sectigo).
• 2027-2030 : premières émissions en hybride.
• 2030-2035 : transition large alignée sur CNSA 2.0 (NSA) et exigences sectorielles.

Pour la majorité des organisations en 2026 : pas d'action immédiate, mais crypto agility (capacité à changer d'algo) à intégrer dès maintenant.

10. Gouvernance PKI

10.1 CP / CPS - les documents fondateurs

• Certificate Policy (CP) : règles haute niveau de la PKI (qui peut demander des certs, pour quels usages).
• Certification Practice Statement (CPS) : procédures opérationnelles (comment les certs sont émis, validés, révoqués).

Obligatoires pour toute CA publique (CA/Browser Forum). Utiles aussi pour PKI interne sérieuse.

10.2 Audits

• WebTrust for CAs : standard d'audit pour CAs publiques.
• eIDAS : réglementation européenne pour certificats qualifiés.
• Audits SOC 2 : souvent requis pour PKI enterprise.

10.3 Key ceremonies

Pour la génération initiale et la rotation des Root CA :

• Plusieurs participants (4-7 personnes) avec rôles définis (conductor, witness, auditor, operators).
• Script documenté minute par minute.
• Caméras qui enregistrent.
• Preuves : hashes de clés, certificats signés, signatures.

Garantie que personne n'a la Root alone, que la procédure est reproductible et auditable.

11. Pièges fréquents et erreurs classiques

11.1 Chain incomplete

Serveur TLS qui ne présente que le cert final, pas les intermediates. Certains clients (mobiles, Java anciens) ne peuvent pas construire la chaîne eux-mêmes → échec TLS.

Vérifier : openssl s_client -connect host:443 -showcerts doit afficher cert + intermediates.

11.2 Certificat expiré

Incidents récents chez Microsoft Teams (2022), Cisco WebEx, Equifax, Twitter : services down pour quelques heures à cause d'un renouvellement manqué. Mitigation : ACME automation + monitoring expiration + alertes 30 jours avant.

11.3 Root CA leaké ou cassé

Le pire scénario. La clé privée Root circulant = fin de la PKI. Procédures très strictes : HSM offline, backup chiffré, multi-party control.

11.4 Trust store pollué

Utilisateur ou organisation qui ajoute des Root CAs d'éditeurs douteux (DPI d'entreprise, malware) → MITM possible de tout le trafic TLS.

Mitigation : monitoring du trust store, EDR qui détecte ajouts anormaux.

11.5 Rotation Root CA oubliée

Root CA émis pour 20-30 ans. Sa rotation est rare mais critique. Oubli de planification = panique quelques mois avant expiration.

11.6 Révocation pas réellement vérifiée

Clients qui ne vérifient pas CRL/OCSP, ou qui ignorent les erreurs silencieusement. Un cert révoqué continue à fonctionner.

Mitigation : short-lived certs (rend la révocation moins critique), OCSP Stapling strict côté serveur.

11.7 PKI interne sans documentation

Root CA créée il y a 10 ans, personne ne sait qui a la clé, pas de procédure de rotation, pas de CPS. Mitigation : formalisation dès le début, même pour PKI modeste.

12. Checklist PKI

Pour une PKI publique TLS (web)

• ACME automation via certbot/cert-manager/Caddy
• Let's Encrypt ou DigiCert pour les certs
• Courte durée de validité (90 jours ou moins)
• Nouvelle clé privée à chaque renouvellement
• Chaîne complète présentée par le serveur
• OCSP Stapling configuré
• Monitoring d'expiration avec alertes 30j et 7j
• Certificate Transparency monitoring pour son domaine

Pour une PKI interne

• Outil moderne (step-ca, Vault PKI, AWS PCA, Azure, GCP)
• Root CA offline avec HSM
• Intermediate CA online dans HSM ou KMS
• Key ceremony documentée pour la Root
• CPS écrite et à jour
• ACME ou API moderne pour émission
• Short-lived certs (24h max pour workloads)
• Distribution automatique du Root CA aux clients

Pour mTLS / workload identity

• SPIFFE/SPIRE, Istio, Linkerd ou équivalent
• Rotation ultra-courte (5-60 min)
• Service mesh qui gère émission et rotation
• Mutual verification obligatoire

Gouvernance

• Inventaire de tous les certs actifs
• Ownership par cert
• Process de révocation testé
• Exercice de rotation Root planifié
• Audit annuel de la PKI
• Plan post-quantum avec crypto agility

13. Verdict et posture Zeroday

La PKI n'est pas un sujet parmi d'autres en cybersécurité : c'est l'infrastructure qui porte la confiance dans tout l'écosystème crypto moderne. Sans PKI solide, TLS, mTLS, signatures, code signing, e-ID s'effondrent. Sa particularité : elle est largement invisible quand elle marche, catastrophiquement visible quand elle casse.

Pour un développeur : comprendre la chaîne de confiance, savoir décoder un certificat, vérifier une chaîne TLS, et pourquoi la rotation courte est préférable. Ces compétences sont applicables tous les jours dans les interactions avec HTTPS, mTLS, code signing.

Pour un AppSec ou DevSecOps : la PKI est un sujet qui paraît simple et s'avère profond. Les certs expirés, les chaînes incomplètes, les Root CAs mal protégés sont des incidents réguliers qui coûtent cher. L'investissement dans une PKI automatisée (ACME everywhere, cert-manager, rotation courte) rapporte durablement.

Pour une organisation : standardiser sur un outil PKI (step-ca, Vault PKI, cert-manager) et automatiser complètement l'émission et la rotation est l'investissement qui élimine 90 % des incidents TLS en production.

Pour approfondir : qu'est-ce qu'une CSR pour la brique de demande de cert, différence hash/HMAC/signature pour les signatures qui sous-tendent les certs, qu'est-ce que la cryptographie pour le contexte crypto général, sécurité REST : les bases pour l'articulation TLS côté API, service accounts : risques et bonnes pratiques pour la workload identity qui s'appuie sur la PKI.