What Happens When a Code Signing Certificate Expires?

Expiration ends the certificate's validity for new signing. It does not automatically invalidate every release that was signed before the expiration date.

Certificate
validity
● VALID
NEW SIGNING
EXPIRATION
the lifecycle changes here

The Short Answer

When a code signing certificate expires, it should no longer be used for new signing. Software signed before expiration may continue to validate, particularly when a trusted timestamp establishes that the signature was created while the certificate was valid.
CODE SIGNING
CERTIFICATE
✓
New signing → STOP

The expired certificate is no longer suitable for a new release. Use a current certificate that satisfies applicable requirements at signing time.

Existing signature → EVALUATE

Verification considers signing time, timestamp, certificate status, chain, and platform-specific rules.

What Does Certificate Expiration Mean?

A code signing certificate has a defined validity period. Its Not Before and Not After fields establish when the certificate is valid. the certificate lifecycle, unlike revocation, which deliberately invalidates a certificate before or during its normal lifecycle.

Issuedcertificate exists
Validnew signing is possible
Expirationvalidity period ends
After expirynew signing needs replacement

What Happens to New Code Signing?

Do not use an expired certificate for a new release. This applies whether the publisher is signing an EXE, DLL, MSI, script/package, or a new application build.

  • Signing tools may reject the expired credential.
  • The signing operation may fail validation.
  • A build or release pipeline can fail if it still references the old certificate.
  • Platform behavior and exact error messages can vary.

What Happens to Existing Software?

Existing software must be evaluated differently. verify the signature

Signed before expiration + trusted timestamp:
the timestamp can provide evidence that signing occurred while the certificate was valid.
Signed before expiration + no timestamp:
the verifier may have less reliable evidence of when the signature was created, making long-term validation more difficult.

Why Timestamping Changes the Expiration Scenario

The visual difference is simple: without a trusted timestamp, the verifier has less evidence about when the signature was created. With one, signing-time evidence travels with the signature.

Without a Trusted Timestamp

Certificate validExpires

The file was signed, but the verifier may have less reliable cryptographic evidence establishing that signing occurred during the certificate's valid period.

With a Trusted Timestamp

Certificate validExpires later
✓ SIGNING-TIME EVIDENCE

Timestamping signed software

Key point: Timestamping does not make an expired certificate valid for new signing. It helps establish the timing of an existing signature.

A trusted timestamp records evidence of signing time. The details of how that evidence works are covered in Code Signing and Timestamping Explained.

Certificate Expiration vs. Signature Validity

Certificate expirationSignature validity
The certificate itself is outside its defined validity period.Whether a particular signature can still be validated depends on the signature, certificate chain, timestamp, status, and applicable verification rules.

What a verifier is effectively checking

1. Signature
Cryptographic match
2. Certificate
Identity / validity
3. Timestamp
Signing-time evidence
4. Chain / status
Trust evaluation

Can an Expired Certificate Still Verify an Old Signature?

Potentially yes. It depends on how the signature was created and how the verifier evaluates it.

Signing timeWhen was the signature created?
Trusted timestampIs there evidence of the signing time?
Certificate validityWas the certificate valid when signing occurred?
Certificate statusDoes revocation/status affect the result?
Certificate chainCan the chain be validated?
Platform behaviorWhat rules does the verifier apply?
Do not promise that every old timestamped signature will remain accepted forever under every circumstance.

Expiration vs. Revocation

QuestionExpirationRevocation
Why?Validity period endedCertificate deliberately invalidated
Expected?Yes; normal lifecycle eventUsually exceptional
Automatic?YesNo
Can happen before expiry?NoYes
Key compromise implied?NoPotentially
Existing signaturesDepends on signing time, timestamp, status and verification rulesDepends on signing time, timestamp, revocation reason and verification rules

Expiration is expected at the end of a validity period, whereas certificate revocation changes a certificate’s status before or during its normal lifecycle.

What Happens to the Private Key?

