What happens when your code signing certificate expires depends almost entirely on one thing: whether your signed files include a cryptographic timestamp. If they do, your existing signed software continues to work normally for end users after the certificate expires. If they don’t, the signatures on all your files become invalid on the expiry date, and users see security warnings.
This is the most important and most commonly misunderstood aspect of code signing certificate expiry. Developers who sign without timestamps panic unnecessarily when they discover their certificate has expired. Developers who sign without timestamps and don’t know it may be caught off guard when their software stops working after expiry.
The second clear impact of expiry is independent of timestamps: you cannot sign new files with an expired certificate. Your existing signed files may be fine, but your CI/CD pipeline will fail at the signing step and you cannot release new software until you renew.
How Timestamps Protect Signatures After Certificate Expiry
When you sign a file and include a timestamp, two things are embedded in the signature: the Authenticode signature itself (which covers the file’s content and your certificate), and a countersignature from a Timestamp Authority (TSA). The TSA countersignature cryptographically records the exact time when signing occurred and is signed by the TSA’s own long-lived certificate.
When Windows or another platform later verifies the signature, it evaluates: was the signing certificate valid at the time of signing? The timestamp answers this question definitively. If your certificate was valid when the timestamp was applied, and the file content matches the signature, the verification passes: the certificate having since expired does not affect the result.
Timestamp Authority certificates are issued with very long validity periods, typically 25 to 40 years. Major TSAs include DigiCert, Sectigo, GlobalSign, and the RFC 3161 services operated by major CAs. As long as the TSA’s certificate remains valid and trusted, the timestamps in your signatures continue to serve their protective function.
The timestamp is not optional. It is the difference between a signature that protects your software indefinitely and one that stops working the day your certificate expires. Every code signing guide, every CA, and every security standard recommends always including a timestamp. The cost is adding one flag to your signing command (-t or -tr for signtool, equivalent for other tools). Signing without a timestamp to save one parameter or one second of signing time creates a maintenance problem that can affect every user of every signed file.
What Actually Happens: Four Scenarios
| Scenario | Impact on existing signed files | Impact on new releases | Action needed |
| Certificate expired; files were signed WITH timestamp | No impact. Signature verification passes. Users see no change. UAC shows publisher name. SmartScreen unaffected. | Cannot sign new releases. Pipeline signing fails. | Renew certificate to sign new releases. No action needed for existing files. |
| Certificate expired; files were signed WITHOUT timestamp | Signatures become invalid on expiry date. Windows marks signature as ‘Invalid.’ UAC shows ‘Unknown Publisher.’ SmartScreen reputation may be affected. | Cannot sign new releases. Pipeline signing fails. | Renew certificate immediately. Re-sign all affected files with new certificate and timestamp. |
| Certificate expiring soon (within 30-60 days); files have timestamps | No current impact. Timestamps protect existing signatures. | Renewing before expiry avoids any pipeline gap. | Renew proactively. No urgency for existing files. |
| Certificate was never used; just expired | No signed files exist. No user impact. | Cannot sign new releases. | Renew or purchase new certificate before signing is needed. |
Windows and Authenticode: Detailed Expiry Behavior
Windows evaluates Authenticode signatures by checking whether the signing certificate was valid at the time of signing. With a valid timestamp, this evaluation consistently passes even after certificate expiry. Without a timestamp, Windows checks whether the certificate is currently valid, and an expired certificate fails this check.
UAC dialog after certificate expiry
For files signed with a timestamp: the UAC dialog continues to show your verified publisher name in a blue dialog. Nothing changes for users running your software. The certificate expiry date appears in the certificate details if a user inspects it, but it does not affect the displayed trust level.
For files signed without a timestamp: the UAC dialog reverts to ‘Unknown Publisher’ with a yellow or orange warning header. This is the same appearance as unsigned software. If the software was previously seen with your publisher name, users will notice the change and may be concerned.
SmartScreen behavior after certificate expiry
SmartScreen reputation is associated with the publisher identity established by the certificate. For timestamped files, the signature remains valid and the publisher identity is preserved. SmartScreen reputation built over time is not immediately affected by certificate expiry.
For files without timestamps where the signature becomes invalid, SmartScreen may re-evaluate the software as effectively unsigned or with an invalid publisher identity. Reputation accumulated under the valid certificate may not carry over. New SmartScreen reputation building from a replacement certificate starts the usual accumulation process.
Checking whether your files have timestamps
| # Check a signed file for timestamp presence:
signtool verify /pa /v YourApp.exe
# In the output, look for lines containing: # ‘The signature is timestamped: 2026‘ # This confirms a valid timestamp is present.
# If the output shows only the signature details with no timestamp line, # the file was signed without a timestamp.
# Alternative: certutil inspection > certutil -v -verify YourApp.exe # Look for the Timestamp section in the output.
# If no timestamp is present and the certificate is expired or near expiry, # re-sign the files with the current (or renewed) certificate plus timestamp # before the certificate expires to extend signature validity. |
The CI/CD Pipeline: What Breaks When the Certificate Expires
Regardless of timestamp status on existing files, an expired certificate breaks your signing pipeline for new releases. When signtool, jarsigner, or any other signing tool attempts to sign a file with an expired certificate, the signing operation fails. The error message varies by tool but will indicate an expired or invalid certificate.
Pipeline failures from certificate expiry typically surface at the first build that runs after the expiry date. If your release cycle means a week passes between builds, the failure appears up to a week after the technical expiry. This is why monitoring certificate expiry dates and renewing proactively is more reliable than waiting for a build failure to prompt action.
For teams with continuous deployment, an expired signing certificate means immediate inability to release. For teams with less frequent releases, the window between expiry and discovery of the problem is unpredictable. Both cases argue for expiry monitoring and proactive renewal 30-60 days before expiry.
With the CA/B Forum’s March 2026 validity reduction to 460 days (approximately 15 months), code signing certificates now expire significantly more frequently than before. A certificate expiring mid-release cycle, mid-sprint, or during a critical security patch period is a realistic scenario. Set calendar reminders and CI alerts at 60 days before expiry. Do not rely on CA email notifications alone: these can be missed, filtered as spam, or sent to an address that has changed.
Expiry Behavior by Platform
Java JAR signing
Java’s jarsigner tool verifies certificate validity at the time of verification by default, not at the time of signing, unless a timestamp is present. A JAR signed with an expired certificate and no timestamp shows verification warnings or errors when verified. With a timestamp, jarsigner uses the timestamp to confirm the certificate was valid at signing time, and verification passes.
For deployed applications loaded by a JRE, the behavior depends on the Java version and security configuration. Strict configurations may refuse to load JARs with expired certificates without timestamps. Always include a timestamp when signing JARs intended for long-term deployment.
Android APKs
Android APK signing uses a different model. For app updates, Android requires the signing key to match the original, regardless of certificate expiry: you can update an app with an expired certificate because Android checks key identity, not certificate validity, for update authorization. New installs on modern Android versions (with stricter V2/V3 signature verification) apply more stringent certificate validity checks. The practical recommendation is the same: include a timestamp and renew certificates proactively.
macOS Developer ID and notarization
Apple’s notarization system records the signing time when a binary is submitted for notarization. The notarization ticket functions similarly to an RFC 3161 timestamp: it records that the binary was signed and notarized while the Developer ID certificate was valid. Notarized apps continue to pass Gatekeeper verification after the Developer ID certificate expires, provided the notarization ticket is stapled to the app bundle.
For macOS apps distributed outside the App Store and notarized before the certificate expired, users continue to run the app normally. New releases require a valid Developer ID certificate, so renewals must happen before releasing new versions.
Re-Signing Files When Timestamps Were Not Included
If your files were signed without timestamps and your certificate has expired or is about to expire, you need to re-sign them with a new certificate that includes a timestamp. The process:
- Renew or purchase a new code signing certificate
- Sign each affected file using the new certificate with a timestamp
- Distribute the re-signed files to replace the expired-signature versions
Re-signing with a new certificate changes the signature on the file. The new signature is from a different certificate with a different publisher thumbprint. Existing SmartScreen reputation accumulated under the old certificate is associated with the publisher organization name. If the organization name in the new certificate is identical to the old certificate, SmartScreen reputation should carry over. If any details change, reputation may need to rebuild.
You do not need to re-sign files that were already signed with a timestamp. A properly timestamped signature is valid indefinitely (subject to the Timestamp Authority’s certificate remaining trusted, which is typically decades away). Re-signing timestamped files is unnecessary work and changes the signature, potentially affecting signature-based auditing records. Only re-sign files that were signed without timestamps.
Preventing Expiry Problems: What to Put in Place
- Always timestamp: Include -tr (timestamp server URL) in every signtool command and equivalent in all other signing tools. This is the single most important practice. It means that when a certificate expires, existing signed files are unaffected and you only need to renew to enable new releases.
- Set calendar alerts at 60 and 30 days before expiry: Do not rely solely on CA email notifications. Add the certificate expiry date to your team calendar when you receive or renew a certificate.
- Add expiry monitoring to CI/CD: Tools like certutil can read certificate expiry dates from certificate files or stores. A daily or weekly CI job that checks certificate expiry and alerts when within 60 days provides early warning before a pipeline failure.
- Document your signing infrastructure: Record which certificate thumbprint was used to sign each release. This enables rapid identification of which files need re-signing in the event of an unexpected expiry without timestamps.
- Renew before you are in a hurry: With 460-day certificates, the renewal cycle is approximately annual. A certificate renewed when there are 60 days remaining gives plenty of time for validation (typically 1-7 days) without deadline pressure.
Frequently Asked Questions
My code signing certificate expired. Is all my software broken?
Not if your files were signed with timestamps. Run signtool verify /pa /v on one of your signed files and look for a timestamp in the output. If a timestamp is present, the signature was valid at signing time and remains valid. Users running your software will see no change. What is broken is your ability to sign new releases: you cannot sign new files with the expired certificate, and your CI pipeline will fail at the signing step. Renew your certificate to restore pipeline signing.
Do I need to re-sign all my old releases when I renew my certificate?
Only if those releases were signed without a timestamp. If they were signed with a timestamp, re-signing is unnecessary: the existing signatures remain valid indefinitely. If they were signed without a timestamp and the certificate has expired, re-signing with the new certificate and a timestamp is required to restore signature validity. Use signtool verify to check each file for timestamp presence.
How long does a timestamp keep a signature valid?
A timestamp keeps a signature valid as long as the Timestamp Authority’s own certificate chain remains trusted. Major TSAs issue their certificates with validity periods of 25 to 40 years. Practically, a timestamp from a reputable TSA (DigiCert, Sectigo, GlobalSign) will keep a signature valid for the useful lifetime of the software. There is no practically meaningful expiry concern from the timestamp itself for contemporary software.
Can I add a timestamp to an already-signed file without re-signing it?
No. A timestamp is part of the signature and must be added at signing time. You cannot add a timestamp to an existing signature after the fact. If a file was signed without a timestamp and you want to protect it against certificate expiry, you must re-sign the file (which creates a new signature) with the current certificate and include a timestamp in that new signing operation. Do this before the certificate expires.
Gloria Bradford is a renowned expert in the field of encryption, widely recognized for her pioneering work in safeguarding digital information and communication. With a career spanning over two decades, she has played a pivotal role in shaping the landscape of cybersecurity and data protection.
Throughout her illustrious career, Gloria has occupied key roles in both private industry and government agencies. Her expertise has been instrumental in developing state-of-the-art encryption and code signing technologies that have fortified digital fortresses against the relentless tide of cyber threats.