Comodo: Failure to revoke within 24 hours

Assigned to


7 months ago
2 months ago


(Reporter: wayne, Assigned: Robin.Alden, NeedInfo)


Firefox Tracking Flags

(Not tracked)


(Whiteboard: [ca-compliance] Next Update - 24-January 2019)



7 months ago
The following message was sent to the list:
Hello, I am the domain owner of I would like to make you aware that Comodo CA took more than 5 days to revoke certificates they had signed for my domain and subdomains after requesting them to do through their sslabuse email address, past the 24 hours maximum mentioned in the Baseline Requirements as stipulated in section

For context, I was previously using Cloudflare's Universal SSL feature, but disabling it did not revoke the old certificates that had not yet expired, but simply removed them from its system, and some of the certificates were still valid for more than 6 months.

I first attempted to contact Cloudflare's support to ask them to revoke the certificates themselves on September 6 at 7:43 UTC. This only led to irrelevant responses and confused customer support agents that had no idea what I was talking about, and this appeared to go nowhere. I eventually got a response from them on September 11 at 5:53 UTC that they would request CAs to perform the revocation, but that was after I did so myself, and I never got a status report back afterwards.

There were two CAs affected by this issue. The vast majority of certificates were signed by Comodo CA, and the rest by DigiCert. I did not run into any issues with DigiCert (they in fact proactively checked with Cloudflare my claim and revoked the certificates before I even had the chance to attempt their domain ownership challenge), but Comodo CA was another story entirely.

My first request to Comodo CA to revoke the certificates for and all of its subdomains was on September 8 at 4:37 UTC. I did not get a reply until September 9 at 15:53 UTC stating that the certificates have been revoked. Not only was this past the 24 hours requirement, but it was also false, as only the most recent certificates had been revoked, not all of them. I mentioned to them their mistake on September 10 at 5:55 UTC with a full list of affected certificates just in case my initial request was unclear to them, and never got a reply back. I did, however, notice that the certificates eventually got revoked on September 13 at 16:04 UTC according to their Certificate Transparency logs, a fact that I only discovered on September 15. Assuming the log is correct, that would be a delay of more than 3 days after notifying them of the incomplete revocation, more than 5 days after my initial request to them, and more than a week until I finally noticed the problem was fixed. It's also worth noting that throughout this entire series of events, Comodo CA never requested proof of domain ownership beyond the evidence I initially provided, so that cannot explain the delays.

One detail that I'm not sure about is why my initial evidence for domain ownership was apparently sufficient for Comodo CA but not for DigiCert. On this regard, the only evidence I provided to both of them was that the email address I used to contact them matched the contact information on my website. (My emails were protected with SPF, DKIM and DMARC for authenticity.) For some reason, DigiCert believed that this evidence did not met the Baseline Requirements for my request, a claim that I am currently unable to verify as I cannot find anything of the sort in them.

You can read the full story on my blog, which I hope will be sufficient to prove my identity:

I can also provide a full copy of the email exchange I had with Comodo CA as evidence on request.

Guillaume Fortin-Debigaré
Since Comodo did eventually reply and revoke these certificates, just not within 24 hours, I believe we have evidence of a BR violation.

Please provide an incident report, as described here:
The incident report should be posted to the corresponding thread and added to this bug.

Comment 1

7 months ago
Robin, please respond to this.  Thanks.
Flags: needinfo?(Robin.Alden)

Comment 2

6 months ago
Robin: ping?


6 months ago
Assignee: Rob.Stradling → Robin.Alden

Comment 3

4 months ago
Using the incident report template from :

* How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in, a Bugzilla bug, or internal self-audit), and the time and date.

Sat 17-SEP-18 02:31 UTC
The revocation requester posted an email to
raising the complaint that a revocation request had taken too long to process.

* A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.

Sat 08-SEP-18 07:38 UTC	 email from the requester to requesting that we:
"revoke all valid and unexpired Comodo TLS certificates for, and * that were generated by Cloudflare"
Sun 09-SEP-18 15:52:04 UTC was revoked.
Sun 09-SEP-18 16:53 UTC  email from informing requester of revocation.
Mon 10-SEP-18 06:55 UTC  email from requester to
Thank you! Unfortunately, it appears that only a subset of them have been revoked, at least through OCSP.
To clarify, I'm expecting all entries from both linked lists below with "O=COMODO CA Limited" to be revoked.
Thu 13-Sep-18 16:04:56 UTC  all remaining certificates revoked.

* Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.

* A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.
One certificate was revoked 32 hours and 14 minutes after the request was received.
The remainder of the certificates were revoked 83 hours and 20 minutes after the clarification was received.

