PKIX path validation failed: java.security.cert.CertPathValidatorException: validity check failed

JDK 21 und neuer stellen den TLS-Alert voran: „(certificate_expired) PKIX path validation failed: …“. Die Zeile mit der eigentlichen Ursache lautet „java.security.cert.CertificateExpiredException: NotAfter: <date>“ (oder CertificateNotYetValidException: NotBefore: <date>), wobei das Datum in der Zeitzone der JVM steht.

Java (JSSE) — SSLHandshakeException caused by CertPathValidatorException / CertificateExpiredException

Was der Fehler bedeutet

Java hat einen Zertifikatspfad zu einem Vertrauensanker gebildet, aber bei der Validierung ist die Datumsprüfung gescheitert: Ein Zertifikat im Pfad liegt zur aktuellen Zeit der JVM außerhalb seines Gültigkeitszeitraums. „Path validation“ (nicht „path building“) bedeutet: Das Vertrauen war in Ordnung, die Datumsangaben nicht. Die verschachtelte CertificateExpiredException oder CertificateNotYetValidException nennt die verletzte Grenze.

Warum der Fehler auftritt

• Das Zertifikat des Servers (oder ein Zwischenzertifikat) ist abgelaufen

  häufig

  Die Erneuerung ist ausgeblieben, oder das erneuerte Zertifikat ist nicht auf dem Endpunkt bereitgestellt, mit dem Java spricht (oft ein interner Load Balancer oder ein Java-Server mit eigenem Keystore).

• Die Kette wurde über ein abgelaufenes Zertifikat in einem eigenen Trust Store gebildet

  gelegentlich

  Trust Stores, in denen ein altes Zwischenzertifikat oder direkt ein Serverzertifikat fest hinterlegt ist, validieren auch nach dessen Ablauf weiter dagegen.

• Die Uhr des JVM-Hosts geht falsch

  gelegentlich

  Bei virtuellen Maschinen und Containern, deren Host-Uhr abgedriftet ist, können aktuelle Zertifikate abgelaufen oder noch nicht gültig erscheinen.

• Ein frisch ausgestelltes Zertifikat und eine Uhr, die nachgeht

  selten

  Zertifikate, die ab „jetzt“ gültig sind, scheitern auf Clients, deren Uhr einige Minuten nachgeht; die meisten CAs datieren notBefore deshalb leicht zurück, private CAs oft nicht.

So behebst du den Fehler

1. 1.

   Die innerste Ursache lesen

   Am Datum bei NotAfter oder NotBefore erkennst du, ob ein Zertifikat abgelaufen ist oder die Uhr falsch geht.

   Caused by: java.security.cert.CertificateExpiredException: NotAfter: Tue Apr 01 00:00:00 UTC 2025
      -> a certificate in the chain expired on that date
   Caused by: java.security.cert.CertificateNotYetValidException: NotBefore: ...
      -> not valid yet: check the clock of this machine

2. 2.

   Jedes Zertifikat prüfen, das der Server sendet

   Gib das Enddatum jedes Zertifikats der ausgelieferten Kette aus; ersetze jedes, das abgelaufen ist.

   echo | openssl s_client -connect api.example.com:443 -servername api.example.com -showcerts 2>/dev/null \
     | awk '/BEGIN CERT/{n++; f="c" n ".pem"} /BEGIN CERT/,/END CERT/{print > f}'
   for f in c*.pem; do openssl x509 -in "$f" -noout -subject -enddate; done

3. 3.

   Eigene Trust Stores bereinigen

   Liste die Einträge des Trust Stores mit ihrer Gültigkeit auf und entferne oder ersetze abgelaufene Zertifikate, die dort fest hinterlegt wurden.

   # Expired or pinned certificates in a custom trust store
   keytool -list -v -keystore app-truststore.p12 -storepass changeit | grep -E 'Alias name|Valid until|Owner'
   keytool -delete -alias old-corp-root -keystore app-truststore.p12 -storepass changeit

← Gesamte Signaturfehler-Datenbank durchsuchen