Certificats, AC et ACME

Prérequis : cours 8.1 ; clés et AC, certificats ACME.

Pourquoi

Un certificat, c'est une identité signée avec une date de mort. Comprendre qui signe quoi (et comment l'automatique obtient ses signatures) évite les pannes du dimanche d'expiration.

Concepts

• Chaîne : certificat final ← intermédiaire(s) ← racine (préinstallée dans OS/navigateurs). Le serveur doit servir toute la chaîne sauf la racine : l'oubli de l'intermédiaire = LE classique.
• AC (autorité de certification, ex. Let's Encrypt) : signe après challenge ACME — HTTP-01 (fichier servi sur le port 80) ou DNS-01 (champ TXT, indispensable pour les wildcards *.example.fr).
• Wildcard : *.example.fr couvre a.example.fr mais pas example.fr nu ni a.b.example.fr. Piège n°1 des multisites.
• Renouvellement : auto à J-30, mais rate limits (5 échecs/heure), port 80 requis pour HTTP-01, et horloge serveur juste (un décalage fausse les validités !).

Exemple : auditer sa chaîne

echo | openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null \
  | awk '/BEGIN CERT/,/END CERT/' | wc -l    # 2+ = chaîne servie (final + intermédiaire)

Cas réel

Wildcard *.example.fr déployé… et example.fr nu en erreur : le wildcard ne couvre pas l'apex. Ajouter l'apex (A/AAAA + certificat avec les deux noms) : 5 minutes quand on sait, 2 heures de « mais pourtant le certificat est valide ! » sinon.

Pièges

• Intermédiaire oublié : desktop OK (cache), mobile KO — tester au mobile ou via validateur externe (ssllabs).
• Horloge serveur décalée : certificats « pas encore valides » — timedatectl avant tout.
• DNS-01 en manuel : le TXT s'oublie au renouvellement → passer en DNS-01 automatisé (plugin DNS du provider) ou rester en HTTP-01.

À retenir

Chaîne complète servie, wildcard ≠ apex, renouvellement auto + monitoring, horloge juste.