Outil · TLS
Le certificat, pas le cadenas du navigateur
Le cadenas peut être vert et le cert quand même pourri : mauvais nom, chaîne incomplète, expiration dans trois jours. On ouvre une session TLS et on lit ça sans se fier à Chrome.
Ce qui casse le plus souvent
Let’s Encrypt oublié dans le cron. Un wildcard qui ne couvre pas www. Un intermédiaire manquant parce que quelqu’un a collé seulement le leaf dans nginx. Rien de rare.
HSTS est à part : le cert peut être nickel et le navigateur ne force toujours pas le HTTPS. On lit l’en-tête sur la page, en plus de la poignée TLS.
Ce qu’on lit
- Chaîne de confiance
- Le serveur présente-t-il une chaîne qu’une autorité connue valide ? rejectUnauthorized côté client, on reporte l’erreur.
- Expiration
- Sous 14 jours on prévient. Expiré, c’est rouge. Pas de magie : c’est la date du cert.
- Nom (SAN / CN)
- www.exemple.com n’est pas exemple.com. Les wildcards *.exemple.com ne couvrent pas un troisième niveau n’importe comment.
- Protocole
- TLS 1.2 ou 1.3. En dessous, on le dit.
- HSTS
- max-age, includeSubDomains, preload. Preload sans 1 an de max-age, ça ne sert à rien de le rêver.
Limites, dites clairement
On ne teste pas le renouvellement automatique. On ne sait pas si votre ACME tourne. On voit l’état maintenant.
Le port 80 n’a pas de certificat. Collez l’hôte ou une URL https. Les IP privées sont refusées, comme pour les headers.
En pratique
Pourquoi « encore 37 jours » alors que je renouvelle à 30 ?
- On compte jusqu’à validTo, pas jusqu’à votre cron. Si Certbot passe à 30 jours, vous serez dans le vert jusqu’au prochain cycle.
Un cert auto-signé ?
- La connexion TLS s’ouvre (on ne coupe pas), mais la chaîne de confiance est en échec. C’est le comportement attendu.
HSTS preload, je coche ?
- Seulement si vous assumez de ne plus jamais servir le domaine en HTTP, y compris les sous-domaines. Sinon laissez includeSubDomains et un max-age long, sans preload.
À croiser
Un bon cert avec des headers vides, c’est fréquent. Enchaînez sur le test d’en-têtes.