Votre navigateur garde des intermédiaires en cache, se souvient des visites passées, et se montre indulgent. C'est le dernier outil avec lequel tester, pas le premier. Ces commandes interrogent le serveur directement, et rien n'est mis en cache.
1. Se vérifie-t-il seulement
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com < /dev/null 2>/dev/null \
| grep -E 'Verify return code|^ *[0-9]+ s:'
Verify return code: 0 (ok) et au moins deux certificats listés. Tout le reste, c'est une chaîne incomplète.
2. Quels noms il couvre
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com < /dev/null 2>/dev/null \
| openssl x509 -noout -text | grep -A1 "Subject Alternative Name"
3. Quand il expire
echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null \
| openssl x509 -noout -dates
4. Chaque sous-domaine, pas seulement le principal
for h in www shop api mail staging; do
printf '%-8s ' "$h"
echo | openssl s_client -connect "$h.yourdomain.com:443" -servername "$h.yourdomain.com" 2>/dev/null \
| openssl x509 -noout -enddate 2>/dev/null || echo "no certificate"
done
5. Sans cache, en inconnu
curl -sS -o /dev/null -w '%{http_code} %{ssl_verify_result}\
' https://yourdomain.com/
# ssl_verify_result 0 is correct
6. Les vieux protocoles, qui devraient être refusés
openssl s_client -connect yourdomain.com:443 -tls1_1 < /dev/null 2>&1 | tail -3
# a handshake failure here is the CORRECT result
TLS 1.0 et 1.1 sont retirés, et 3DES et RC4 ne devraient pas négocier. Si l'un d'eux se connecte, la configuration est ancienne : posez
ssl_protocols TLSv1.2 TLSv1.3; et une liste de chiffrements moderne.Puis surveillez l'expiration
0 8 * * * /usr/local/bin/check-cert.sh yourdomain.com 21 # warn 21 days out
Vérifiez aussi le certificat depuis l'EXTÉRIEUR de votre réseau. Un pare-feu ou un proxy peut présenter un certificat différent en interne : un test interne peut donc réussir alors que le site public est cassé.