Certificate expires ≠ private key expires. The cryptographic key does not automatically disappear when the certificate reaches its expiration date.

  • Do not use the expired certificate for new signing.
  • Continue protecting the private key as sensitive material.
  • For normal renewal, follow the CA/provider's current key-generation and protection requirements.
  • If compromise is suspected, treat it as a security incident rather than ordinary renewal.

Do You Need to Re-Sign Existing Software?

There is no blanket rule to re-sign every previous release. Evaluate the release and its signature first.

Certificate expired
Was the software already signed?
NO → New release

Sign with a new valid certificate.

YES → Existing release

Check signing time, trusted timestamp, status, chain and applicable platform rules before deciding whether re-signing is necessary.

What Happens During Certificate Renewal?

Renewal is a transition between signing credentials, not a magic extension of the old certificate.

01
Existing certificate
02
Approaching expiration
03
Renew / apply
04
Identity / policy validation
05
New certificate + key
06
Update signing environment
07
Test → verify → release
Renewal is not simply extending the old certificate's expiration date. The actual process depends on the CA and current issuance requirements.

Prepare for the next certificate before the old one expires

Compare suitable certificate options and plan the credential transition before it interrupts a release. The new certificate must meet your organization’s validation and key-protection requirements.

Should You Reuse the Existing Private Key?

Key reuse and key replacement are separate decisions. Do not present reuse as automatically preferable for a new certificate.

  • CA requirements
  • Current key-protection requirements
  • Signing infrastructure
  • Security policy
  • Whether the original key remains trustworthy
  • Whether the key is hardware-backed

What Happens in CI/CD?

Expiration often becomes visible first in automated release workflows.

Pipeline points to
OLD certificate
→
Signing step
FAILS
→
Update credential
→ test → release

New certificate → update signing configuration → test → verify → production release.

Automated release workflows need to be updated when signing credentials change. Signing software in a CI/CD pipeline helps make that transition part of the release process.

How to Check Whether a Certificate Has Expired

Inspect the certificate and signature rather than relying only on a filename, release date, or build system status.

Valid fromCertificate start date
Expires onCertificate end date
Subject / publisherIdentity information
IssuerIssuing authority
Certificate chainCertification path
Timestamp / statusSigning-time evidence and current status

On Windows, inspect the file's digital signature, select the signature, open its details, and inspect the signing certificate and certification path.

For a repeatable verification process, use the steps in the Windows signature verification guide to inspect the signature and certificate details.

Real-World Example

Watch the release timeline cross the certificate's expiration point. The old releases remain separate historical artifacts; the October release needs a current certificate.

Jan 2026
Certificate issued
Mar 2026
v1.0 signed + timestamp
Jun 2026
v1.1 signed + timestamp
Sep 2026
Certificate expires
Oct 2026
v1.2 needs new certificate
Existing v1.0 / v1.1
Evaluate signatures using evidence and rules

What Publishers Should Do Before Expiration

01Track the expiration date
02Start renewal early
03Confirm identity/contact information
04Prepare signing environment
05Obtain and configure the new certificate
06Test signing and verify the chain
07Confirm timestamping
08Update CI/CD
09Document the certificate/key transition

Common Misconceptions

“When the certificate expires, all my software stops working.”
Not necessarily.
“An expired certificate automatically makes every old signature invalid.”
Not universally; signing time and timestamp matter.
“The private key expires with the certificate.”
No.
“A timestamp makes an expired certificate valid for new signing.”
No. Timestamping helps establish signing time; it does not make an expired certificate suitable for new signing.
“Renewal extends the old certificate's expiration date.”
Not necessarily; a new certificate is generally issued through the applicable renewal/issuance process.
“Expiration and revocation are the same.”
No.

Keep the lifecycle distinctions clear

Issuance explains how you obtain a certificate. Timestamping establishes signing time. Revocation covers deliberate invalidation. This page focuses on what changes when the normal validity period ends.