HTTPS en production : certificats et durcissement
Flux ACME, diagnostic TLS, durcissement HSTS.
Objectifs
À la fin de cette leçon, vous saurez :
- suivre le flux ACME complet et son renouvellement automatique ;
- diagnostiquer un certificat défaillant ;
- durcir la configuration TLS (HSTS, redirection, versions).
🔗 Pour vous rafraîchir la mémoire : curl pas à pas · lecture de fichiers et aide (cat, grep, man) · redirections et pipes
Le flux ACME pas à pas
Quand Caddy (ou certbot) demande un certificat pour monsite.fr :
1. client ACME → autorité Let's Encrypt : « je veux monsite.fr »
2. LE : prouve le contrôle — défi HTTP-01 :
« pose ce fichier à http://monsite.fr/.well-known/acme-challenge/XYZ »
3. LE interroge http://monsite.fr/.well-known/... depuis Internet
4. fichier trouvé → certificat émis (90 jours)
5. renouvellement automatique vers J-30
Le défi HTTP-01 exige que le port 80 soit joignable publiquement et que le domaine pointe déjà : ordre de déploiement obligatoire — DNS d'abord, proxy ensuite. Variante DNS-01 : la preuve passe par un enregistrement TXT, indispensable si le port 80 est fermé ou pour des certificats wildcard (*.monsite.fr).
Diagnostiquer les pannes classiques
curl -vI https://monsite.fr 2>&1 | grep -E "subject|expire|SSL"
echo | openssl s_client -connect monsite.fr:443 -servername monsite.fr 2>/dev/null \
| openssl x509 -noout -dates -subject -issuer
| Symptôme | Cause probable |
|---|---|
| CERT_HAS_EXPIRED | renouvellement cassé (port 80 fermé ? service mort ?) |
| hostname mismatch | certificat pour un autre domaine / www oublié |
| self-signed en prod | fallback Caddy après échec ACME → vérifier les défis |
| fonctionne chez vous, pas ailleurs | propagation DNS incomplète |
Durcir au-delà du cadenas
# Dans le Caddyfile :
monsite.fr {
tls {
protocols tls1.2 tls1.3 # exclure les vieux protocoles
}
header {
Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
}
# redirection 80 → 443 automatique chez Caddy
}
HSTS dit aux navigateurs : « pendant un an, refuse tout accès en HTTP à ce domaine ». Après l'avoir envoyé une fois, même un lien http:// tapé à la main arrive chiffré. Prudence : HSTS se retire difficilement (les navigateurs le mémorisent) — ne l'activez que quand HTTPS est stable partout, sous-domaines compris.
La checklist HTTPS de mise en production
[ ] Certificat valide sur le domaine ET www
[ ] Redirection 80→443 systématique
[ ] TLS 1.2 minimum
[ ] HSTS activé (après stabilité)
[ ] Renouvellement vérifié (logs Caddy/certbot)
[ ] testssl.sh ou SSL Labs : note A ou A+
Exercice
- Sur votre serveur de test, observez les logs Caddy lors de l'émission d'un certificat.
- Testez votre site avec SSL Labs : relevez deux points d'amélioration.
- Simulez une expiration : que fait Caddy à J-30 ? Comment forcer un renouvellement ?
- Pourquoi HSTS ne doit-il être activé qu'après coupure du HTTP ?
Résumé
- ACME = démonstration de contrôle → certificat 90 jours auto-renouvelé.
- openssl s_client = radiographie TLS instantanée.
- Durcissement progressif : redirection, protocoles, puis HSTS.
Correction disponibleCherchez d’abord par vous-même.Voir la correction
Correction
Réponses détaillées
Question 4. HSTS force le navigateur à refuser HTTP pendant sa durée. Si un sous-domaine ou un ancien service ne supporte pas encore HTTPS, il devient inaccessibles aux visiteurs « éduqués » par l'en-tête. On active donc HSTS en dernier, après avoir vérifié que TOUT le périmètre est proprement en HTTPS.