Certificate Problem Reports: Who Can Start Your Revocation Clock

What a Certificate Problem Report is

The Baseline Requirements define a Certificate Problem Report as a complaint of suspected Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates. Stripped of the capital letters, it is the one channel through which anybody can tell a CA that a certificate it signed is wrong, and oblige it to look.

The definition is broader than most people expect. Key compromise is the obvious case, and it is the one CAs get asked about most. Misuse covers a certificate being used for something the subscriber agreement forbids. But the catch-all at the end sweeps in a large category that has nothing to do with bad faith: a certificate whose contents are simply inaccurate, or one that was issued in a way the rules did not permit. Most reports filed against ordinary, well-run organizations land here.

That is the part worth internalising. A report is not an accusation that you did something wrong. In the large revocation events of recent years, the defect was on the CA's side of the line, and the subscribers who had to replace thousands of certificates at short notice had done nothing at all. The rules do not distinguish. The certificate is non-compliant, so the certificate goes.

Who can file one against your certificate

Section 4.9.2 names four groups who may submit a Certificate Problem Report: Subscribers, Relying Parties, Application Software Suppliers, and other third parties. The final category has no membership requirement, which means a security researcher, a competitor, a customer, or a stranger with a certificate parser and a free afternoon all qualify. Your permission is not part of the process.

Section 4.9.3 backs that up with an obligation on the CA. It must maintain a continuous 24x7 ability to accept and respond to revocation requests and Certificate Problem Reports, and it must publish clear reporting instructions both online and in Section 1.5.2 of its Certification Practice Statement. Every publicly trusted CA therefore has a documented address where reports go, and it is not hard to find. That is by design: the whole accountability model of the public web PKI rests on outsiders being able to raise the alarm.

In practice the reports that move fastest come from people the CA has reason to take seriously. Section 4.9.5 tells the CA to weigh who filed, and singles out a complaint from a law enforcement official as carrying more weight than a consumer complaining about a delivery. Reports from browser root programs, from researchers with a track record, and from automated monitoring of Certificate Transparency logs sit near the top of that scale. An anonymous grievance about a business dispute sits near the bottom, and is disposed of accordingly.

The two clocks: 24 hours and 5 days

Section 4.9.1.1 splits revocation into two tiers. Five reasons oblige the CA to revoke within 24 hours. Eleven more carry a SHOULD at 24 hours and a MUST at 5 days. Which tier you land in is decided by the nature of the defect rather than by how inconvenient revocation would be, and the CA does not get to reclassify a reason to buy itself room.

The 24-hour tier covers the cases where a certificate has stopped being trustworthy in the cryptographic sense. You asked for revocation in writing. You told the CA the original request was not authorized. The CA has evidence your private key was compromised, or that the key can be computed from the public key, or that the domain validation behind the certificate should not be relied upon, which is the clause that covers a CAA check the CA got wrong.

The 5-day tier is longer and, for most subscribers, more relevant. It covers keys that no longer meet the size and quality rules, evidence of misuse, a breach of the subscriber agreement, a domain name you are no longer legally entitled to use, a wildcard used to authenticate a fraudulently misleading subdomain, a material change in the information in the certificate, issuance not in accordance with the Requirements, and information in the certificate that turns out to be inaccurate. That last pair is where almost every large revocation event of the past few years has started.

What the CA owes you in the first 24 hours

Section 4.9.5 gives the CA a single day to investigate the facts and circumstances and to provide a preliminary report on its findings to both the subscriber and the entity who filed. Two details in that sentence are easy to skim past and both matter: the report goes to both sides, and the 24 hours run from receipt rather than from the moment somebody at the CA opens the ticket.

Getting that preliminary report is the first moment you learn any of this is happening, which puts a surprising amount of weight on an administrative detail: the contact address recorded on the order. CAs send these notices to the technical or administrative contact for the certificate. If that address belongs to a colleague who left two years ago, or to a shared mailbox that nobody has opened since the last renewal, the first you will hear about the report is when monitoring tells you the certificate has gone.

It is worth auditing that field the way you would audit a domain's registrant contact. Point it at a monitored distribution list rather than a person, make sure someone reads it at weekends, and check it covers the certificates issued before whoever runs PKI today was hired. None of this is difficult. It is simply the sort of task that never becomes urgent until the day it becomes the only thing that matters.

Whether the deadline can be moved

The short version: you can influence the date, and you cannot move the deadline. Section 4.9.5 obliges the CA to work with the subscriber and the reporter to establish whether the certificate will be revoked and, if so, on what date. The same paragraph then closes the door: the period from receipt of the report to published revocation must not exceed the timeframe in Section 4.9.1.1.

