Violation report - Comodo CA certificates revocation delays
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
Re: Incident Report - Misissuance of one certificate without DNS CAA authorization (Certigna)
On Sun, Sep 16, 2018 at 03:07:44PM -0700, josselin.allemandou--- via dev-security-policy wrote: > > 1. Can you explain in more detail the user experience of the RA interface > > which was used to misissue this certificate? Specifically, did approval > > of the issuance in the face of a CAA validation failure require a positive > > acknowledgement and override of the CAA validation failure, separate and > > distinct from the actions required to issue a certificate which passed CAA > > validation? > > The interface used by registration officer is dedicated to the processing > of certificate requests and is accessible with strong authentication with > a smartcard certificate. Via this interface, registration officer > operates and runs all the required checks for each FQDN requested. All > the manual controls to achieve are successively presented to the > registration operator so that he operates and acknowledges the validation > of each control. The results of automatic checks, such as CAA DNS and > DCV, are also presented to the operator in the validation workflow. > Previously, the CAA DNS control was the only one that was an alert and not > a blocking element for validating the request. The interface has been > fixed and the negative CAA DNS control result now blocks request > validation as for other controls. Was the action required to manually override the CAA validation failure different from what would be required if the CAA validation had succeeded? Could an operator have just "clicked the same button they always clicked", and have the CAA validation failure overridden? Or was there a separate sequence of UI interactions required to override a CAA validation failure? > We made an error regarding CAA DNS control and the fact that its result is > not blocking for validation. We assessed during the risk assessment that > the form of consent of the legal representative, and the control of the > CAA DNS with a warning prompted to the registration officer, would be > sufficient to limit the risks of obtaining the consent of the > organization. This certificate issuance showed that we should have set up > an automatic block as soon as the implementation of the control. Now the > automatic blocking is active and the wrong results of all controls are > blocking. This sounds like there may have been a misunderstanding in the BR description of CAA validation. What specific language in the BRs surrounding CAA validation caused you to believe that successful CAA validation was optional in the presence of other forms of consent? What changes do you propose in the language of the CAA validation requirements in the BRs to ensure that no other CA could possibly misunderstand the CAA validation requirements? Have you proposed those changes to the CA/B Forum, to improve the BRs for all participants? If not, why not? That the BRs have been misunderstood in this fashion is somewhat concerning. it suggests that there may be other misunderstandings latent in your systems and processes, which haven't surfaced because they haven't (yet) led to an identified misissuance or other incident. What steps have you taken, or are you planning on taking, to address possible misunderstandings of the BRs or Mozilla policy that may cause Certigna to unintentionally misissue a certificate or suffer from some other incident? > 4. Which other parts of the issuance process have been modified as a > result of the review of those risk analyses, in light of the failure of > the risk analysis around CAA override to correctly control for the > misissuance risk inherent in CAA override functionality being available to > RAs without sufficient compensating controls? > > 5. What compensating controls *were* in place to prevent misuse of this > manual CAA override? > > All controls results, manual as well as automatic, are now blocking for > validation of a request. Only the CAA DNS control was not blocking. The > risk assessment did not lead to action on the other controls. From now > on, even if the control methodologies differ from one set of requirements > to another, we will automatically ensure that validation is automatically > blocked until all controls are positive, even if the risk is considered to > be covered. by one of the methods used, and this also to ensure > compliance. It should be noted that control of consent is the only point > on which control practices were heterogeneous in our normative > requirements. For the other controls, the methodologies used are > homogeneous. This answer does not address the controls in place at the time of the misissuance. Any action which an operator can manually take should be able to be audited for correctness, but I don't see any mention of that being a possibility in your response. I take that to mean that there are no functional audit logs, or at least that there are no effective audits (sampling or otherwise) of those logs, for decisions and actions
Re: Incident Report - Misissuance of one certificate without DNS CAA authorization (Certigna)
Hello Thank you all for your feedback for which we have tried to provide additional information below. Know that if necessary, you will also find the description of our practices through the following links: • our CPS : * Services CA : http://politique.certigna.fr/en/DPCcertignaservicesca.pdf * Wild CA : http://politique.certigna.fr/en/DPCcertignawildca.pdf • Our BR self-assessment file :https://bugzilla.mozilla.org/attachment.cgi?id=9007984 Wayne: Thank you. We linked the ticket to the bug as requested. Tyler Schroder: We confirm that the certificate in question is the one that Tyler identified. It was revoked and we updated our CP / CPS to clarify the changes made following the incident and to provide additional information on other practices. > 1. Can you explain in more detail the user experience of the RA interface > which was used to misissue this certificate? Specifically, did approval > of the issuance in the face of a CAA validation failure require a positive > acknowledgement and override of the CAA validation failure, separate and > distinct from the actions required to issue a certificate which passed CAA > validation? The interface used by registration officer is dedicated to the processing of certificate requests and is accessible with strong authentication with a smartcard certificate. Via this interface, registration officer operates and runs all the required checks for each FQDN requested. All the manual controls to achieve are successively presented to the registration operator so that he operates and acknowledges the validation of each control. The results of automatic checks, such as CAA DNS and DCV, are also presented to the operator in the validation workflow. Previously, the CAA DNS control was the only one that was an alert and not a blocking element for validating the request. The interface has been fixed and the negative CAA DNS control result now blocks request validation as for other controls. > 2. What details can you share around the risk analysis that deemed it > appropriate to deploy a system where human operators were able to override > critical issuance controls without any oversight, approval, or subsequent > review of that override? 3. What other parts of the issuance process have had a similar risk > analysis undertaken with similar initial results? 6. In what specific ways did those compensating controls fail to properly manage the risk? > Are you saying that you don't account for the risk of possibly issuing a > certificate in contravention of the BRs and Mozilla policy? To clarify our risk assessment process. We perform a risk assessment on the perimeter of PKI at least once a year and before major changes. We employ an exhaustive methodology aligned with the EBIOS method and the guidelines of ISO/IEC 27005. Our risk management processes are audited both in accordance with the requirements of ETSI standards, BRs, but also ISO/IEC 27001, standard on which we are also certified. We therefore consider legal, regulatory, contractual and normative security requirements for the conduct of risk assessments, and therefore the risks of non-compliance with the requirements set out by the BRs. Our different risk assessments incorporate the analysis of risks related to the registration operator activities. The different iterations led to the establishment of the RA interface with a rigorous script to follow and to respect in order to limit any risk or non-compliance in the processing of requests. We made an error regarding CAA DNS control and the fact that its result is not blocking for validation. We assessed during the risk assessment that the form of consent of the legal representative, and the control of the CAA DNS with a warning prompted to the registration officer, would be sufficient to limit the risks of obtaining the consent of the organization. This certificate issuance showed that we should have set up an automatic block as soon as the implementation of the control. Now the automatic blocking is active and the wrong results of all controls are blocking. 4. Which other parts of the issuance process have been modified as a result of the review of those risk analyses, in light of the failure of the risk analysis around CAA override to correctly control for the misissuance risk inherent in CAA override functionality being available to RAs without sufficient compensating controls? 5. What compensating controls *were* in place to prevent misuse of this manual CAA override? All controls results, manual as well as automatic, are now blocking for validation of a request. Only the CAA DNS control was not blocking. The risk assessment did not lead to action on the other controls. From now on, even if the control methodologies differ from one set of requirements to another, we will automatically ensure that validation is automatically blocked until all controls are positive,
