I have created a bug and requested a response from Comodo: https://bugzilla.mozilla.org/show_bug.cgi?id=1492006
As noted, there are no specific requirements regarding how CAs validate revocation requests in the BRs. Every CA may do this however they choose, so I don't believe there is any action required in regard to DigiCert's response to their problem report. - Wayne On Sun, Sep 16, 2018 at 8:30 PM please please via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hello, I am the domain owner of debigare.com. 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 4.9.1.1. > > 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 debigare.com > 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: > https://www.debigare.com/4-unexpected-issues-i-encountered-upon-switching-web-hosts/ > > I can also provide a full copy of the email exchange I had with Comodo CA > as evidence on request. > > Guillaume Fortin-Debigaré > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy