Perhaps more concerning, this sounds a lot like bug #1462844 in which misissued certificates were reported that had not been found and revoked despite GoDaddy having previously scanned their database for the issue. GoDaddy never identified or described how they would remediate the cause of that bug.
On Fri, Feb 8, 2019 at 1:28 PM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Thanks Joanna, > > Just to make sure - this is > https://bugzilla.mozilla.org/show_bug.cgi?id=1524815 correct? > > If so, this sounds remarkably similar to the root cause analysis that > Entrust shared, in https://bugzilla.mozilla.org/show_bug.cgi?id=1521520 . > Similar to that issue, please provide an update as to what steps are being > taken to ensure that future compliance objectives are met - that is, what > process changes have been made with respect to the data sources you use, > how tools will be reviewed that use those data sources, and what steps may > be taken to improve the quality and accuracy of those data sources (e.g. > disclosing active certificates to CT) > > While Mozilla policy does not require or mandate the disclosure to CT, > those non-active certificates are still relevant to the BR expectations of > compliance, and should they be discovered (e.g. via auditors or if they > were to be shared outside GoDaddy), the BR non-compliance may appear > significantly worse to the community. Rather than not logging non-active > certificates, it may be more useful to approach this by ensuring your tools > consider both active and non-active certificates - that is, anything that > has been signed with the CA's private key. > > On Fri, Feb 8, 2019 at 2:44 PM Joanna Fox via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > GoDaddy received a certificate problem report on 1/29/2019 for 2 > unrevoked > > unexpired certificates have underscores in the DNS name that did not meet > > the January 15th deadline for revocation. The certificates reported are > as > > follows: > > https://crt.sh/?opt=zlint&id=626981823 > > https://crt.sh/?opt=zlint&id=637047181 > > > > 1. How your CA first became aware of the problem (e.g. via a problem > > report submitted to your Problem Reporting Mechanism, a discussion in > > mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and > > the time and date. > > > > Certificate Problem Reporting via email address supplied in CP/CPS on > > Tuesday, January 29, 2019 11:18:42 AM > > > > 2. 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. > > > > 1/29/2019 11:18:42 AM AZ time Problem Report received by GoDaddy > > 1/29/2019 3:55 PM AZ time Problem report was viewed by an agent and > > escalated appropriately. > > 1/29/2019 to 1/30/2019 Researched as to why these certificates were not > > caught in the initial data set for underscore revocation. > > 1/30/2019 Identified root cause as order of an operation problem where > > certificates could be CT logged but never be delivered to the certificate > > requester. > > 1/30/2019 23:36:32 UTC and 1/30/2019 23:35:55 UTC Certificates that were > > reported are revoked. > > > > 3. 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. > > > > We have prevented new certificates with underscores from being > provisioned > > since November 8, 2018. > > > > 4. 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 crt.sh IDs, either in the report > or > > as an attached spreadsheet, with one list per distinct problem. > > > > https://crt.sh/?opt=zlint&id=626981823 > > https://crt.sh/?opt=zlint&id=637047181 > > > > 5. Explanation about how and why the mistakes were made or bugs > > introduced, and how they avoided detection until now. > > > > Our initial effort to bring underscore certificates into compliance was > > dependent upon an ‘active’ flag in our database. In rare cases, due to an > > order of operation problem, non-active certificates were being logged to > > CT. These non-active certificates were fully vetted meeting the BR > > standards but failed to be delivered to the certificate requester due to > a > > software defect. > > > > 6. 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. > > > > We have prevented new certificates with underscores from being > provisioned > > since November 8, 2018. These non-active certificates were revoked and we > > are taking steps to prevent non-active certificates from being logged to > CT > > within the next 2 weeks. > > _______________________________________________ > > 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 > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
