Aller au contenu
ecdsa.com
curl (OpenSSL backend)curl

Message d’erreur

curl: (60) SSL certificate problem: certificate has expired

Également affiché sous la forme

  • curl: (60) SSL certificate OpenSSL verify result: certificate has expired (10)

Le texte de la raison est identique dans les builds de curl avec OpenSSL 1.1.1, 3.0 et 3.5. Les versions plus récentes de curl (8.22.0 dans notre test) le formulent « SSL certificate OpenSSL verify result: certificate has expired (10) ». Les certificats qui ne sont pas encore valides produisent une autre raison : « certificate is not yet valid ».

curl (OpenSSL backend) — CURLE_PEER_FAILED_VERIFICATION, X509_V_ERR_CERT_HAS_EXPIRED (10)

Ce que cela signifie

L’un des certificats de la chaîne construite par curl a une date notAfter antérieure à l’heure actuelle de la machine qui exécute curl. Il s’agit généralement du certificat du serveur lui-même, mais un certificat intermédiaire ou une racine à signature croisée qui a expiré produit le même texte. La vérification se fait par rapport à l’horloge locale : une horloge fausse ressemble donc exactement à un certificat expiré.

Pourquoi cela se produit

Comment corriger l’erreur

  1. 1.

    Trouver quel certificat a expiré

    Affichez la date notAfter de chaque certificat envoyé par le serveur. Si le certificat feuille a expiré, renouvelez-le ; si c’est un certificat intermédiaire, remplacez le fichier de chaîne par celui que votre AC publie actuellement.

    bash
    # Split the served chain into cert1.pem (leaf), cert2.pem, ... and print each expiry date
openssl s_client -connect api.example.com:443 -servername api.example.com -showcerts </dev/null 2>/dev/null \
  | awk '/BEGIN CERT/{n++; f="cert" n ".pem"} /BEGIN CERT/,/END CERT/{print > f}'
for f in cert*.pem; do openssl x509 -in "$f" -noout -subject -enddate; done
  2. 2.

    Renouveler, recharger et vérifier ce qui est réellement servi

    Après le renouvellement, rechargez chaque processus et chaque équipement qui termine TLS pour ce nom, puis confirmez la date côté réseau plutôt qu’à partir du fichier sur le disque.

    bash
    sudo certbot renew                    # or your ACME client / CA portal
sudo systemctl reload nginx           # the server keeps serving the old file until reloaded
echo | openssl s_client -connect api.example.com:443 -servername api.example.com 2>/dev/null \
  | openssl x509 -noout -enddate      # confirm the new date is what the network sees
  3. 3.

    Corriger l’horloge du client

    Lorsque le certificat est accepté sur d’autres machines, synchronisez l’heure de la machine en échec avec NTP. Dans les conteneurs, l’horloge vient de l’hôte : corrigez-la donc à cet endroit.

    bash
    date -u                       # compare with the real UTC time
timedatectl status            # "System clock synchronized: yes"?
sudo timedatectl set-ntp true
  4. 4.

    Mettre à jour le fichier d’AC du client

    Sur les systèmes en service depuis longtemps, un paquet ca-certificates à jour supprime les racines mises hors service et ajoute les racines actuelles, ce qui permet à OpenSSL de choisir un chemin valide plutôt qu’un chemin expiré.

    bash
    # Old clients: refresh the root store so they stop building paths through retired roots
sudo apt-get update && sudo apt-get install --only-upgrade ca-certificates   # Debian/Ubuntu
sudo dnf upgrade ca-certificates                                             # RHEL/Fedora

Erreurs associées

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