* The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.
The list of revoked certificates is above.

* Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

For the first certificate, our rep would have checked with Cloudflare that the requester was permitted to request the revocation.  
The BRs say in section
> The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs:
> 1. The Subscriber requests in writing that the CA revoke the Certificate;
The requester was not the subscriber.
Because of the time taken to check with an external party, plus the time taken by us to process the request, more than 24 hours elapsed from the requester's email.
We followed our usual process flow in revoking a single certificate in response to the request when we should have confirmed with the requester that multiple certificates were involved.

For the remaining certificates, we had to identify in our systems the list of certificates to be revoked and then revoke them.  The request was potentially ambiguous and processing it fell outside our usual work flow and it was passed to other staff for processing.  The urgency of the revocation request was not adequately communicated as the request was passed along.

* List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.

1) We have re-iterated to our staff the urgency of revocation requests being processed to completion.
2) We are re-evaluating our CPS and website language around revocation requests.  
We help our customers to help us revoke their certificates most easily and quickly when the revocation requests are clear, well defined and completely unambiguous.

Robin Alden
Sectigo Limited
Flags: needinfo?(Robin.Alden)

Comment 4

4 months ago
Robin: thank you for the incident report.

The reporter has requested clarification on what made his request ambiguous and difficult to process [1]?

Also, please update this bug with the results of action #2 in the incident report.

Flags: needinfo?(Robin.Alden)

Comment 5

4 months ago
(In reply to Wayne Thayer [:wayne] from comment #4)
> The reporter has requested clarification on what made his request ambiguous
> and difficult to process [1]?
> [1]
> CzrGuZJsBgAJ

I did not mean to criticize the requester's report.  His request was clear.
The ambiguity to which I referred was meant in the sense that it applied to our customer support representatives who responded to the request.  Their typical process flow in revoking is to identify a certificate and revoke it.
In this case we had to determine the entire list of affected certificates, check that the requester was the domain owner, and then revoke the certificates.  

> Also, please update this bug with the results of action #2 in the incident
> report.

We have not yet concluded the re-evaluation about our revocation process.

So far it seems clear that we would have saved ourselves a bunch of pain AND have more quickly enabled the requester to achieve his aim of revoking these certificates had we provided an automated mechanism by which he could have triggered the revocation himself.
We are defining a set of mechanisms which will:
a) allow domain owners to command revocation of certificates that include their domains
b) allow anyone to command revocation of certificates for which they control the private key.
These would operate in addition to the existing mechanisms that allow our customers to revoke certificates they have ordered.

Comment 6

3 months ago

Robin: Do you have updates from what's described in Comment #5? Do you have a date in which you'll be able to provide updates? Otherwise, it may be useful to switch to weekly updates, as described in

Comment 7

3 months ago

Robin: Can you provide an update?


Comment 8

3 months ago

We have the automated revocation mechanisms in outline form. I will post substantial details here by Thursday Jan 24th.


3 months ago
Whiteboard: [ca-compliance] → [ca-compliance] Next Update - 24-January 2019

Comment 9

2 months ago

Robin: it has been almost a month since you stated in comment #8 that you would provide more information.


Comment 10

2 months ago

Our Self-service revocation portal will support these methods:

#1 If the certificate you want revoked was ordered by you directly from Sectigo (or previously from Comodo CA), log into your account with us and select the certificate to be revoked.
This mechanism is in place and has been for a long time.

#2 If the certificate you want revoked is one for which you hold the private key either because you generated the key in the first place or because you found the key on the internet, you may do one of the following:

#2a create a revocation token by appending the certificate serial number to the string "REVOKE:".
E.g. "REVOKE:23:b5:72:50:18:7d:2f:83:03:9e:27:09:34:0b:4d:eb"
Use the private key to generate a SHA-256 based signature over the revocation token. Send us the revocation token and the signature and we will revoke the certificate.
Instructions on the use of openssl to accomplish this will be given in the portal.

#2b send us the Certificate and the private key and we will revoke the certificate.

#3 If the certificate you want revoked has a domain that you control in its subject (in a subjectAlternativename:dNSName entry), you may ask us to revoke the certificate by demonstrating your control of the domain.
The portal will list the supported means of demonstrating control and provide straight-forward instructions.
You may choose to revoke one or more certificates by providing the serial numbers of the certificates to be revoked, or to request the revocation of all certificates containing this domain.

The portal will note that #2b discloses the private key to us and means that the key is compromised, and will recommend the use of #2a by preference.

You need to log in before you can comment on or make changes to this bug.