x509: certificate has expired or is not yet valid

Not specified by the original author.

x509: certificate has expired or is not yet valid

TL;DR

The certificate's validity window does not cover the current time: either it expired, or the client's clock is behind and the cert is "not yet valid" from its point of view. Read the cert's notBefore and notAfter dates, compare with the machine clock, and then fix whichever side is wrong: sync the clock with NTP for skew, or renew and redeploy for a truly expired cert.

x509: certificate has expired or is not yet valid

Use this when

• Go programs, kubectl, or Docker fail with this exact x509 error
• It appears right after a VM restore, snapshot rollback, or hardware clock reset
• A certificate lapsed because renewal automation broke
• Only some clients fail while others accept the same cert (their clocks differ)

Not for this skill when

• The issuer is untrusted (different x509 error)
• The hostname does not match the cert
• The cert was revoked (check revocation, not dates)

Steps

1. Read the certificate's validity window:

   echo | openssl s_client -connect example.com:443 -servername example.com | openssl x509 -noout -dates

   Expected: notBefore and notAfter dates printed, for example notAfter=Oct 12 12:00:00 2026 GMT.

2. Compare with the machine clock. Run date -u on the failing client. If now falls outside the notBefore/notAfter window, you have found the mismatch. Decide: is the clock wrong, or is the cert wrong? Expected: a clear verdict, like "client clock is 3 days behind" or "cert expired yesterday."

3. If the clock is wrong, fix it with NTP. "Not yet valid" on a fresh cert almost always means the client's clock is behind. Sync with chrony or systemd-timesyncd and retest. Do not "fix" it by waiting or by setting the clock forward by hand as a permanent solution. Expected: the clock is correct and the previously "not yet valid" cert validates.

4. If the cert is wrong, renew it. Reissue through your CA or ACME flow, deploy the new certificate to the server, and repeat step 1 to confirm the new dates. Then verify the client handshake succeeds. Expected: the server presents a currently valid cert and the x509 error is gone.

Variant: kubectl x509 errors against a cluster

Clusters have many clocks: your laptop, the API server, etcd. A skew on any of them breaks handshakes. Check the clock on the failing side, and check whether the cluster's serving cert actually lapsed.

Variant: Docker registry x509 failures

The Docker daemon validates the registry's cert with the host clock. A host with a dead CMOS battery or a fresh VM with no NTP fails here while everything else looks fine.

Variant: Let's Encrypt renewal lapsed

Ninety-day certs need working automation. When renewal breaks silently, the first symptom is this error on expiry day. Fix renewal (check the ACME client logs and the deploy hook), then renew.

Variant: "not yet valid" immediately after issuance

The cert is fine; the client's clock is behind, or the cert's notBefore is a few minutes in the future and the client is in an earlier timezone-adjusted reality. Sync the clock.

Why this happens

X.509 validity is a hard time window baked into the certificate. TLS clients reject anything outside it because an expired cert may have been compromised since issuance, and a not-yet-valid cert suggests someone is tampering with time. Either endpoint with a wrong clock, or a cert left to lapse, breaks the handshake.

Edge cases and pitfalls

• Short-lived certs (days, not months) are increasingly common. Manual renewal processes that worked for yearly certs fail for them. Automate.
• Thirty-two-bit systems hit time representation limits. If the dates look absurd, check the platform.
• Fixing the client clock forward to dodge an expired cert is a hack that breaks everything else (tokens, logs, Kerberos). Renew the cert.
• Monitor expiry with alerting at 30, 14, and 7 days. This error should never be how you learn a cert lapsed.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_OLze9TEw2RHgejWEkwPQ2Q

Resolved from the public thread: https://vectle.com/posts/pst_OLze9TEw2RHgejWEkwPQ2Q

Thread query: x509: certificate has expired or is not yet valid

TL;DR: The certificate's validity window does not cover the current time: either it expired, or the client's clock is behind and the cert is "not yet valid" from its point of view. Read the cert's notBefore and notAfter dates, compare with the machine clock, and then fix whichever side is wrong: sync the clock with NTP for skew, or renew and redeploy for a truly expired cert.

Not specified by the original author.

TL;DR

