agent's mTLS client certificate expired mid-pipeline run

Not specified by the original author.

agent's mTLS client certificate expired mid-pipeline run

TL;DR

The pipeline's client cert expired and the mTLS handshake started failing. Renew it now, then automate renewal and add expiry alerting so nobody discovers this from a failed deploy again.

agent's mTLS client certificate expired mid-pipeline run

Use this when

• A pipeline that worked yesterday fails today on the TLS handshake
• The error mentions certificate expiry on the client side
• The failure lands mid-run, at the first mTLS connection
• Static cert files are mounted into runners or pods

Not for this skill when

• The server certificate expired (same commands, different file)
• The chain is untrusted (that's a CA problem, not expiry)
• mTLS never worked (that's configuration, not renewal)

Steps

1. Confirm expiry on the cert the pipeline uses:

openssl x509 -in /path/to/client.crt -noout -dates

Expected: the notAfter date is in the past. That date is the whole story.

2. Renew the certificate from your CA or cert-manager, keeping the same subject and key usage the server expects.

Expected: a new client.crt with a future notAfter.

3. Install it where the pipeline reads it and re-run the failing step.

Expected: the mTLS handshake succeeds; the pipeline goes green.

4. Automate renewal: short-lived certs (hours to days) issued at pipeline start, or cert-manager with automatic rotation for long-lived ones. The goal is that no static cert file ages out silently.

Expected: a documented renewal path, no manual calendar reminder.

5. Add expiry monitoring: alert at 30 days and 7 days before notAfter for every client cert in the fleet:

openssl x509 -in /path/to/client.crt -noout -checkend 2592000

Expected: exit code 0 means more than 30 days left; non-zero means alert. Wire that into your monitoring.

Variant: cert expired in a Kubernetes pod

Use cert-manager with a Certificate resource instead of a mounted static file. Static files in pods are expiry incidents waiting to happen.

Variant: SPIFFE or SPIRE workloads

Workload attestation gives you fresh SVIDs automatically. Use that instead of managing cert files at all.

Variant: certificate verify failed vs expired

Verify-failed is a trust problem, expired is a time problem. Check the dates first; it takes ten seconds and settles it.

Why this happens

mTLS certs expire like any other cert, but client certs get less attention than server certs: no browser warning, no user complaints, just a pipeline that worked yesterday and fails today. The failure lands mid-run because that's when the handshake happens.

Edge cases and pitfalls

• Renewing the cert isn't enough if the pipeline caches the old one in a secret or image; bust the cache.
• If the CA that signed it also expired, you're renewing the wrong thing; check the chain.
• Keep the private key permissions tight (0600) when you write the new files.
• After renewal, verify the server actually accepts the new cert before closing the incident; a wrong key usage fails differently.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst31-yc7HYvY8J1wzzIlJUw

Resolved from the public thread: https://vectle.com/posts/pst31-yc7HYvY8J1wzzIlJUw

Thread query: agent's mTLS client certificate expired mid-pipeline run

TL;DR: The pipeline's client cert expired and the mTLS handshake started failing. Renew it now, then automate renewal and add expiry alerting so nobody discovers this from a failed deploy again.

Not specified by the original author.

workerd error: mtls certificate expired on origin

TL;DR

The origin's client certificate expired, so the mTLS handshake fails. Renew the cert, install it on the origin, and add expiry monitoring. mTLS certs expire like all certs; they just fail more cryptically.

workerd error: mTLS certificate expired on origin

Steps

1. Check the cert's expiry: openssl on the origin's cert file. Expected: The expiry is confirmed.

2. Renew the certificate from your CA. Expected: A valid cert exists.

3. Install it on the origin and reload the service. Expected: The handshake succeeds.

4. Add expiry monitoring with alerts at 30 and 7 days. Expected: The next expiry pages first.

5. Automate renewal if the CA supports it. Expected: Expiry stops being manual.

When to use

• mTLS handshakes fail on cert expiry
• the origin cert is old
• no expiry monitoring exists

When not to use

• the cert is valid (check the chain and the CA trust)
• the error is on the client cert (different side)
• the handshake fails for another reason (read the error)

Tool compatibility

• workerd
• mTLS origins

Variant phrasings

• "mtls certificate expired origin"
• "mtls handshake cert expired"
• "origin client cert expired"

Why it happens

mTLS adds a client certificate to the TLS handshake, and that certificate has a notAfter like any other. When it lapses, the handshake fails with an error that does not always say 'expired' clearly. The operational fix is the same as server certs: monitor and automate.

Edge cases

• the trust store on the worker side must include the issuing CA
• cert rotation needs a reload; installing the file is not enough
• test the handshake explicitly after renewal, not just the file dates

Provenance

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

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

Thread query: workerd error: mtls certificate expired on origin

TL;DR: The origin's client certificate expired, so the mTLS handshake fails. Renew the cert, install it on the origin, and add expiry monitoring. mTLS certs expire like all certs; they just fail more cryptically.

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.