Code Signing Certificate Revoked: What Breaks and What to Do Next

What does revoking a code signing certificate actually do?

It tells the world to stop trusting that certificate, from a date the CA records, permanently. The CA adds the certificate serial number to its certificate revocation list and to the answers its OCSP responder gives, along with a revocation date and a reason code. Verifiers that check revocation then treat the certificate as untrustworthy. Nothing is deleted and no file is altered; what changes is the answer everyone gets when they ask about the certificate.

Two properties of that operation surprise people. The first is that it cannot be undone. Certum states outright that revocation is irreversible and ends the subscriber agreement with no refund, and every other publicly trusted CA works the same way, because a revocation you could take back would be useless as a security control. The second is speed: a request submitted through the Certum panel is applied automatically within about an hour. There is no grace period in which to change your mind.

Revocation is also narrower than its reputation suggests. It acts on one certificate, not on your organization, your publisher identity, or your ability to buy another certificate. Teams sometimes delay revoking a compromised key because they imagine a blacklist that follows them around. There is no such thing. What a revocation does damage is the trust in signatures made with that specific key after the recorded date, and that is the cost worth thinking carefully about.

What breaks in software you already shipped?

Releases that were timestamped before the revocation date normally keep validating. Everything else stops. An RFC 3161 timestamp is a countersignature from the CA’s timestamp authority proving when the signature was made, and Microsoft documents that this is what lets a signature outlive the certificate behind it after expiry or revocation. Without one, a verifier has no evidence that the signature predates the problem, so it applies the revocation to the file in front of it.

This is where a good deal of published advice goes wrong. Some vendor documentation warns flatly that revoking invalidates all code signed with the certificate, timestamped or not. Read as a worst case that is fair enough, and if you are the one deciding whether to revoke, assume it. As a description of the mechanism it is too blunt: the Code Signing Baseline Requirements exist partly so that the split by date can be drawn, and the behaviour of Windows chain validation is to draw it.

Two caveats keep the picture honest. Some verifiers do not perform the timestamp comparison at all, particularly application control policies such as WDAC or AppLocker rules written to reject any revoked chain outright, and some installers and enterprise deployment tools take the same strict line. And a signature whose timestamp itself cannot be validated gets no benefit from it. The date split is the normal outcome rather than a guarantee that covers every environment your software lands in.

If you want the timestamp mechanism itself rather than the incident around it, our guide to code signing timestamping covers how the countersignature is built and why the lifetime signing option changes the answer.

Which revocation reason should you give the CA?

Give the one that is true, and understand that only the compromise answer changes what happens to your back catalogue. Revocation reasons come from the X.509 reason code list in RFC 5280, and the CA records the code you effectively selected in the CRL entry. Most of them behave identically from your releases’ point of view. The exception is keyCompromise, because it is the reason that justifies setting the revocation date in the past.

The backdating provision is the part worth understanding before you file anything. The Code Signing Baseline Requirements allow a CA to record a revocation date earlier than the moment it processes the revocation, so the date can be placed before the key was exposed or before suspect code was signed. Anything timestamped after that date stops being trusted, which is exactly the intent when someone else has been signing with your key. It also means the date you supply determines how much of your own work you throw away, so bring an evidence-backed timeline rather than a guess.

CA interfaces rarely show these labels. You will more often see a short list in plain language, or a free-text field on a revocation form, and the CA maps your answer onto a code. Say explicitly whether the key was exposed and when, because that sentence is what the mapping turns on.

When are you required to revoke, and how fast?

Within 24 hours for compromise and suspect code, and within a window measured in days for everything else. Ballot CSC-18 revised the revocation section of the Code Signing Baseline Requirements in 2023 to align its reasons with the TLS rules and to impose the stricter deadline where it matters: once a CA confirms that a private key was compromised, or that the certificate signed suspect code, it must revoke within 24 hours. Slower circumstances, such as details in the certificate becoming inaccurate, allow a longer window.

Those deadlines bind the CA, and they start when the CA confirms the problem, not when you first suspect it. The practical consequence runs the other way: your reporting speed sets the clock. A team that spends three days deciding whether a lost laptop counted as key exposure has given away three days during which the key was live and nobody outside the company knew.

Situations that genuinely require revocation are narrower than the anxious version and wider than the complacent one. Revoke when the key or its activation credentials left your control, when a token or HSM is missing and unaccounted for, when someone who could sign has left under circumstances you cannot verify, when the certificate was issued on information that turned out to be wrong, and when you discover something was signed that should not have been. Ordinary events do not qualify: an expiring certificate, a routine replacement, or a developer changing machines are not revocation triggers.

What do users and build systems actually see?

