Timestamping certificate expired

The timestamp signature and/or certificate could not be verified during signtool or jarsigner often means the timestamp authority certificate chain expired—not your code signing leaf.

Release engineers hit timestamp server certificate expired when CI pipelines still possess valid code-signing certs but RFC 3161 countersignatures fail because the TSA’s SSL/TLS endpoint or signing cert aged out. Windows Authenticode, Java jarsigner -tsa, and PDF long-term validation depend on timestamp tokens issued by a Time Stamping Authority.

Timestamping uses HTTPS or HTTP to reach /tcpdf//tdssvc style endpoints, then embeds a token signed with TSA credentials. Expiry can break at the transport TLS layer (cannot reach the server) or at token verification (TSA cert in the token expired).

First response

Capture the full toolchain error (signtool, osslsigncode, jarsigner, gpg with external TSA). Note TSA URL (http://timestamp.digicert.com, internal https://tsa.corp.example/rfc3161).

Test TLS to the TSA hostname separately from verifying an old signed artifact. Record whether failures began on new signatures or when validating historical installers during audit.

Review internal PKI runbooks alongside Code signing certificate expired—teams often rotate signing certs but forget TSA hierarchy maintenance.

Archive one failing build log with timestamp extension disabled versus enabled—side-by-side logs help vendor support distinguish transport from token verification quickly. Note HSM firmware versions when signing runs through PKCS#11; rare HSM bugs mimic expiry but openssl to TSA URL should still be first.

What this error means

When signing, the client requests a timestamp token from the TSA. The token includes a signature chain rooted in a TSA certificate. If that chain is expired, verifiers reject the timestamp even if the code-signing cert was valid at signing time—undermining “signature valid after cert expiry” guarantees.

Transport failures (WinHttp SSL errors, curl: (60)) indicate TLS to the timestamp URL failed, often due to expired HTTPS cert on the TSA web server distinct from the TSA signing cert. OpenSSL must be used to separate the two layers.

EV code signing and hardware token workflows may queue signatures behind a single TSA endpoint—expiry there blocks the entire release cabinet, not one developer laptop.

Time zones matter for global release trains: a TSA HTTPS cert expiring at UTC midnight may block US afternoon builds while EU morning builds already failed—correlate timelines in the ticket.

Common causes

Vendor TSA URL changed while build scripts still point at a retired endpoint with expired TLS. Internal Microsoft AD CS timestamp role certificate expired on the TSA subordinate CA. Firewall allowlists updated but stale load balancer cert on tsa.corp blocked new CI runners.

Leap from SHA-1 TSA to SHA-256 without updating signtool /td parameters left pipelines calling deprecated hosts. Corporate SSL inspection replaced public trust with an MITM root that expired. EJBCA or SignServer nodes not renewed on the same schedule as public-facing web TLS.

Kernel-mode driver signing and UEFI dbx updates have distinct timestamp policies—Windows may accept test signatures on dev machines while production Hardware Dev Center workflows fail on the same expired TSA URL. Container signing with Cosign and Notary v2 can integrate external TSAs; treat those URLs like any other CI dependency with monitoring.

Confirm from the outside

Split failures into transport (cannot POST timestamp query) versus token (reply parses but signer cert expired). Archive one failing .tsr file and one successful historical artifact signed before the incident for side-by-side openssl ts inspection. Run checks from the same signing agent host that failed, including any HTTP proxy variables that alter the path to the TSA.

TLS to public TSA:

openssl s_client -connect timestamp.digicert.com:443 -servername timestamp.digicert.com </dev/null 2>/dev/null | openssl x509 -noout -dates -issuer

OpenSSL timestamp query (example):

openssl ts -query -data /tmp/payload.bin -cert -out /tmp/tsq.tsq
curl -sS -H 'Content-Type: application/timestamp-query' --data-binary @/tmp/tsq.tsq \
  https://freetsa.org/tsr -o /tmp/tsr.tsr
openssl ts -reply -in /tmp/tsr.tsr -text

Windows repro:

signtool sign /fd SHA256 /tr http://timestamp.digicert.com /td SHA256 /f test.pfx /p pass test.exe

Inspect token certs:

openssl ts -reply -in /tmp/tsr.tsr -token_out | openssl x509 -noout -dates -subject

macOS codesign --timestamp errors reference CSSMERR_TP_CERT_EXPIRED in Keychain logs—spot-check one failing DMG build log alongside Windows signtool output if you ship multiplatform artifacts.

How to read the output

Distinguish HTTPS notAfter (reachability) from token signer notAfter (verification). Multiple certificates may appear in a reply—check each link in the chain presented to verifiers.

Fix checklist

1. Identify TSA URLs in all signing pipelines (Windows, Java, macOS, container image signers).
2. OpenSSL TLS to each TSA hostname from CI egress.
3. Renew internal TSA CA/server certs or switch to vendor URL documented as current.
4. Update build scripts and HSM profiles with new /tr endpoints if required.
5. Re-sign a test artifact and verify offline with signtool verify /pa.
6. Re-run release pipeline without disabling timestamping.
7. Archive old tokens policy for auditors if migration changes TSA root.
8. Monitor TSA HTTPS endpoints and internal OCSP/CRL dependencies.

Archive a golden signed artifact after each TSA migration and verify annually in an air-gapped VM to prove long-term validation still satisfies auditors. Document which teams own TSA URLs in Azure Key Vault references versus YAML pipelines to avoid duplicate rotations.

If your pipeline signs both test and production artifacts with one agent pool, confirm test jobs also recovered—teams sometimes notice production failures last because nightly builds were skipped on weekends.

When to use automation

Signing pipelines run weekly while TSA certs expire on quarterly CA schedules. Monitor live TLS on every timestamp.* hostname builders call. /check suits public TSAs.

Set 30, 14, 7, and 1 day alerts; pair with RDAP on corporate domains hosting private TSA. Timestamp outages block releases—treat like production incidents.

CI should run a lightweight timestamp smoke test on every signing agent image rebuild, curling TSAs and parsing token signer dates. /check covers public vendor hostnames; private TSAs need internal monitors. Link PKI calendars with Code signing certificate expired alerts so both signing and timestamp hierarchies renew in coordinated change windows.

Legal and compliance teams depend on timestamps for non-repudiation narratives—escalate TSA expiry with the same severity as production database outages when release gates hard-stop.

Document fallback TSA URLs approved by security architecture—test failover quarterly so CI does not learn about secondary URLs during a primary outage. For air-gapped builds, internal TSAs need battery-backed HSM renewal schedules matched to public CA calendars.

NuGet, Maven central publishing, and Mac notarization each may call different timestamp services—maintain a single spreadsheet of URLs per pipeline stage. After fixing TSA TLS, regenerate at least one release artifact per supported platform and archive verification logs for compliance folders.

Release managers should block promotion when timestamp smoke tests fail even if functional tests pass—document that policy in the RACI so midnight deploys do not bypass signing gates under pressure.

Contractual SLAs with customers requiring timestamped builds should list approved TSA URLs explicitly—vendor substitutions without updating contracts create audit gaps unrelated to technical renewal.

Add every TSA hostname from build pipelines to monitoring with alerts inside signing-agent lead time—timestamp outages are release stop events. Private TSAs still benefit from internal TLS probes using the same thresholds as public Digicert or Sectigo endpoints.