Qu'est-ce qu'un certificat TLS en 2026 ? Guide complet

Un certificat TLS est un document numérique signé cryptographiquement par une autorité de certification (Certificate Authority, CA) qui prouve l'identité d'un domaine ou d'une entité auprès de ses interlocuteurs. Il permet à un navigateur ou client de vérifier qu'il communique bien avec le serveur prétendu (par exemple : api.example.test est bien le serveur d'Acme SAS), pas avec un attaquant qui intercepterait le trafic. Standardisé par RFC 5280 (X.509), il contient la clé publique du serveur, son identité (Subject), l'identité de la CA émettrice (Issuer), une période de validité, des extensions précisant les usages autorisés. En 2026, l'écosystème est dominé par Let's Encrypt (Internet Security Research Group, gratuit avec automation ACME, 350+ millions de certificats actifs), suivi par les CA commerciales (DigiCert, GlobalSign, Sectigo, GoDaddy) et les solutions cloud-managed (AWS Certificate Manager, Azure Key Vault Certificates, Google-managed SSL). La validité maximale standardisée diminue progressivement (398 jours actuellement → 200 jours mars 2026 → 100 jours mars 2027 → 47 jours mars 2029, décision CA/Browser Forum d'avril 2025), rendant l'automation ACME obligatoire. Cet article détaille la structure d'un certificat X.509, les types (DV/OV/EV/wildcard/SAN), la chaîne de confiance, les CA majeures 2026, le cycle de vie complet (CSR → émission → déploiement → renouvellement → révocation), la validation côté client (OCSP, CRL, OCSP stapling, Certificate Transparency), mTLS pour authentification client, l'automation 2026 obligatoire, les premières expérimentations post-quantum et les pièges fréquents.

Définition et rôle

Un certificat TLS prouve cryptographiquement à un client (navigateur, application) qu'il communique bien avec le serveur attendu. Sans certificat valide, le client ne peut pas distinguer le vrai serveur d'un attaquant qui intercepterait le trafic.

Trois fonctions essentielles

Sans certificat valide, que se passe-t-il ?

Le navigateur affiche une erreur bloquante (Chrome NET::ERR_CERT_AUTHORITY_INVALID, Firefox SEC_ERROR_UNKNOWN_ISSUER) qui empêche la connexion. Depuis 2017 avec Chrome 56, le navigateur marque "Not Secure" tout site HTTP non chiffré. La part de trafic HTTPS dépasse 95 % en 2026 selon les statistiques Cloudflare et HTTP Archive.

Structure d'un certificat X.509

Un certificat X.509 (standard ITU-T) est un fichier binaire (DER) ou texte base64 (PEM) avec une structure normalisée. Inspectable via openssl x509 -in cert.pem -text.

Champs principaux

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            04:af:5b:c2:e3:d1:90:8a:b1:23:c4:d5:e6:f7:89:00
        Signature Algorithm: ecdsa-with-SHA384
        Issuer: C=US, O=Let's Encrypt, CN=R10
        Validity
            Not Before: Jan 15 10:00:00 2026 GMT
            Not After : Apr 15 10:00:00 2026 GMT
        Subject: CN=api.example.test
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:9f:8e:7d:6c:5b:4a:39:28:17:06:f5:e4:d3:c2:
                    b1:a0:9f:8e:7d:6c:5b:4a:39:28:17:06:f5:e4:d3:
                    c2:b1:a0:9f:8e:7d:6c:5b:4a:39:28:17:06:f5:e4
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                DNS:api.example.test, DNS:www.api.example.test
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier:
                A1:B2:C3:D4:E5:F6:78:90:12:34:56:78:9A:BC:DE:F0:11:22:33:44
            X509v3 Authority Key Identifier:
                keyid:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88
            Authority Information Access:
                OCSP - URI:http://r10.o.lencr.org
                CA Issuers - URI:http://r10.i.lencr.org/
            X509v3 CRL Distribution Points:
                Full Name: URI:http://r10.c.lencr.org/96.crl
            CT Precertificate SCTs:
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : ...
                    Timestamp : Jan 15 10:00:30.123 2026 GMT
    Signature Algorithm: ecdsa-with-SHA384
         30:65:02:30:7c:b8:9a:5d:fe:23:14:c7:01:65:8f:...

Champs critiques expliqués

Depuis 2017, le champ CN (Common Name) seul est déprécié. Tous les domaines couverts doivent être listés dans Subject Alternative Name (SAN). Les navigateurs ignorent CN en présence de SAN.

Types de certificats par validation

Trois niveaux de validation, dépendant du processus que la CA suit pour émettre.

DV (Domain Validation) — 95 % des cas 2026

La CA vérifie uniquement que le demandeur contrôle le domaine, par challenge automatisé :

• HTTP-01 challenge : la CA demande de placer un fichier précis sous http://example.test/.well-known/acme-challenge/<token>.
• DNS-01 challenge : la CA demande d'ajouter un TXT record DNS spécifique.
• TLS-ALPN-01 challenge : variante moins courante.

Émission immédiate (secondes à minutes), gratuit avec Let's Encrypt et la majorité des CA modernes. Suffisant pour 95 % des cas (HTTPS standard, e-commerce, SaaS).

OV (Organization Validation) — 4 % des cas 2026

La CA vérifie en plus l'identité de l'organisation : extrait Kbis ou équivalent, contact téléphonique du dirigeant, adresse vérifiée. Processus 1-5 jours. Émission payante : 50-300 € par an selon CA.

Le nom de l'organisation apparaît dans les détails du certificat (rarement consulté par utilisateurs). Pertinent pour intégrations B2B avec exigence contractuelle d'OV.

EV (Extended Validation) — 1 % des cas 2026

Validation rigoureuse de l'identité légale (présence physique, vérification documents légaux multiples, conformité audit Webtrust). Processus 1-3 semaines. Émission payante : 200-1000 € par an.

Historiquement, EV affichait le nom de l'entreprise dans une barre verte dans le navigateur (Chrome 1-78, Safari avant 2019, Firefox avant 2019). Cette UI a été supprimée par Chrome (2019) et Safari (2019) car études comportementales montraient que les utilisateurs n'y prêtaient pas attention. Suppression de la barre verte = chute drastique de la demande EV.

EV reste demandé en 2026 par : banques, institutions financières (PSD2 contexte), e-commerce sensible, certains contrats B2B exigeants.

Types par couverture de domaines

Wildcards demandent typiquement DNS-01 challenge (HTTP-01 ne fonctionne pas pour wildcards). Plus risqués (compromission = tous les sous-domaines exposés), à utiliser uniquement quand justifié.

Chain of trust

Un certificat TLS n'est pas signé directement par la CA racine. Chaîne de confiance type :

┌──────────────────────────────────────┐
│ Root CA (auto-signée, dans navigateur)│
│ Exemple : ISRG Root X1 (Let's Encrypt)│
│ Validité : 20-30 ans                 │
│ Algorithme : RSA-4096 ou ECDSA P-384 │
└──────────────────────────────────────┘
                  │ signe
                  ▼
┌──────────────────────────────────────┐
│ Intermediate CA                       │
│ Exemple : Let's Encrypt R10 ou R11   │
│ Validité : 5-10 ans                  │
│ Algorithme : ECDSA P-256             │
└──────────────────────────────────────┘
                  │ signe
                  ▼
┌──────────────────────────────────────┐
│ Leaf certificate (votre serveur)      │
│ Exemple : api.example.test           │
│ Validité : 47-90 jours (Let's Encrypt)│
│ Algorithme : ECDSA P-256             │
└──────────────────────────────────────┘

Pourquoi cette chaîne ?

• Sécurité root : la clé privée Root CA est extrêmement protégée (HSM offline, cérémonie de signature physique). Compromettre Root = catastrophe industrielle.
• Flexibilité : Intermediate CAs peuvent être révoquées sans tuer la Root. Permet rotation, séparation par usage.
• Performance : seul l'Intermediate est en ligne pour signer les milliers de certificats par jour.

Validation côté client

Le client (navigateur, OS) embarque une trust store avec les Root CAs de confiance (Mozilla, Microsoft, Apple, Chrome maintiennent leurs trust stores).

Quand le serveur présente son certificat lors du TLS handshake :

1. Le serveur envoie son leaf certificate + chaîne intermédiaire.
2. Le client vérifie chaque signature de la chaîne jusqu'à arriver à un Root CA présent dans sa trust store.
3. Si la chaîne est valide ET le leaf certificate est dans sa période de validité ET pas révoqué, la connexion est acceptée.

Autorités de certification (CA) en 2026

L'écosystème CA en 2026 est dominé par quelques acteurs clés.

CA gratuites

CA commerciales

CA cloud managed

Évolution du marché 2024-2026

Mouvement de fond : DV gratuit (Let's Encrypt) capture la majorité du marché de masse. CA commerciales se replient sur OV/EV pour grands comptes et marchés réglementés. Cloud managed prend la part technique des organisations cloud-native.

Acquisition récente : DigiCert acquis CertCentral, QuoVadis 2019, Mocana 2022. Sectigo acquis SSL.com 2024. Consolidation continue.

Let's Encrypt et ACME

Let's Encrypt (lancement avril 2016, opéré par Internet Security Research Group) est l'événement le plus marquant de l'écosystème TLS depuis 10 ans.

Caractéristiques principales

• Gratuit : zéro coût, financé par sponsors (Mozilla, EFF, Cisco, Akamai, Cloudflare, Facebook, etc.).
• Automation native : protocole ACME (RFC 8555) pour émission/renouvellement programmatique.
• Validité courte : 90 jours par défaut (vs 1-2 ans CA traditionnelles).
• Multi-domaine SAN : jusqu'à 100 SAN par certificat.
• Wildcard supporté depuis mars 2018.
• DV uniquement : pas de OV ni EV, par design (gratuit + automation impossible avec validation manuelle).

Volume 2026

• 350+ millions de certificats actifs servis par Let's Encrypt en 2026.
• 300+ millions de domaines uniques.
• Plus de 5 milliards de certificats émis cumulés depuis 2016.

Protocole ACME

ACME (Automatic Certificate Management Environment, RFC 8555) automatise tout le cycle de vie certificat.

# Exemple : émission Let's Encrypt via certbot (EFF)
sudo certbot --nginx -d api.example.test -d www.example.test \
  --email admin@example.test \
  --agree-tos \
  --non-interactive
 
# Sous le capot, certbot :
# 1. Génère paire de clés ECDSA P-256 (ou RSA 2048)
# 2. Crée un Certificate Signing Request (CSR)
# 3. Communique avec Let's Encrypt via ACME
# 4. Répond au challenge HTTP-01 (placement fichier sous /.well-known/acme-challenge/)
# 5. Récupère le certificat émis
# 6. L'installe dans nginx, configure auto-renewal
# 7. Renew automatique avant expiration (cron systemd timer)

Clients ACME populaires

Limitations Let's Encrypt

• Rate limits : 50 certificats par domaine enregistré par semaine, 300 nouvelles commandes par 3 heures par compte. Suffisant pour la majorité, contraignant pour très grandes organisations multi-domaines.
• Pas d'OV/EV : si OV/EV requis, utiliser CA commerciale.
• Validité 90 jours : nécessite automation (devient 47 jours en 2029, encore plus crucial).

Validité courte : 47 jours en 2029

Le CA/Browser Forum a voté en avril 2025 une réduction progressive de la validité maximale des certificats TLS publics.

Calendrier

Pourquoi cette réduction ?

• Sécurité : réduction de la fenêtre d'exploitation en cas de compromission de clé.
• Discipline : force l'automation, élimine les processus manuels (sources de bugs et oublis).
• Agilité : permet rotation algorithmes plus rapide (transition PQ par exemple).

Impact pratique

Pour les équipes ops :

• Avant 2026 : possible de gérer manuellement 100 certificats avec renouvellement annuel.
• 2026-2027 : automation devient indispensable (200 puis 100 jours).
• 2029+ : sans automation, impossible. Tout cycle de vie via ACME ou solutions cloud-managed.

Conséquence : montée en charge des plateformes ACME, des outils Caddy/Traefik avec auto-HTTPS, des services cloud-managed (AWS ACM, Azure App Service Managed Cert, Google-managed SSL).

Validation côté client

Comment le navigateur ou client TLS vérifie la révocation d'un certificat ?

CRL (Certificate Revocation List)

Liste signée par la CA des certificats révoqués. Le client la télécharge périodiquement et vérifie si le certificat reçu y figure.

Limites :

• Liste massive (centaines de Mo pour grandes CA).
• Latence (mise à jour quotidienne typique).
• Performances dégradées.

CRL principalement utilisé pour les certificats internes ou OV/EV. Largement déprécié pour DV publics.

OCSP (Online Certificate Status Protocol)

RFC 6960. Le client interroge l'OCSP responder de la CA en temps réel : "le certificat avec serial X est-il révoqué ?".

# Vérification OCSP manuelle
openssl ocsp -issuer ca-cert.pem -cert leaf-cert.pem \
  -url http://r10.o.lencr.org -CAfile ca-cert.pem

Limites :

• Privacy : la CA voit quels sites le client visite.
• Performance : ajout de latence à chaque connexion HTTPS.
• Disponibilité : si OCSP responder down, soft-fail (le navigateur ignore et accepte).

OCSP Stapling

Solution moderne aux limites d'OCSP. Le serveur Web pré-récupère la réponse OCSP signée et la présente lui-même au client lors du handshake TLS. Le client n'a pas besoin de contacter la CA.

# Nginx avec OCSP stapling activé
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/nginx/ssl/ca-bundle.pem;
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;

OCSP stapling = privacy préservée, performance améliorée, disponibilité indépendante de l'OCSP responder. Pratique recommandée 2026.

OCSP Must-Staple

Extension X.509 qui force le client à exiger OCSP stapling. Si le serveur ne peut pas fournir une réponse OCSP fraîche, le client refuse la connexion.

Sécurité maximale : empêche un attaquant ayant compromis la clé privée d'utiliser le certificat révoqué (l'OCSP stapling fraîche prouve la non-révocation au moment exact). Adoption faible (10-15 % des sites en 2026) car risque opérationnel si OCSP responder de la CA down.

Certificate Transparency (CT)

RFC 6962. Tous les certificats publics doivent être inscrits dans des CT logs publics (append-only logs cryptographiquement vérifiables). Cela permet de détecter les certificats émis frauduleusement (par CA compromise, ou émission accidentelle).

CT obligatoire dans Chrome depuis avril 2018 et Apple Safari depuis octobre 2018 pour tous les certificats émis. Un certificat sans Signed Certificate Timestamp (SCT) prouvant l'inscription CT est rejeté.

Outils pour surveiller CT logs :

• crt.sh (Comodo / Sectigo) : recherche publique CT logs.
• CertSpotter (SSLMate) : monitoring d'émission certificats sur vos domaines.
• Cert-Manager Cloudflare : surveillance via API.

Détection d'un certificat émis frauduleusement (par CA compromise) en heures grâce à CT.

mTLS et certificats client

Mutual TLS : le client présente aussi un certificat lors du handshake. Authentification cryptographique forte côté client.

Cas d'usage mTLS

• Microservices internes : authentification service-to-service via service mesh (Istio, Linkerd auto-mTLS).
• B2B critique : open banking PSD2, FAPI 2.0, échanges entre banques.
• IoT : authentification de devices connectés.
• VPN / Zero Trust Network Access : authentification utilisateur via certificat client.

Configuration Nginx mTLS

server {
    listen 443 ssl http2;
    server_name api.example.test;
    
    # Certificat serveur classique
    ssl_certificate /etc/nginx/ssl/server.crt;
    ssl_certificate_key /etc/nginx/ssl/server.key;
    
    # Configuration mTLS : exiger client cert
    ssl_client_certificate /etc/nginx/ssl/ca-clients.crt;
    ssl_verify_client on;
    ssl_verify_depth 2;
    
    location / {
        proxy_pass http://backend:8080;
        # Transmettre les infos du cert client au backend
        proxy_set_header X-Client-Cert-Subject $ssl_client_s_dn;
        proxy_set_header X-Client-Cert-Verify $ssl_client_verify;
        proxy_set_header X-Client-Cert-Fingerprint $ssl_client_fingerprint;
    }
}

CA d'entreprise pour mTLS

Pour mTLS interne, gérer sa propre CA d'entreprise (Private CA) :

• HashiCorp Vault PKI engine : Vault peut être CA d'entreprise complet.
• Smallstep step-ca : CA open source légère.
• AWS Private CA : managed.
• Cloudflare PKI : managed.

Pas besoin d'utiliser une CA publique pour mTLS interne, économie et contrôle complet.

Outils et automation 2026

Stack moderne pour gérer les certificats TLS sans friction.

Pour serveur web standard

• Caddy : serveur web Go avec auto-HTTPS via ACME. Zéro configuration. Recommandé 2026 pour nouveaux projets.
• Traefik : reverse proxy avec auto-HTTPS via ACME. Excellent K8s-native.
• Nginx + certbot : pattern legacy mais robuste. Largement déployé.
• Apache + mod_md : ACME natif depuis Apache 2.4.30.

Pour cloud workloads

• AWS Certificate Manager (ACM) : gratuit pour ALB/CloudFront/API Gateway. Renouvellement transparent.
• Azure App Service Managed Certificates : gratuit pour App Service.
• Google-managed SSL certificates : gratuit pour Google Cloud Load Balancer.
• Cloudflare Universal SSL : gratuit pour tous sites derrière Cloudflare.

Pour Kubernetes

• cert-manager : opérateur Kubernetes pour automation ACME et émission via CA managées. Standard de facto 2026.
• Istio CA : pour mTLS service mesh, intégré.
• Linkerd identity : équivalent Linkerd.

Pour CA d'entreprise (Private CA)

• HashiCorp Vault PKI engine : référence open source.
• Smallstep step-ca : alternative légère, easy to deploy.
• AWS Private CA : managed AWS.
• EJBCA : enterprise complet, complexe.

Pour développement local

• mkcert : génère certificat Local CA + leaf cert pour localhost ou domaines custom. Indispensable pour HTTPS local sans warning navigateur.

# mkcert : setup local HTTPS development
brew install mkcert
mkcert -install
mkcert localhost api.local *.example.local
 
# Génère localhost+3.pem et localhost+3-key.pem
# Trust automatique du Local CA dans navigateurs et OS

Cycle de vie d'un certificat

Schéma complet du cycle de vie en 2026.

┌────────────────────────────────────────────────────┐
│ 1. GÉNÉRATION CSR                                   │
│ - Génération paire clés (ECDSA P-256 ou RSA 2048+) │
│ - Création Certificate Signing Request (CSR)       │
│ - Inclut : domain name, public key, organization   │
└────────────────────────────────────────────────────┘
                          │
                          ▼
┌────────────────────────────────────────────────────┐
│ 2. VALIDATION DV                                    │
│ - HTTP-01 challenge (placement fichier .well-known)│
│ - DNS-01 challenge (TXT record)                    │
│ - TLS-ALPN-01 challenge                            │
└────────────────────────────────────────────────────┘
                          │
                          ▼
┌────────────────────────────────────────────────────┐
│ 3. ÉMISSION                                         │
│ - CA émet certificat signé (90j Let's Encrypt)     │
│ - Inscription Certificate Transparency logs        │
│ - Téléchargement client                            │
└────────────────────────────────────────────────────┘
                          │
                          ▼
┌────────────────────────────────────────────────────┐
│ 4. DÉPLOIEMENT                                      │
│ - Installation sur serveur web (nginx, Apache)     │
│ - Configuration cipher suites TLS 1.3              │
│ - Activation OCSP stapling                         │
│ - Configuration HSTS                               │
└────────────────────────────────────────────────────┘
                          │
                          ▼
┌────────────────────────────────────────────────────┐
│ 5. MONITORING                                       │
│ - Surveillance expiration (alertes 30j, 7j, 1j)    │
│ - CT log monitoring (CertSpotter)                  │
│ - SSL Labs grade trimestriel                       │
└────────────────────────────────────────────────────┘
                          │
                          ▼
┌────────────────────────────────────────────────────┐
│ 6. RENOUVELLEMENT                                   │
│ - Automatique via ACME (60j avant expiration)      │
│ - Nouvelle paire clés générée                      │
│ - Reload serveur web sans downtime                 │
└────────────────────────────────────────────────────┘
                          │
                          │ Cycle continu
                          ▼
                          Retour étape 1

Outils de monitoring TLS

Stack pratique pour surveiller la santé TLS production.

Audit type trimestriel : SSL Labs + testssl.sh + Hardenize. Cible : grade A+ SSL Labs, configuration Mozilla "Modern" profile.

Pièges fréquents

Six erreurs récurrentes sur les certificats TLS 2024-2026.

Piège 1 — Pas d'OCSP stapling activé

Performance dégradée + privacy compromise. Activation triviale (Nginx, Apache, Caddy auto). Devrait être par défaut partout.

Piège 2 — Renouvellement manuel raté

Expiration certificat = downtime complet du site (navigateurs bloquent). Cas régulièrement médiatisés (par exemple : Zoom 2020, Microsoft Teams 2020). Solution : automation ACME systématique, alerting 30/7/1 jour avant expiration.

Piège 3 — Wildcard trop large

*.example.test couvre tout sous-domaine niveau 1. Si compromis, exposition massive. Préférer multi-SAN explicites quand possible. Wildcards uniquement quand justifiés (multi-tenant SaaS avec sous-domaines clients dynamiques).

Piège 4 — Cipher suites obsolètes

Configuration ancienne autorisant TLS 1.0/1.1 (dépréciés mars 2020), 3DES, RC4, MD5. SSL Labs grade F. Solution : suivre Mozilla Modern config, audit trimestriel.

Piège 5 — Hardcoded certificat sans automation

Cert installé manuellement, équipe ne sait plus le re-générer ni le renouveler. Bus factor 1. Solution : tout en Git/GitOps, automation ACME documentée.

Piège 6 — Pas de HSTS

HTTP Strict Transport Security (HSTS) header force les navigateurs à utiliser HTTPS pour les visites futures. Sans HSTS, attaquant SSL stripping peut downgrader vers HTTP. Activation en 5 secondes :

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

Considérer aussi HSTS preload list (hstspreload.org) pour inclusion dans browsers natifs.

Migration vers post-quantum

État de la transition certificats vers PQ en 2026.

Standards en cours

CA/Browser Forum n'a pas encore standardisé les certificats X.509 post-quantum (en cours de discussion 2025-2026). Plusieurs propositions :

• Hybrides : certificat contenant à la fois clé classique (ECDSA P-256) et clé post-quantum (ML-DSA).
• Algorithmes purs PQ : ML-DSA (FIPS 204), SLH-DSA (FIPS 205), FN-DSA (FIPS 206 draft).
• Durée de validité : impact sur tailles certificats (ML-DSA signatures 2KB+ vs ECDSA 64B).

Premiers déploiements

• Cloudflare : certificats hybrides X.509 expérimentaux 2024-2025.
• Google Trust Services : tests internes 2025.
• Apple, Microsoft : recherche active.
• AWS : Post-quantum TLS pour KMS depuis 2024-2025.

Recommandation 2026 pour la majorité

Pour la majorité des organisations en 2026 : pas de migration immédiate des certificats TLS classiques. Maintenir veille active, tester en environnements non-prod si infrastructure critique. Migration probable 2027-2028 quand les standards CA/Browser Forum stabilisés.

Points clés à retenir

• Un certificat TLS est un document X.509 signé par une CA prouvant l'identité d'un domaine. Permet aux clients de vérifier le serveur via TLS handshake et d'établir une connexion chiffrée.
• Trois types par validation : DV (95 % des cas, gratuit Let's Encrypt, automation ACME), OV (4 %, validation organisation, payant), EV (1 %, validation rigoureuse, banques surtout).
• Let's Encrypt domine le marché 2026 avec 350+ millions de certificats actifs grâce à automation ACME (RFC 8555) gratuite.
• Validité maximale en réduction progressive : 398 jours actuellement → 200 jours mars 2026 → 100 jours mars 2027 → 47 jours mars 2029. Automation obligatoire.
• Stack moderne 2026 : Caddy ou Traefik avec ACME natif pour serveurs web, AWS ACM/Azure/Google-managed pour cloud, cert-manager pour Kubernetes, Vault PKI ou step-ca pour Private CA d'entreprise mTLS.

Pour aller plus loin

• Chiffrement asymétrique expliqué - les clés RSA et ECC contenues dans les certificats.
• Qu'est-ce que la cryptographie - vue d'ensemble incluant PKI et certificats.
• Chiffrement symétrique expliqué - AES utilisé dans TLS pour les données après handshake.
• Sécurité d'un VPS : checklist - configuration TLS Nginx avec OCSP stapling et HSTS.