Su navegador guarda intermedios en caché, recuerda visitas anteriores y es indulgente. Es lo último con lo que probar, no lo primero. Estas órdenes preguntan al servidor directamente y no hay nada cacheado.

1. ¿Verifica siquiera?

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) y al menos dos certificados listados. Cualquier otra cosa es una cadena incompleta.

2. Qué nombres cubre

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. Cuándo caduca

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

4. Cada subdominio, no solo el 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. Sin caché, como un desconocido

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

6. Los protocolos viejos, que deberían rechazarse

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 y 1.1 están retirados, y 3DES y RC4 no deberían negociar. Si alguno de ellos conecta, la configuración es vieja: ponga ssl_protocols TLSv1.2 TLSv1.3; y una lista de cifrados moderna.

Luego vigile la caducidad

0 8 * * * /usr/local/bin/check-cert.sh yourdomain.com 21   # warn 21 days out
Compruebe el certificado también desde FUERA de su red. Un cortafuegos o un proxy puede presentar un certificado distinto por dentro, así que una prueba interna puede aprobar mientras el sitio público está roto.