Code Signing Timestamps: Why Your Signature Outlives Your Certificate

What a code signing timestamp actually is

A code signing timestamp is a countersignature: a timestamp authority — a service run by a CA — signs a statement that says "this signature existed at this moment," using its own long-lived certificate. It rides inside your file next to your signature, so any copy, anywhere, carries its own proof of when it was signed. No lookup, no phoning home.

To see why that proof matters, look at what a verifier has to decide. When Windows checks a signed file, the question is never just "is this signature mathematically correct?" — it's "was the certificate behind it valid at the time of signing?" Without a timestamp, Windows has no idea when signing happened, so it falls back to the only date it can check: today. The day your certificate expires, that check starts failing for every file you ever signed with it. Microsoft's own documentation is blunt about the fix: time stamping is what allows Authenticode signatures to stay verifiable after the certificate expires.

One mental model that helps: the certificate answers who signed, the timestamp answers when. Identity needs to be re-verified every year or so — that's why certificates expire at all — but a moment in time, once honestly recorded, never needs renewing. Of the two, only the timestamp ages well, and that asymmetry is the whole reason it exists.

How RFC 3161 timestamping works

RFC 3161 is the internet standard for trusted timestamping. During signing, your tool hashes the signature and sends that hash to a timestamp authority. The TSA signs the hash together with the current time using its own certificate and returns the result — a timestamp token — which your tool embeds in the file as a countersignature. Your file never travels; only a hash does.

Two properties of this exchange are worth noticing. First, the TSA can't lie about what it saw: it only ever receives a hash, so it learns nothing about your software, and it can't retroactively stamp a different file with the same token. Second, you can't lie about the time: the clock belongs to the TSA, not to your build machine, so setting your PC's date back to 2024 changes nothing. That's what makes the timestamp evidence rather than a claim — and it's why verifiers accept it from files signed by certificates that died years ago.

The TSAs you'll meet in practice are run by the same CAs that issue certificates. Certum answers at http://time.certum.pl, DigiCert at http://timestamp.digicert.com, Sectigo at http://timestamp.sectigo.com — all free, all open to anyone regardless of where you bought your certificate. The plain-HTTP URLs look alarming but aren't a problem: the token is signed by the TSA, so tampering in transit would just produce an invalid token.

Certificate expiry and the new 460-day rule

Code signing certificates have never been allowed to live forever, and the ceiling just dropped hard: as of March 1, 2026, the CA/Browser Forum's ballot CSC-31 caps new publicly trusted code signing certificates at 460 days — about 15 months — replacing the old 39-month maximum. Certificates issued before that date keep their original term, but every renewal from now on lands under the new limit.

Software, meanwhile, refuses to age on the CA's schedule. Users run installers they downloaded years ago; enterprises pin approved versions and roll them out long after you've moved on. Under the 39-month rule, an untimestamped signature had up to three years before the cliff. Under 460 days, the same oversight breaks your back catalog roughly twice as fast — and each renewal resets nothing for files signed with the old key, because a new certificate can't retroactively vouch for old signatures. The industry's direction of travel is shorter still: TLS certificates are already headed toward 47-day lifetimes, and code signing tends to follow the same logic a few years behind. The shorter certificates get, the more the burden of long-term trust shifts onto the timestamp.

There's a second, quieter benefit. When a certificate is revoked — say, after a key compromise — the CA records a revocation date, and timestamps let verifiers distinguish signatures made before that date from ones made after. Your legitimate releases from last spring can stay trusted while anything signed after the compromise is rejected. Without timestamps, that line can't be drawn, and revocation takes your whole signing history down with it. This pairs with how SmartScreen reputation accrues to your certificate: both systems reward publishers whose signing history is legible.

How to add a timestamp

Every mainstream signing tool takes the timestamp server as a flag on the signing command: SignTool uses /tr with /td SHA256, PowerShell's Set-AuthenticodeSignature takes -TimestampServer, and Java's jarsigner takes -tsa. One flag, one extra network round-trip, and the token is embedded automatically.

:: SignTool — sign and timestamp in one go
signtool sign /fd SHA256 /tr http://time.certum.pl /td SHA256 /a MyApp.exe

:: SignTool — add a timestamp to an already-signed file
signtool timestamp /tr http://time.certum.pl /td SHA256 MyApp.exe

# PowerShell
Set-AuthenticodeSignature -FilePath .\Deploy.ps1 `
  -Certificate $cert -TimestampServer "http://time.certum.pl"

# jarsigner
jarsigner -tsa http://time.certum.pl -keystore ks.p12 MyApp.jar mykey

The full context for each command lives in our step-by-step guides — signing an EXE with SignTool, signing a PowerShell script, and signing a JAR with jarsigner — including the errors each tool throws when the timestamp server is unreachable. Which server you point at is genuinely a matter of taste; it does not need to match your certificate's CA. If your certificate is a Certum code signing certificate from My-SSL, Certum's own time.certum.pl is the natural pick, and it costs nothing extra to use — timestamping is included in how the service is meant to be used, not an add-on.

Verification is one command too: signtool verify /pa /v MyApp.exe prints "The signature is timestamped" with the date, and Get-AuthenticodeSignature exposes a TimeStamperCertificate property. If those come back empty, the file will stop verifying when the certificate does.

When a timestamp doesn't save you

A timestamp protects signatures against exactly one thing: the certificate reaching its natural expiry date. It does not protect against revocation that's backdated to before you signed, it's overridden by the lifetime-signing option, and it obviously can't help a file that never got one. Knowing the failure cases is what separates relying on timestamps from merely using them.

The revocation case deserves the most attention. When a CA revokes a certificate, it records the date the certificate stopped being trustworthy — and if your key was stolen, the CA backdates that to the compromise, not to the day anyone noticed. Signatures timestamped before the revocation date survive; anything stamped after it fails, including the malware the thief signed. That's the system working as designed. It's also why key custody matters as much as any flag — where your key physically lives is the subject of our cloud signing vs USB token comparison.

The lifetime-signing case is more obscure. Windows defines a special extended key usage (Microsoft documents it as the "lifetime signer" OID) that tells verifiers to enforce certificate expiry even when a valid timestamp is present — used when a publisher deliberately wants signatures to die with the certificate, most commonly in kernel-mode scenarios. You won't get it by accident on a standard OV or EV certificate; if you're evaluating certificates and see it mentioned, it means expiry behavior you should ask about before buying.

Timestamping habits that pay off

Treat the timestamp as part of the signature, not an option: bake the flag into every signing script, have CI fail the build when timestamping fails, verify the token is present before release, and keep a fallback TSA URL for the day your usual one is briefly down. Each habit costs a line of script; skipping any of them costs a support fire on a date you don't control.

• Put the flag in the script, not in your memory. Timestamping only works if it happens every time. The signing command in your pipeline should carry /tr and /td SHA256 permanently — a release signed by hand at 11 p.m. is exactly the one that forgets.
• Fail the build if the timestamp fails. TSAs are ordinary web services and occasionally time out. SignTool exits non-zero when timestamping fails, so let that stop the pipeline; a signed-but-unstamped artifact slipping through is the failure mode you'll discover in two years, not two minutes.
• Keep a second TSA URL handy. Any RFC 3161 server works with any certificate, so a retry against DigiCert's or Sectigo's endpoint is a perfectly good plan B when your usual server is unreachable mid-release.
• Verify before you publish. A one-line check — signtool verify /pa /v — confirms both the signature and the timestamp. Make it the last step of the release job rather than a thing someone does when a customer complains.