Il suo browser tiene in cache i certificati intermedi, ricorda le visite passate ed è indulgente. È l'ultimo strumento con cui provare, non il primo. Questi comandi chiedono direttamente al server e non c'è nulla in cache.

1. Si verifica, prima di tutto

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) e almeno due certificati elencati. Tutto il resto è una catena incompleta.

2. Quali nomi copre

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. Quando scade

echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null \
  | openssl x509 -noout -dates

4. Ogni sottodominio, non solo quello principale

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. Senza cache, da sconosciuto

curl -sS -o /dev/null -w '%{http_code} %{ssl_verify_result}\
' https://yourdomain.com/
# ssl_verify_result 0 is correct

6. I protocolli vecchi, che andrebbero rifiutati

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 e 1.1 sono stati ritirati, e 3DES e RC4 non dovrebbero negoziare affatto. Se uno di questi si collega, la configurazione è vecchia: imposti ssl_protocols TLSv1.2 TLSv1.3; e un elenco di cifrari moderno.

Poi tenga d'occhio la scadenza

0 8 * * * /usr/local/bin/check-cert.sh yourdomain.com 21   # warn 21 days out
Controlli il certificato anche da FUORI della sua rete. Un firewall o un proxy può presentare internamente un certificato diverso, quindi una prova interna può passare mentre il sito pubblico è rotto.