So the conversation with your CA is real, and it is narrower than most subscribers hope. You can argue that the report is wrong on the facts, which is the only argument that actually stops revocation. You can ask for the revocation to be timed for a maintenance window rather than mid-afternoon. What you cannot do is buy a fortnight, and a CA that gives you one has created an incident of its own that it will have to disclose.

That constraint explains behaviour that looks unreasonable from the outside. When a CA tells a bank with four thousand certificates that they all go in five days, it is not being inflexible about a policy it wrote. It is obeying a rule its root program membership depends on, and the alternative is distrust of the CA itself, which would take those four thousand certificates down anyway along with everyone else's.

Section 4.9.5 does list five criteria the CA should weigh when choosing the date: the nature of the alleged problem, the consequences of revocation, how many reports it has received about that certificate or subscriber, who is making the complaint, and relevant legislation. Those criteria decide where inside the window you land. They have no bearing on where the window ends.

Three rulebooks, three different answers

The CA/Browser Forum maintains separate Baseline Requirements for TLS, S/MIME and code signing, and their revocation sections have drifted apart. The 5-day outer deadline is common to all three. What differs is the list of reasons that trigger the 24-hour tier, and whether the CA has any room to delay at all.

The S/MIME Baseline Requirements (v1.0.15, dated 30 July 2026) track the TLS text closely. Five reasons at 24 hours, ten more at 5 days, with the domain-control clause rewritten to cover mailbox control instead. If you manage email certificates, read the TLS rules and mentally substitute the mailbox address for the domain name and you will be close enough.

Code signing is the one that genuinely diverges. Version 3.11.0 of the Code Signing Baseline Requirements adds a sixth 24-hour reason with no TLS equivalent: reasonable assurance that a certificate was used to sign Suspect Code, defined as code containing malicious functionality or serious vulnerabilities. It also names Anti-Malware Organizations alongside the usual reporters, and requires the CA to acknowledge plausible notices about suspect code signed under its hierarchy.

Then comes the clause that exists nowhere else. The CA may delay revocation at the request of an Application Software Supplier where immediate revocation would have a potentially large negative impact on the ecosystem. Section 4.9.5 goes further and asks the CA to work with the subscriber to estimate a revocation date that limits the damage to code that was signed legitimately — and for key compromise, to use the earliest date of suspected compromise. The logic is proportionality. Revoking a TLS certificate breaks one deployment; revoking a signing certificate can invalidate every copy of your software already installed. If you ship signed binaries, that asymmetry is the single strongest argument for keeping your signing key on certified hardware and timestamping every signature, because both decisions change what survives a revocation date.

Shrinking your exposure before it happens

Nothing you do stops someone filing a report, and nothing you do buys time once one lands. What you can change is how much a five-day deadline costs you. That comes down to three things: how quickly you can reissue, how completely you know where your certificates are installed, and how long each certificate is exposed in the first place.

Reissue speed is the one most organizations underestimate. A domain-validated certificate can be reordered and reissued in minutes. An organization-validated or extended-validation certificate needs the organization data to still be current with the CA, and if the vetting has gone stale, revalidation is not a five-day job. Knowing which of your certificates would need fresh paperwork is worth an afternoon of somebody's time well before you need the answer.

Inventory is the second. The deadline applies per certificate, not per server, so a certificate installed on a load balancer, two application servers and a forgotten staging box has to be replaced in four places. Organizations that discover the fourth place during a revocation event tend to discover it via an outage. If you cannot produce that list today, start with what your CA's account shows and reconcile it against Certificate Transparency.

Certificate lifetime is the third, and it is moving whether or not you act. Certificates issued on or after 15 March 2026 cap at 200 days, dropping to 100 days from March 2027 and 47 days from March 2029. Shorter lifetimes mean any given certificate spends less time exposed to a report. They also force the automation that makes a five-day replacement unremarkable, which is the real benefit. There is even an explicit exemption at the bottom of the scale: Section 4.9.1.1 opens by saying a CA may support revocation of Short-lived Subscriber Certificates, meaning 7 days or less since 15 March 2026 — the only category where mandatory revocation does not apply at all.

One last habit worth building. Read the preliminary report carefully rather than forwarding it to whoever owns the server. It names the reason code the CA is working from, and the reason code tells you which deadline you are on and whether the problem is yours, your CA's, or a misunderstanding you can correct with evidence in the first 24 hours. That distinction is usually visible in the first paragraph, and it decides everything you do next.