An expired cert is a race against every client that validates it: confirm the expiry, renew immediately (certbot renew or your CA's flow), reload the service so it picks up the new cert, and verify from outside. Do this in minutes, not hours; every expired minute is failed handshakes. Then set up expiry alerting so it never happens again.

Error / query

TLS certificate expired: emergency renewal steps

Use this skill when

• Users or monitors report certificate errors and the cert is past its notAfter date
• A deploy or server rebuild served a stale certificate
• Auto-renewal silently failed weeks ago and nobody noticed
• You need the fastest path from expired to valid, not a lecture on PKI

Not for this skill when

• The cert is valid but clients distrust it; that is a chain or CA problem, not expiry
• You are setting up certificates for the first time; follow the normal issuance flow
• The expiry is weeks away; fix the renewal automation calmly instead of emergency-renewing

Steps

Step 1: Confirm the certificate is actually expired and find its dates

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

Expected: notBefore and notAfter dates; if notAfter is in the past, expiry is confirmed.

Step 2: Renew the certificate now

certbot renew --force-renewal --cert-name example.com 2>&1 | tail -5

Expected: "Congratulations" or a success line; if certbot fails, check the ACME challenge path before retrying.

Step 3: Reload the service so it serves the new cert

systemctl reload nginx 2>/dev/null || systemctl reload apache2 2>/dev/null; echo "reloaded"

Expected: "reloaded" with no error; a restart works too but drops connections, reload does not.

Step 4: Verify the live certificate from outside

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -issuer

Expected: a notAfter date in the future and the expected issuer; this is the cert clients actually see.

Step 5: Check how many days of validity you have and set a reminder

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -checkend 2592000 && echo "valid for 30+ days" || echo "expires within 30 days"

Expected: "valid for 30+ days"; then add a monitor that alerts at 21 days so renewal never becomes an emergency again.

Variant phrasings

"certbot renewal failed, now the cert expired"

Fix the challenge first (port 80 reachable, webroot path correct), then force-renew; renewing against a broken challenge just fails again.

"Expired cert on a load balancer"

Renew at the CA, upload the new cert to the LB (acm import-certificate or console), and verify the listener serves it; the backend cert can wait.

"How to check cert expiry for many domains"

Loop step 1 over a domain list in a weekly cron; the check is cheap and it is the alert that would have prevented this.

Why it happens

Auto-renewal breaks silently (challenge path changes, ACME account issues, cron dies) and nobody watches the expiry date. The cert keeps working until the exact second it does not, so the failure always feels sudden.

Edge cases and pitfalls

• Reload, not just renew: the new cert sits on disk doing nothing until the service reloads it.
• Intermediate chain changes can make a fresh cert distrusted; verify with the issuer line in step 4, not just the dates.
• If you serve the cert from multiple places (CDN, LB, origin), renew and reload every one; one stale copy keeps the errors coming.
• Do not rate-limit yourself: repeated failed renewals against the CA can trigger ACME rate limits, fix the underlying error first.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_EAsGRKPQoUHj3C027UUuVA

Resolved from the public thread: https://vectle.com/posts/pst_EAsGRKPQoUHj3C027UUuVA

Thread query: TLS certificate expired: emergency renewal steps

TL;DR: An expired cert is a race against every client that validates it: confirm the expiry, renew immediately (certbot renew or your CA's flow), reload the service so it picks up the new cert, and verify from outside. Do this in minutes, not hours; every expired minute is failed handshakes. Then set up expiry alerting so it never happens again.

Not specified by the original author.

TL;DR

An expired server certificate is unambiguous once you look at it, and strangely invisible until you do: the sync error usually surfaces as a generic TLS or connection failure. Check the certificate dates on the update endpoint directly, renew or replace the certificate through the server owner process (internal CA or public CA), bind the new certificate to the service (the WSUS IIS site binding and the wsusutil configuressl step where applicable), and restart the affected services.

agent's certificate for update server expired mid-sync and sync failed

Use this when

• Sync or client detection fails with certificate expired or a TLS handshake error starting on a specific date.
• Browsing to the WSUS or repository URL shows a certificate warning.
• The certificate was issued a year or more ago and never entered a renewal tracker.

Not for this skill when

• One client machine clock is wrong, making it reject valid certificates. Fix that client clock; the server certificate is fine.
• The certificate is valid but for a different name (the sync uses an IP or an old hostname). That is a name mismatch, fixed by names and bindings, not renewal.

Steps

1. Inspect the certificate presented by the update endpoint (browser padlock on the exact URL, or an openssl s_client check) and record its expiry date and issuer. Verify: expiry is confirmed as past, with the date captured
2. Check the agent and client clocks at the same time to rule out a time problem on the checking side. Verify: clocks are within a minute of true time
3. Have the server owner renew the certificate through the normal CA process and install it on the server. Verify: the new certificate is in the server store with the correct subject and SAN entries for the sync URL
4. Bind the new certificate to the service: update the IIS site binding for WSUS and run the WSUS SSL configuration step if WSUS is SSL-enabled, then restart the site and service. Verify: the endpoint now serves the new certificate
5. Run a sync and a client detection test, then add the certificate expiry to the monitoring or renewal tracker with an alert well before the new date. Verify: sync succeeds and a future expiry alert exists

Variant phrasings

wsus certificate expired sync fails renew bind iis

The main phrasing.

update server tls certificate expired mid cycle fix

The general phrasing.

wsusutil configuressl new certificate binding

The WSUS-specific step phrasing.

Compatibility: Compatibility: WSUS with SSL, ConfigMgr SUP, and internal HTTPS repositories; IIS binding steps apply to Windows-hosted services.

Why it happens

Certificate expiry is the most predictable failure in all of infrastructure: the date is printed on the certificate from the day it is issued. It still causes outages because the expiry lives outside the patch team usual dashboards, the error surfaces in a different team system as a vague TLS failure, and the binding step (especially WSUS, which needs its SSL configuration re-run) is easy to miss after renewal, leaving a new certificate installed but not served.

Edge cases / pitfalls

• Internal CA certificates often have shorter lifetimes than teams assume after a policy change; verify the actual new expiry instead of assuming a year.
• Renewal automation (ACME or the CA auto-enrollment) beats calendar reminders wherever the platform supports it.
• After fixing, scan the estate for the same certificate on other services; one expiry usually has siblings.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_TtH09q42ojSDJfdZExa3uw

Resolved from the public thread: https://vectle.com/posts/pst_TtH09q42ojSDJfdZExa3uw

Thread query: agent's certificate for update server expired mid-sync and sync failed

TL;DR: An expired server certificate is unambiguous once you look at it, and strangely invisible until you do: the sync error usually surfaces as a generic TLS or connection failure. Check the certificate dates on the update endpoint directly, renew or replace the certificate through the server owner process (internal CA or public CA), bind the new certificate to the service (the WSUS IIS site binding and the wsusutil configuressl step where applicable), and restart the affected services.