PKI - Public Key Infrastructure et certificats 2026

La PKI (Public Key Infrastructure) est l'infrastructure cryptographique qui gère le cycle de vie complet des certificats numériques X.509 (RFC 5280) : émission, stockage, renouvellement, révocation, validation. C'est la fondation invisible de la confiance numérique moderne, chaque connexion HTTPS, chaque mTLS service-to-service, chaque code signature, chaque VPN client repose sur la PKI. En 2026, l'écosystème PKI vit deux ruptures structurantes : (1) Post-Quantum Cryptography (PQC) avec la publication par NIST le 13 août 2024 des trois standards finaux, FIPS 203 ML-KEM (CRYSTALS-Kyber), FIPS 204 ML-DSA (CRYSTALS-Dilithium), FIPS 205 SLH-DSA (SPHINCS+), qui imposent une migration crypto sur 5-15 ans selon le secteur, mandatory pour systèmes US National Security en 2035 par NSA CNSA 2.0 ; (2) Distrust progressive d'Entrust annoncée par Mozilla et Google en juin 2024, affectant ~30 000 certificats et démontrant la fragilité de la confiance dans les CAs publiques. Côté tooling, l'ACME (Automated Certificate Management Environment, RFC 8555 mars 2019) avec Let's Encrypt (5+ milliards de certificats émis depuis décembre 2015) est devenu le standard de fait pour Web PKI, et cert-manager (CNCF Graduated 2024) domine pour Kubernetes. Pour Private PKI : HashiCorp Vault PKI (IBM acquisition 2024), Smallstep step-ca, AWS Private CA, EJBCA (PrimeKey/Keyfactor depuis 2003), Microsoft AD CS. Comprendre la hiérarchie CA, les standards X.509 et ACME, l'automation moderne, la migration PQC, et les leçons distrust Entrust est non-négociable pour tout architecte sécurité 2026.

Pour le contexte adjacent : voir IAM - Identity and Access Management pour la couche identity dans laquelle les certificats client jouent un rôle, et Zero Trust - Architecture et ZTNA pour la stratégie qui repose largement sur mTLS pervasif.

1. Anatomie X.509 et hiérarchie CA

Un certificat X.509 (standard ITU-T, profile IETF RFC 5280) contient les champs suivants :

Hiérarchie CA typique :

