Code Signing and Timestamping Explained
A code signing certificate can eventually expire. Timestamping adds trusted evidence about when the signing event occurred, which can be important when a previously signed application is validated later.
The key question is not simply “does timestamping keep an expired certificate valid?” It does not. The useful question is what evidence about signing time is available when the signature is evaluated later, and how does the applicable platform use that evidence?
Timestamping at a Glance
Timestamping adds a time-stamping authority to the signing workflow. The publisher creates the code signature; the TSA provides a timestamp token that carries trusted time evidence associated with the signed data.
Software
The application or signed artifact is prepared for distribution.
Digital Signature
The publisher uses the code signing private key to create the signature.
Timestamp Authority
A TSA provides a trusted timestamp service rather than issuing the publisher's certificate.
Timestamp Token
The token is incorporated with the signature so later validation has signing-time evidence.
The timestamp is therefore an additional piece of evidence around the signature. It is not a second publisher signature and it does not make every future validation outcome automatic.
What Is a Code Signing Timestamp?
A code signing timestamp is trusted evidence associated with the time at which a signing operation occurred. It is supplied by a Timestamp Authority rather than being created by the publisher's code signing certificate.
The timestamp request is based on cryptographic data related to the signing event. The TSA returns a timestamp token containing information such as a message imprint, a time value and TSA-related certificate/signature information.
This creates an important distinction: the timestamp does not sign the software in the same sense as the publisher's signing key. Instead, it provides independently generated time evidence that can participate in later signature validation.
Timestamp certificate and timestamp token are related, but they are not the same object.
Why Is Timestamping Needed?
Certificate validity changes with time. A signature created while a certificate was valid may be encountered much later, after the certificate has passed its stated validity period.
Without Timestamp
The later verifier has less signing-time evidence available to establish when the signature was created.
With Trusted Timestamp
The signed artifact carries evidence that a timestamping service associated with the signature with a particular time.
This is intentionally not a promise of perpetual validity. Timestamp trust, certificate status, signature validity and platform rules still matter. A timestamp is one part of the evidence used during later validation.
How Timestamping Works
The timestamping sequence begins after the publisher has created the software signature and ends when the timestamp token is incorporated into the signed artifact.
Software is signed
The publisher creates the digital signature using the code signing private key.
Request is generated
The signing system prepares timestamp request data based on the signature and required imprint.
TSA issues token
The Timestamp Authority processes the request and returns timestamp evidence.
Token is incorporated
The timestamp token becomes part of the signed artifact's available validation evidence.
The TSA generally does not need the entire software file. Timestamping is designed around a cryptographic message imprint so the service can provide time evidence over the relevant data without becoming the publisher's software signer.
What Is a Timestamp Authority (TSA)?
A Timestamp Authority is a service that provides trusted time-stamping evidence. Its role is different from the Certificate Authority that issues the publisher's code signing certificate.
The CA validates the publisher's identity and issues the code signing certificate. The TSA instead processes timestamp requests and returns a timestamp token under its own time-stamping certificate hierarchy.
The distinction matters because the publisher and the TSA are separate cryptographic identities. The publisher's private key signs the software; the TSA's private key is used for the timestamp service.
| Certificate Authority | Timestamp Authority |
|---|---|
| Validates publisher identity and issues the code signing certificate. | Provides trusted evidence associated with a timestamping event. |
| Operates an identity/trust hierarchy for subscriber certificates. | Operates a time-stamping trust hierarchy. |
| Publisher's code signing certificate is the relevant end-entity credential. | Timestamp certificate authenticates the timestamp service and its token. |
What Is Inside a Timestamp Token?
A timestamp token contains structured evidence that binds a cryptographic message imprint to a time value and the Timestamp Authority's identity and signature.
At a conceptual level, the verifier can inspect the message imprint, timestamp, TSA identity and TSA signature, along with the certificate information needed to validate the timestamp authority.
The message imprint is especially important: it lets the verifier relate the token to the data that was presented for timestamping without requiring the TSA to sign the entire software file.
Timestamp Token
Code Signing Certificate vs Timestamp Certificate
Both certificates participate in the broader validation story, but they represent different parties and support different cryptographic purposes.
Confusing these certificates can make timestamp troubleshooting unnecessarily difficult. A timestamp certificate does not replace the publisher's code signing certificate, and the publisher's certificate does not authenticate the TSA's timestamp.
Where Does Timestamping Fit in the Signing Process?
Timestamping sits alongside the code signing operation rather than replacing it. The publisher creates the signature first; the timestamp service adds independent time evidence afterward.
The final signed artifact can therefore contain the publisher's signature plus timestamp evidence associated with that signature.
What Happens When the Code Signing Certificate Expires?
Expiration is where timestamping becomes practically important. The goal is to preserve evidence that the signing event occurred while the signing certificate was within its applicable validity period.
The signature may be encountered later with less evidence about when it was created. Once certificate validity has changed, the applicable platform may have difficulty establishing the historical signing context required for its validation rules.
Key issue: signing time is not independently evidenced by a trusted timestamp.
The signature carries evidence that a trusted timestamping service associated the signed data with a signing time while the publisher's certificate was valid, subject to applicable validation rules.
Key issue: timestamp evidence can help the verifier establish the historical signing event.
Validity period ends
The certificate reaches the end of its stated validity period.
Signing time evidence
The timestamp provides evidence associated with when the signing event occurred.
Status still matters
Timestamping is not a mechanism that automatically overrides every revocation or compromise scenario.
Cryptographic validity
The underlying signature still has to satisfy the applicable verification process.
Expiration vs Revocation
Expiration and revocation are different certificate-status events. Timestamping adds signing-time evidence, but it does not erase the significance of certificate compromise or other status conditions.
| Event | Meaning | Timestamp relationship |
|---|---|---|
| Certificate expires | The certificate's normal validity period has ended. | A trusted timestamp can provide evidence about when the signing event occurred. |
| Certificate is revoked | The CA has invalidated the certificate before or independently of normal expiry. | Timestamping does not automatically override every revocation or compromise condition. |
| Timestamp exists | A TSA has provided trusted time evidence associated with the relevant signed data. | Its own certificate and trust relationship can require validation. |
| Signature is invalid | Cryptographic or signature validation has failed. | A timestamp cannot repair an invalid underlying signature. |
How Timestamp Verification Works
Timestamp verification is a reverse journey: instead of asking how a timestamp was created, the verifier asks whether the available token and its authority can be trusted and what signing-time evidence they provide.
The verifier can examine the timestamp token, validate its cryptographic relationship to the relevant imprint, validate the TSA certificate and chain, and determine the time represented by the token.
That information is then considered alongside the code signing certificate and the signed software. The final result depends on the applicable signature format, certificate status and platform validation rules.
Timestamping and Certificate Chains
Timestamping can introduce a second certificate hierarchy into the validation picture. The publisher's code signing chain and the TSA's timestamp chain are separate trust relationships.
Code Signing Chain
This chain supports validation of the publisher's signing certificate.
Timestamp Chain
This chain supports validation of the timestamp authority's certificate and token.
The existence of two chains does not mean the timestamp certificate is an intermediate in the publisher's chain. They are separate hierarchies connected through different identities and purposes.
Timestamping Formats & Algorithms
Modern timestamping is built around standardized time-stamping concepts rather than a proprietary “timestamp file.”
Timestamping Across Platforms
The purpose of trusted time evidence is consistent, but the way timestamping is attached to and validated with a signature can differ by platform and signing technology.
| Environment | Timestamping context | Important boundary |
|---|---|---|
| Windows / Authenticode | Timestamp evidence can be attached to an Authenticode signature. | Validation follows Windows certificate and signature infrastructure. |
| Java / JAR | Timestamping can be associated with signed JAR entries and signing information. | Java runtime and signing configuration affect validation behavior. |
| macOS | Apple has its own code-signing and distribution ecosystem. | Do not map Windows timestamp behavior directly onto Apple workflows. |
| CI/CD | Timestamping can be integrated into automated signing pipelines. | Production systems need reliable TSA connectivity and post-signing validation. |
What If the Timestamp Server Is Unavailable?
Timestamping introduces a dependency on an external service. A production signing workflow therefore needs to decide what happens when the TSA cannot be reached or its response cannot be validated.
If timestamping is configured as a required part of the signing workflow, a failed timestamp request can cause the signing operation to fail or leave the artifact without the expected timestamp evidence. Network failures, service availability and response-validation problems should be treated as operational concerns.
Production signing systems can account for this with appropriate retry behavior, a supported alternate TSA where permitted, monitoring and post-signing verification.
Should Every Code Signing Signature Be Timestamped?
For software that will be distributed and validated after the signing certificate's validity period, timestamping is generally an important part of a robust signing workflow. The exact requirement can still depend on the platform, signature technology and applicable policy.
Timestamping is especially valuable for
- Long-lived software releases
- Enterprise applications distributed over time
- Publicly distributed applications
- CI/CD release pipelines
- Artifacts expected to be validated after certificate expiration
Do not reduce it to “always mandatory”
- Platform requirements can differ
- Signature formats can differ
- Organizational policies can differ
- Some workflows may have different validation requirements
- Check the specific ecosystem and signing technology
The practical rule is to treat timestamping as a deliberate part of the signing architecture, not as an optional afterthought added only when a certificate is about to expire.
A Practical Timestamping Scenario
Imagine a company releasing version 5.2 of a desktop application. The application is signed while the publisher's code signing certificate is valid, then timestamped before distribution.
Release artifact is prepared.
Publisher's private key creates signature.
Signing certificate is within its validity period.
Signing system sends required imprint data.
Trusted timestamp evidence is returned.
Signed and timestamped application is distributed.
Certificate later reaches its expiry date.
Verifier can evaluate the timestamp evidence and applicable rules.
The verifier does not simply see “expired certificate” and stop the analysis. It considers the signature, timestamp evidence, certificate status and the rules of the platform or signature format. That is why timestamping is best understood as part of the long-term validation story.
Common Timestamping Mistakes
Timestamp failures are often caused by treating the timestamp as a decorative field instead of a separate trust and operational dependency.
Long-lived software can lack independent signing-time evidence.
The request may fail or the returned evidence may not be usable.
They represent different parties and serve different purposes.
Timestamping does not automatically override every certificate-status problem.
Cryptographic choices should follow the requirements of the current ecosystem.
A successful signing command is not a substitute for checking the final artifact.
Pipeline reliability should include TSA availability and validation handling.
Related Resources
Follow the learning path from signing mechanics to certificates, chain validation and timestamp-specific troubleshooting.
Complete software signing process.
02 / CERTIFICATEWhat Is a Code Signing Certificate?Certificate and publisher identity.
03 / CHAINCode Signing Certificate Chain ExplainedRoot, intermediate and end-entity hierarchy.
04 / VERIFICATIONHow Software Signature Verification WorksHow signed software is checked.
05 / REQUIREMENTSCode Signing Certificate RequirementsRequirements for obtaining a certificate.
06 / TROUBLESHOOTINGCode Signing Timestamp ErrorsPractical timestamp troubleshooting.
Primary technical reference
RFC 3161 — Time-Stamp Protocol, for standardized timestamp-request and timestamp-token concepts.
Timestamping behavior can vary by signature format, operating system, signing technology and validation policy. This page explains the underlying model without treating timestamping as a guarantee of perpetual software validity.