verify error:num=10:certificate has expired

s_client gibt „verify error:num=10:certificate has expired“ und danach „notAfter=…“ aus; openssl verify gibt „error 10 at <depth> depth lookup: certificate has expired“ aus. Zertifikate, die noch nicht gültig sind, führen zu Fehler 9, „certificate is not yet valid“.

OpenSSL CLI (openssl s_client / openssl verify) — X509_V_ERR_CERT_HAS_EXPIRED

Was der Fehler bedeutet

OpenSSL-Fehler 10 (X509_V_ERR_CERT_HAS_EXPIRED): Ein Zertifikat in der Kette hat in notAfter ein Datum, das bezogen auf den Zeitpunkt der Prüfung in der Vergangenheit liegt; dieser Zeitpunkt ist die lokale Uhrzeit, sofern nicht -attime angegeben ist. Die zusammen mit dem Fehler ausgegebene depth-Zeile zeigt, um welches Zertifikat es sich handelt: 0 ist das eigene Zertifikat des Servers, höhere Zahlen sind Zwischenzertifikate.

Warum der Fehler auftritt

• Das Serverzertifikat ist abgelaufen (Tiefe 0)

  häufig

  Die Erneuerung ist fehlgeschlagen, oder der Server oder der Load Balancer hat das erneuerte Zertifikat nie geladen.

• Ein Zwischenzertifikat in der ausgelieferten Kette ist abgelaufen

  gelegentlich

  Alte Kettendateien liefern weiterhin ein abgelaufenes Zwischenzertifikat oder Cross-Signing-Zertifikat aus, auch nachdem die CA umgestellt hat; ersetze die Kette durch die aktuelle Kette der CA.

• Die Uhr des prüfenden Rechners geht vor

  gelegentlich

  Eine Uhr, die in der Zukunft steht, lässt gültige Zertifikate abgelaufen aussehen; mit -attime lassen sich Probleme mit der Uhr von einem echten Ablauf unterscheiden.

So behebst du den Fehler

1. 1.

   Abgelaufenes Zertifikat ermitteln

   Lies die Zeilen depth und notAfter; -checkend zeigt, ob eine Zertifikatsdatei innerhalb einer bestimmten Anzahl von Sekunden abläuft, was sich gut für das Monitoring eignet.

   # The depth printed with the error identifies the certificate; s_client also prints notAfter
   echo | openssl s_client -connect api.example.com:443 -servername api.example.com 2>&1 | grep -E '^depth|verify error|notAfter'
   # Check a file, and whether it expires within 30 days (exit 1 = yes)
   openssl x509 -in server.pem -noout -enddate -checkend 2592000

2. 2.

   Zu einem gewählten Zeitpunkt prüfen

   openssl verify -attime <unix time> zeigt, ob die Kette zu diesem Zeitpunkt gültig war, und trennt so den Ablauf von anderen Fehlern.

   # Would the chain verify at another moment? (useful to separate clock problems)
   openssl verify -attime "$(date -d '2025-02-01' +%s)" -CAfile root.pem server.pem

3. 3.

   Erneuern und neu laden

   Erneuere das Zertifikat, lade die Komponente neu, die TLS terminiert, und prüfe das neue Ablaufdatum über das Netzwerk.

   sudo certbot renew && sudo systemctl reload nginx
   echo | openssl s_client -connect api.example.com:443 -servername api.example.com 2>/dev/null | openssl x509 -noout -enddate

← Gesamte Signaturfehler-Datenbank durchsuchen