[Root CA]                    ← Self-signed, offline, 20-30 ans validity
   │
   ├── [Intermediate CA #1]   ← Signed by Root, online, 5-10 ans validity
   │      │
   │      ├── [Leaf cert example.com]   ← 90 jours typique 2026
   │      ├── [Leaf cert api.example.com]
   │      └── [Leaf cert *.example.com]
   │
   └── [Intermediate CA #2]   ← Disaster recovery + algorithm migration
          │
          └── [Leaf certs ECDSA P-256]

Position tranchée 2026 : architecturer une PKI à 3 niveaux minimum (Root offline + Intermediate online + Leaves), jamais signer directement avec le Root. Préparer 2 Intermediates pour la migration PQC (un RSA classique, un ML-DSA quantum-resistant) en 2026-2030.

2. Web PKI - CA/Browser Forum et Root Programs 2026

La Web PKI est gouvernée par trois entités :

Leaders Web PKI 2026 :

2.1 L'incident structurant 2024 - Distrust Entrust

Juin 2024 : Mozilla et Google ont annoncé la distrust progressive d'Entrust suite à 6+ ans de manquements aux Baseline Requirements du CA/Browser Forum (mauvaise gestion des incidents, retards de révocation, communication insuffisante avec la communauté). Chronologie :

Leçons 2026 : (1) la confiance des CAs publiques n'est pas garantie, toujours plan de migration cross-CA, (2) les Baseline Requirements CA/Browser Forum sont strictes et le non-respect = risque existentiel, (3) multi-CA strategy avec ACME automation permet de re-émettre rapidement avec un autre CA en cas de distrust.

3. ACME (RFC 8555) - le standard d'automation 2026

ACME (Automated Certificate Management Environment) est le protocole standardisé par IETF RFC 8555 publié en mars 2019 qui automatise l'émission, le renouvellement et la révocation de certificats. Adopté massivement après son introduction par Let's Encrypt lancé en décembre 2015 par ISRG (Internet Security Research Group).

3.1 Adoption Let's Encrypt 2015-2026

3.2 Validity 90 jours - choix structurant

Let's Encrypt a imposé dès le départ une validity de 90 jours (vs 1-2 ans des CAs traditionnelles 2015). Justifications :

1. Limite l'impact d'une compromission de clé privée.
2. Force l'automation, impossible de renouveler manuellement 4 fois par an à grande échelle.
3. Encourage la crypto-agility, rotation rapide pour migration algos.

En mars 2023, le CA/Browser Forum a voté la réduction progressive de la validity maximale Web PKI :

Position tranchée 2026 : adopter 90 jours validity dès maintenant + automation ACME pure sur tous les certs. Tout cert > 90 jours est de la dette technique anticipée.

3.3 Clients ACME 2026

4. Private PKI - leaders 2026

Position tranchée 2026 : pour Kubernetes + microservices → cert-manager + HashiCorp Vault PKI ou Smallstep step-ca. Pour AWS-centric → AWS Private CA (managé, intégration ACM + Route53). Pour Windows enterprise → AD CS reste le défaut malgré son âge. Pour gov/banking avec FIPS / Common Criteria → EJBCA (PrimeKey/Keyfactor).

5. Post-Quantum Cryptography - migration critique 2024-2035

5.1 NIST PQC Standards finaux août 2024

Le 13 août 2024, NIST a publié les 3 premiers standards finaux post-quantum après 8 ans de processus PQC standardization (lancé 2016) :

FIPS 206 FN-DSA (Falcon, signature compacte) reste en standardisation, attendu fin 2025-2026.

5.2 Pourquoi maintenant et pas plus tard

Risque structurel : un cryptographically-relevant quantum computer (CRQC) capable de casser RSA-2048 ou ECDSA P-256 via algorithme de Shor n'existe pas en 2026, mais NIST estime son apparition entre 2030 et 2040. Trois implications :

1. « Harvest now, decrypt later » : un attaquant collecte aujourd'hui le trafic chiffré (exfiltration TLS, dumps CDN) et le décrypte quand le quantum computer existera. Pour données à long-shelf-life (medical records, gov classified, IP secrets), c'est une menace immédiate.
2. Migration crypto : remplacer les algos dans une infrastructure massive (Web PKI, OS, libraries, hardware) prend 5-15 ans.
3. NSA CNSA 2.0 : mandate l'adoption PQC pour systèmes US National Security d'ici 2035.

5.3 Adoption 2024-2026

Position tranchée 2026 : pour 80 % des organisations, ne pas paniquer maintenant sur PQC mais commencer la crypto-agility :

1. Inventaire crypto (CBOM CycloneDX 1.6), où est utilisé RSA, ECDSA, Diffie-Hellman ?
2. Test certificats hybrides Kyber+ECDSA en pre-prod via OpenSSL 3.4+ ou BoringSSL.
3. Automation ACME pour rotation rapide quand PQC sera mainstream.
4. Éviter clés long-lived > 2 ans, elles devront être migrées.
5. Banking, gov, defense : démarrer la migration maintenant (CNSA 2.0 deadline 2035).

6. Stack outillage PKI 2026

6.1 Setup Smallstep step-ca + ACME pour mTLS Kubernetes

# 1. Install step CLI + step-ca
brew install step  # macOS
# OR
curl -sLO https://github.com/smallstep/cli/releases/latest/download/step_linux_amd64.tar.gz
 
# 2. Bootstrap private CA avec ACME provisioner
step ca init \
  --name "Internal CA - Acme Corp" \
  --dns "ca.acme.internal" \
  --address ":443" \
  --provisioner "acme@acme.internal" \
  --provisioner-type ACME
 
# 3. Démarrer step-ca
step-ca $(step path)/config/ca.json
 
# 4. Sur les services qui ont besoin de certs, install cert-manager
helm repo add jetstack https://charts.jetstack.io
helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager --create-namespace \
  --set installCRDs=true \
  --version v1.16.0
 
# 5. Créer ClusterIssuer avec ACME pointing vers step-ca
cat <<EOF | kubectl apply -f -
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: stepca-issuer
spec:
  acme:
    server: https://ca.acme.internal/acme/acme/directory
    email: devops@acme.internal
    privateKeySecretRef:
      name: stepca-issuer-account-key
    solvers:
      - http01:
          ingress:
            class: nginx
EOF
 
# 6. Demander un cert pour un service
cat <<EOF | kubectl apply -f -
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: api-tls-cert
  namespace: production
spec:
  secretName: api-tls
  duration: 24h        # Short-lived !
  renewBefore: 8h
  subject:
    organizations: [Acme Corp]
  privateKey:
    algorithm: ECDSA
    size: 256
  dnsNames:
    - api.acme.internal
    - api-internal.acme.svc.cluster.local
  issuerRef:
    name: stepca-issuer
    kind: ClusterIssuer
EOF

Ce setup donne mTLS pervasif dans Kubernetes avec certs 24h validity auto-renouvelés. C'est l'archétype PKI moderne 2026.

6.2 Configuration HashiCorp Vault PKI dynamic secrets

# 1. Activer le secret engine PKI
vault secrets enable -path=pki pki
 
# 2. Configurer max TTL (Root CA validity)
vault secrets tune -max-lease-ttl=87600h pki  # 10 ans
 
# 3. Générer Root CA
vault write -field=certificate pki/root/generate/internal \
  common_name="Acme Root CA" \
  ttl=87600h > root_ca.crt
 
# 4. Configurer URLs pour AIA + CRL
vault write pki/config/urls \
  issuing_certificates="https://vault.acme.internal/v1/pki/ca" \
  crl_distribution_points="https://vault.acme.internal/v1/pki/crl"
 
# 5. Activer Intermediate CA
vault secrets enable -path=pki_int pki
vault secrets tune -max-lease-ttl=43800h pki_int  # 5 ans
 
# 6. Créer un role pour mTLS service-to-service avec TTL court
vault write pki_int/roles/microservice-mtls \
  allowed_domains="acme.internal" \
  allow_subdomains=true \
  max_ttl="24h" \
  ttl="1h" \
  key_type="ec" \
  key_bits=256
 
# 7. Demander un cert (depuis un service applicatif)
vault write pki_int/issue/microservice-mtls \
  common_name="api.acme.internal" \
  ttl="1h"
# Returns: certificate, private_key, ca_chain, tout pour mTLS

7. Erreurs fréquentes PKI et anti-patterns

8. ROI mesurable et tarification 2026

ROI typique d'un programme PKI mature 2026 :

Tarification 2026 ordre de grandeur :

9. Mapping PKI vers compliance frameworks 2026

10. Pour aller plus loin

• IAM - Identity and Access Management, la couche identity dans laquelle les certs client jouent un rôle.
• Zero Trust - Architecture et ZTNA, stratégie qui repose largement sur mTLS pervasif.
• RBAC - Role-Based Access Control, modèle d'autorisation post-authentication.
• ABAC - Attribute-Based Access Control, autorisation contextuelle.
• EDR - Endpoint Detection and Response, détection des compromissions de clés/certs.
• Bootcamp DevSecOps, formation 12 semaines couvrant PKI, mTLS, ACME.
• Hub catégorie Glossaire cyber, autres définitions de référence Zeroday.
• RFC 5280 (X.509 PKI Profile) : https://datatracker.ietf.org/doc/html/rfc5280.
• RFC 8555 (ACME) : https://datatracker.ietf.org/doc/html/rfc8555.
• NIST FIPS 203/204/205 (PQC, août 2024) : https://csrc.nist.gov/projects/post-quantum-cryptography.
• CA/Browser Forum Baseline Requirements : https://cabforum.org/baseline-requirements-documents/.
• Let's Encrypt : https://letsencrypt.org/.
• Mozilla CA Program : https://wiki.mozilla.org/CA.
• HashiCorp Vault PKI : https://developer.hashicorp.com/vault/docs/secrets/pki.
• Smallstep step-ca : https://smallstep.com/docs/step-ca/.
• cert-manager (CNCF) : https://cert-manager.io/.
• Cloudflare PQC TLS rollout 2024 : https://blog.cloudflare.com/pq-2024/.
• Distrust Entrust Mozilla 2024 : https://blog.mozilla.org/security/2024/06/27/distrusting-entrust-tls-certificates/.

11. Points clés à retenir

• PKI = infrastructure cryptographique gérant le cycle de vie des certificats X.509 (RFC 5280). Fondation invisible HTTPS, mTLS, code signing, VPN.
• Web PKI vs Private PKI : Web PKI = CAs publiques (Let's Encrypt, DigiCert, Sectigo) ; Private PKI = CA interne (Vault, Smallstep, AWS PCA, EJBCA, AD CS).
• CA/Browser Forum + Mozilla CA Program + Apple/Microsoft Root Programs gouvernent la confiance Web PKI.
• Distrust Entrust annoncée par Mozilla et Google en juin 2024 : Chrome cesse de trust certs Entrust émis après 31 octobre 2024. ~30 000 certs affectés. Leçon : multi-CA strategy obligatoire.
• Let's Encrypt (ISRG, lancé décembre 2015) : 5+ milliards de certs émis, ~50-60 % du Web HTTPS public 2026.
• ACME (RFC 8555 mars 2019) = standard d'automation. Clients : certbot, acme.sh, Caddy, Traefik, cert-manager (CNCF Graduated 2024), lego, win-acme.
• CA/Browser Forum réduit progressivement la validity max Web PKI : 825j (2018) → 398j (2020) → 200j proposé septembre 2025 → 90j à terme.
• NIST FIPS 203/204/205 publiés finaux le 13 août 2024 : ML-KEM (Kyber), ML-DSA (Dilithium), SLH-DSA (SPHINCS+). Migration PQC critique 2024-2035.
• NSA CNSA 2.0 mandate l'adoption PQC pour systèmes US National Security d'ici 2035.
• « Harvest now, decrypt later » = menace immédiate pour données long-shelf-life. Démarrer crypto-agility maintenant.
• Cloudflare active X25519+Kyber768 hybride sur tous serveurs en mars 2024. Chrome 124 par défaut en avril 2024.
• Leaders Private PKI 2026 : HashiCorp Vault PKI (IBM acquisition 2024), Smallstep step-ca, AWS Private CA (360 €/mois/CA), EJBCA (PrimeKey/Keyfactor depuis 2003), Microsoft AD CS.
• Anti-pattern n°1 : certs > 90 jours validity sans automation. Outages garantis, crypto-agility nulle.
• Anti-pattern n°2 : mono-CA dependency. Distrust Entrust 2024 a montré la fragilité.
• Compliance : PKI mappe NIST FIPS 203/204/205, NIST SP 800-57 + 800-131A, PCI-DSS v4.0 Req 4, NIS2 article 21, DORA article 9, ISO 27001:2022 A.8.24, eIDAS 2.0, CA/B Forum Baseline Requirements, Common Criteria EAL4+.