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

À partir du JDK 21, l’alerte TLS figure en tête du message : « (certificate_expired) PKIX path validation failed: … ». La ligne de la cause première est « java.security.cert.CertificateExpiredException: NotAfter: <date> » (ou CertificateNotYetValidException: NotBefore: <date>), dans le fuseau horaire de la JVM.

Java (JSSE) — SSLHandshakeException caused by CertPathValidatorException / CertificateExpiredException

Ce que cela signifie

Java a construit un chemin de certificats jusqu’à une ancre de confiance, mais sa validation a échoué au contrôle des dates : un certificat du chemin se trouve hors de sa période de validité à l’heure courante de la JVM. « Path validation » (et non « path building ») signifie que la confiance n’était pas en cause, contrairement aux dates. L’exception imbriquée CertificateExpiredException ou CertificateNotYetValidException indique la borne en cause.

Pourquoi cela se produit

• Le certificat du serveur (ou un intermédiaire) a expiré

  fréquente

  Le renouvellement n’a pas eu lieu, ou le certificat renouvelé n’est pas déployé sur le point de terminaison avec lequel Java communique (souvent un répartiteur de charge interne ou un serveur Java doté de son propre magasin de clés).

• La chaîne a été construite via un certificat expiré d’un magasin de confiance personnalisé

  occasionnelle

  Les magasins de confiance qui épinglent directement un ancien certificat intermédiaire ou un certificat de serveur continuent de valider par rapport à celui-ci après son expiration.

• L’horloge de l’hôte de la JVM est fausse

  occasionnelle

  Les machines virtuelles et les conteneurs dont l’horloge de l’hôte a dérivé peuvent faire paraître des certificats en cours de validité expirés ou pas encore valides.

• Un certificat tout juste émis et une horloge en retard

  rare

  Les certificats valides à partir de « maintenant » échouent sur les clients en retard de quelques minutes ; c’est pourquoi la plupart des AC antidatent légèrement notBefore, ce que les AC privées ne font souvent pas.

Comment corriger l’erreur

1. 1.

   Lire la cause la plus interne

   La date NotAfter ou NotBefore vous indique si un certificat a expiré ou si l’horloge est décalée.

   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.

   Vérifier chaque certificat envoyé par le serveur

   Affichez la date de fin de chaque certificat de la chaîne servie ; remplacez celui qui a expiré.

   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.

   Nettoyer les magasins de confiance personnalisés

   Listez les entrées du magasin de confiance avec leur validité, et supprimez ou remplacez les certificats expirés qui y ont été épinglés.

   # 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

← Parcourir toute la base de données des erreurs de signature