On Windows, the characteristic result code is 0x800B010C, CERT_E_REVOKED, described as a certificate explicitly revoked by its issuer. It surfaces during installation, when an application control policy evaluates a binary, or when someone runs signtool verify /pa /v against the file. The signature and the file are both intact when this appears, which is why re-downloading, clearing caches, or repairing the installation never resolves it.

The reports you get from users will rarely mention a code at all. Expect “it says the publisher could not be verified”, an installer that stops without explaining itself, or a deployment tool that quietly refuses a package it accepted last month. Kernel-mode drivers fail hardest and earliest, because driver signature enforcement rejects a revoked chain at load time rather than at install time.

Rollout is uneven, which makes early reports confusing. CRLs are cached, OCSP responses carry their own validity windows, and a machine that checked yesterday may keep accepting the file for hours after the revocation is published. Machines with no outbound access to the revocation endpoints may not notice for longer still. Treat scattered reports as the leading edge rather than the extent of the problem, and confirm the state yourself with a direct signature check on a clean machine.

How do you revoke a code signing certificate?

Through the CA that issued it, and for Certum certificates there are three routes. The fastest is the customer panel at panel.certum.pl: open the certificate under your data security products, use the revocation option in the item menu, and confirm. Certum applies a revocation requested this way automatically within about an hour. The alternatives are a signed revocation letter sent by registered post and a dedicated revocation form, both of which exist for cases where panel access itself is part of the problem.

Before you confirm, write down three things: the reason, the date from which the certificate should be considered untrustworthy, and the evidence behind that date. Panel flows tend to collect only the reason, so if you need the revocation backdated to a compromise, raise it with the CA in writing rather than assuming the form handles it. Getting this right at the point of submission is much easier than arguing about a recorded date afterwards.

One thing to sort out first if you can: whether anyone still needs to sign something with the outgoing certificate. Once the revocation lands, a signature made afterwards is worthless, and the ability to produce one at all depends on whether the key is still reachable. Compromise cases override this entirely, and you revoke immediately. For every other reason, finishing the release in flight before you revoke saves a genuinely annoying week.

What is the recovery sequence after revocation?

Contain, revoke, re-key, re-sign, re-publish. The order is the point: containment and revocation take minutes and stop the bleeding, while obtaining a replacement certificate takes days and cannot be rushed. Teams that treat the replacement as step one, because it feels like progress, leave a compromised key signing for the whole of that lead time.

Re-keying is more involved than it was before the hardware mandate. Since June 1, 2023, the private key of every publicly trusted code signing certificate has had to be generated and stored in hardware meeting FIPS 140-2 Level 2 or Common Criteria EAL 4+, and marked non-exportable. A replacement therefore means a new token in the post, a new key in an HSM you run, or a new credential on a cloud signing service. The organization details you already had validated are often reusable, which is the part of the timeline you can actually shorten.

If the replacement is going to a build pipeline, this is the moment to reconsider the delivery model rather than reorder what you had. A token that must be physically present is what turns a certificate incident into a fortnight of manual signing. Our Certum code signing certificates are available with cloud key storage as well as a physical token, so a replacement key can be reachable from a build agent on the day it is issued.

Re-signing comes last and is narrower than it looks. You only need to re-sign what actually fell on the wrong side of the revocation date and is still being downloaded or installed. Sign each of those with the new certificate, timestamp them, and replace the artifacts customers reach: release pages, update feeds, package repositories, and any installer mirrored by a third party. Then verify one from a clean machine, because the copy your build server produced is not the copy your customers get.

How do you limit the damage before it happens?

Timestamp every signature, and know which key signed which release. Those two habits decide almost everything about how bad a revocation is. Timestamping is what preserves the releases that predate the incident; a signing record is what tells you, on the day, which builds you have to re-issue rather than re-issuing the entire catalogue because nobody is sure.

• Make timestamping non-optional in the pipeline. Fail the build when the timestamp step fails instead of letting it warn and continue. An untimestamped release is a liability that only shows up years later, at the worst possible moment.
• Keep a signing log. Which certificate, which key, which artifact, which date. Cloud signing services give you this for free; a token in a drawer gives you nothing unless someone writes it down.
• Separate the keys that have different blast radii. A key used for internal tooling and a key used for the installer a hundred thousand customers run should not be the same key, because one incident then forces one decision about both.
• Treat certificate custody as an offboarding step. Most revocations we see are not dramatic breaches. They are a token nobody can find after someone left, which is a paperwork problem that became a cryptographic one.
• Rehearse the first hour. Know who can log into the CA panel, who decides, and where the incident timeline gets written. The 24-hour rule is generous only if the first hour is not spent looking for a password.

Shorter certificate lifetimes have quietly helped here. Certificates issued on or after March 1, 2026 are capped at 460 days under ballot CSC-31, so the window in which any single key accumulates signatures is smaller than it used to be. The renewal rhythm that came with that change is covered in our breakdown of code signing certificate validity.