invalid peer certificate: certificate expired: verification time

Full form: "invalid peer certificate: certificate expired: verification time <unix> (UNIX), but certificate is not valid after <unix> (<n> seconds ago)". Earlier rustls releases printed only the variant name ("invalid peer certificate: Expired"). Certificates that are not valid yet produce a separate "not valid yet" variant.

rustls 0.23 (via reqwest, ureq, hyper-rustls) — CertificateError::ExpiredContext

What it means

rustls verified the chain but a certificate in it is past its notAfter date at the verification time. rustls 0.23 states both instants as Unix timestamps and how many seconds ago the certificate expired, which tells you immediately whether the certificate or the clock is wrong.

Why it happens

• The server's certificate expired

  common

  Renewal failed or the renewed certificate is not served yet.

• The client's clock is wrong

  occasional

  Embedded devices and containers on hosts without NTP can be far off; compare the verification time in the message with the real time.

• An expired certificate pinned as a trust anchor

  rare

  Clients that add a server certificate itself as a root keep validating against that old certificate after the server renewed.

How to fix it

1. 1.

   Convert the timestamps

   date -u -d @<seconds> turns both values into readable UTC times.

   # The message gives both instants as Unix seconds
   date -u -d @1743465600      # certificate's notAfter
   date -u                     # this machine's time

2. 2.

   Renew and redeploy

   Renew the server's certificate, reload the service, and confirm the new end date from the network side.

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

← Browse the full signature error database