📜 C3.2.3 — Certificats numériques & PKI

Accroche (10 min)

En mars 2020, Let's Encrypt a révoqué 3 048 289 certificats en moins de 24 heures suite à un bug de validation. Des millions de sites HTTPS ont affiché des erreurs de sécurité. Les infrastructures automatisées (certbot + timer systemd) n'ont rien remarqué. Les autres ont été prises au dépourvu. La leçon : l'automatisation du renouvellement des certificats n'est pas une option, c'est une nécessité opérationnelle.

Section 1 — La PKI : infrastructure de confiance (~50 min)

Principe de la chaîne de confiance

Votre navigateur fait confiance à amazon.com sans le connaître personnellement parce qu'il reconnaît que le certificat d'Amazon a été signé par une autorité de certification (AC) que le système d'exploitation considère digne de confiance. C'est la Public Key Infrastructure (PKI) : une délégation de confiance organisée et vérifiable.

AC Racine (Root CA)          ← hors ligne, clé dans HSM
     │ signe
     ▼
AC Intermédiaire (ICA)       ← en ligne, délivre les certificats
     │ signe
     ▼
Certificat Final             ← www.innovattech.fr

La AC racine conserve sa clé privée hors ligne (HSM ou coffre-fort). Elle signe uniquement les AC intermédiaires, minimisant l'exposition. Les AC intermédiaires sont en ligne et émettent les certificats finaux. Cette séparation facilite la révocation ou rotation sans impacter la racine.

Certificat X.509 v3 — Champs clés

# Lire le certificat d'un serveur web
echo | openssl s_client -connect google.com:443 2>/dev/null | openssl x509 -noout -text

# Afficher uniquement les dates de validité
echo | openssl s_client -connect google.com:443 2>/dev/null | openssl x509 -noout -dates

TLS 1.3 — Handshake simplifié

Client                              Serveur
  │──Client Hello (suites, random)──►│
  │◄──Server Hello (suite choisie)───│
  │◄──Certificate (chaîne)───────────│
  │──Verify cert (signé par AC connue)│
  │──Client Finished (clé dérivée)──►│
  │◄──Server Finished────────────────│
  │═══════════ Données chiffrées ════│

Forward Secrecy : les clés éphémères (ECDHE) garantissent que même si la clé privée du serveur est compromise ultérieurement, les communications passées ne peuvent pas être déchiffrées rétroactivement.

Révocation des certificats

Section 2 — Let's Encrypt et automatisation ACME (~25 min)

Let's Encrypt est une AC publique et gratuite (ISRG, 2016) qui automatise l'émission via le protocole ACME (RFC 8555). Méthodes de validation :

• HTTP-01 : fichier placé sur le serveur web (port 80) — simple, mais pas de wildcard
• DNS-01 : enregistrement TXT DNS — nécessaire pour les certificats *.innovattech.fr
• TLS-ALPN-01 : réponse spéciale sur le port 443

# Installer certbot pour Nginx (Debian)
sudo apt install certbot python3-certbot-nginx

# Obtenir un certificat en production
sudo certbot --nginx -d www.innovattech.fr -d innovattech.fr

# Tester le renouvellement (dry-run — aucun certificat émis)
sudo certbot renew --dry-run

# Vérifier les certificats installés
sudo certbot certificates

# Vérifier le timer systemd de renouvellement automatique
systemctl status certbot.timer

TP — Passer InnovatTech en HTTPS (85 min)

Scénario : Le site d'InnovatTech (Nginx sur Debian 12, domaine innovattech.fr) tourne en HTTP. Mission : migrer vers HTTPS avec Let's Encrypt, vérifier la chaîne de confiance et automatiser le renouvellement. Bonus : créer une PKI interne pour l'authentification serveur-à-serveur.

Étape 1 — Utiliser l'environnement de staging Let's Encrypt

sudo apt update && sudo apt install -y certbot python3-certbot-nginx

# --staging : évite les quotas de production pendant les tests
sudo certbot --nginx --staging -d www.innovattech.fr   --email admin@innovattech.fr --agree-tos

Étape 2 — Vérifier la configuration Nginx

sudo nginx -t && sudo systemctl reload nginx
ss -tlnp | grep :443

Étape 3 — Analyser le certificat installé

# Lire le certificat (5 champs à identifier dans le livrable)
openssl x509 -in /etc/letsencrypt/live/www.innovattech.fr/cert.pem -noout -text

# Vérifier la chaîne de confiance
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt   /etc/letsencrypt/live/www.innovattech.fr/fullchain.pem
# Résultat attendu : .../fullchain.pem: OK

Étape 4 — Tester le renouvellement automatique

sudo certbot renew --dry-run
systemctl list-timers --all | grep certbot

Bonus — PKI interne pour mTLS serveur-à-serveur

# 1. Créer la clé et le certificat auto-signé de l'AC racine
openssl genpkey -algorithm RSA -out rootCA.key -pkeyopt rsa_keygen_bits:4096
openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 3650 -out rootCA.pem   -subj "/C=FR/O=InnovatTech SARL/CN=InnovatTech Root CA"

# 2. Générer la clé et le CSR pour un serveur interne
openssl genpkey -algorithm RSA -out server.key -pkeyopt rsa_keygen_bits:2048
openssl req -new -key server.key -out server.csr   -subj "/C=FR/O=InnovatTech SARL/CN=server.innovattech.fr"

# 3. Signer le certificat serveur avec les SAN appropriés
cat > v3_server.ext <<'EXT'
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage=digitalSignature,keyEncipherment
extendedKeyUsage=serverAuth,clientAuth
subjectAltName=DNS:server.innovattech.fr
EXT

openssl x509 -req -in server.csr -CA rootCA.pem -CAkey rootCA.key   -CAcreateserial -out server.crt -days 825 -sha256 -extfile v3_server.ext

# 4. Construire la chaîne complète
cat server.crt rootCA.pem > server_fullchain.pem

Synthèse (10 min)

Question : Quelle est la différence entre un certificat et une clé privée ? Que se passe-t-il si la clé privée d'un serveur web est compromise ?