Summary

  • Rotating or renewing a code-signing certificate changes which key signs future releases; it does not by itself invalidate binaries that were signed and validly timestamped before the old certificate expired.
  • Treat the cutover as an artifact-authority reconciliation: join every binary hash to its signer, RFC 3161 token, effective revocation time, distribution location and observed verifier result.

At noon, a software publisher moves its release pipeline to a replacement code-signing certificate. The first new build signs correctly. The dashboard turns green. Yet a binary produced the previous evening remains on a regional mirror, carries a valid timestamp and still verifies on customer machines.

Nothing in that sequence is necessarily broken. The error would be to call the certificate change a completed trust cutover.

Code signing answers whether software is linked to a signing identity and whether its signed bytes have changed. Timestamping adds another statement: a trusted Timestamp Authority attests that a hash existed at a particular time. Together, those records can allow a verifier to accept a signature after the signer certificate's ordinary expiry. They can also divide a compromised certificate's output into code signed before and after an effective revocation time.

That is why a code-signing certificate has two operational end dates. One is its expiry: after that boundary, a newly produced signature will not ordinarily validate as having been made while the certificate was valid, even though software may still be able to compute signature bytes with the private key. The other is the time from which a verifier should no longer accept the certificate's signing authority. The two dates can be identical, but the trust model does not require them to be.

What the timestamp actually proves

RFC 3161 defines a Time-Stamp Protocol around a MessageImprint: a hash-algorithm identifier and the hash value of the data presented to the Timestamp Authority. The authority checks the algorithm and length, but it does not inspect the underlying program. Its token carries a policy, a unique serial number and genTime, and it is signed with a key dedicated to timestamping.

The token therefore proves less—and more—than a generic “signed at” label. It proves that a particular imprint was presented under a stated timestamp policy. It does not prove that the code was safe, that the publisher controlled every signing path or that a mirror now serves the intended version.

Verification remains active work. RFC 3161 requires the requester to check the response, Timestamp Authority certificate, data imprint, hash algorithm, signature and timing. Microsoft exposes the same separation in SignTool: sign, timestamp and verify are distinct commands. Its RFC 3161 route uses /tr for the timestamp server and /td for the timestamp digest. Verification can check the signer chain and revocation status rather than merely report that a signature blob exists.

Microsoft's ClickOnce documentation gives the practical consequence directly. A valid timestamp can allow an application to remain accepted after its signing certificate expires. That is useful: publishers should not have to re-sign every sound historical package whenever a certificate reaches its planned end. But the same durability means rotation cannot be measured only by whether the next release uses a new key.

Revocation creates a time boundary

The CA/Browser Forum's Code Signing Baseline Requirements address publicly trusted code-signing certificates and their Timestamp Authorities. They require CAs that issue these certificates to operate an RFC 3161-compliant timestamp service, recommend timestamp use and reject SHA-1 message imprints.

The requirements also explain why revocation is not a simple delete operation. One certificate may have signed one entity or thousands. Revoking it can invalidate sound code along with suspect code. A CA must begin investigating plausible certificate problem reports within twenty-four hours, and for key compromise the effective revocation date should be the earliest suspected compromise.

That date can time-bind the affected software. The requirements say software should continue to treat entities carrying a timestamp before the revocation date as valid. This is not a promise that every platform behaves identically. It is a rule for separating artifact populations by evidence rather than by filename or release channel.

The Timestamp Authority has its own failure boundary. RFC 3161 distinguishes ordinary retirement from key compromise. If a timestamping key is retired without compromise and the revocation reason is expressed correctly, earlier tokens may remain valid. If the key itself is compromised, the tokens it produced cannot simply be trusted; audit records or an independent second timestamp may matter.

The operational denominator is every distributed artifact

A certificate inventory is not enough. The publisher needs to know which artifacts were signed, which timestamp token is attached, where each artifact remains obtainable and how target verifiers treat it.

That denominator includes primary downloads, package repositories, content-delivery caches, enterprise software stores, update channels, offline installers and recovery images. Removing a binary from the newest download page does not withdraw it from any of the others. Conversely, revoking a certificate without locating sound old packages can turn a security response into an avoidable continuity failure.

The minimum control is an artifact-authority cutover ledger. For each cryptographic artifact hash, record the build and release, signer certificate fingerprint and serial, signing digest, timestamp token and authority, genTime, certificate expiry, revocation status and effective revocation time. Join those fields to every distribution location, withdrawal or replacement state, verifier policy and observed acceptance or rejection.

The ledger makes the completion test falsifiable. The cutover is complete only when future production uses the intended signer, every retained old artifact has an explicit trust decision, every withdrawn artifact is absent from the controlled distribution surfaces, and representative verifiers produce the expected result.

Evidence boundary

RFC 3161 specifies token and verification mechanics; it does not certify a particular Timestamp Authority. The CA/Browser Forum requirements govern a public code-signing baseline; they do not make every operating system or package manager identical. Microsoft documentation establishes documented SignTool, Authenticode and ClickOnce behaviour, not the behaviour of every software ecosystem.

No compromise is alleged here. The point is narrower: certificate expiry, certificate rotation, certificate revocation and timestamp-authority failure are different events. A defensible cutover keeps them different in both the evidence and the decision.

Sources