Thanks for your comment. For Github case: 1. what happened: issued the certificate that included un-validated domain, and found out this mistake in the next day review, and revoked this certificate. 2. why this happened: this is bug as you described, and due to many orders need to review manually, so the first day missed and issued; the next day second same order come and found out, then rejected. 3. what is being done to prevent this in the future: We fixed this bug, and we changed the github setting from "flag" to "reject" for class 1 and class 2 order to reduce the manual check mistake.
For Figure 13, this subscriber finished the domain control validation for domain: netwi.ru, this means the domain: mail. netwi.ru and mx.netwi.ru are validated; and it finished the website control validation for domain: mail.idisk.su, so only 1 domain mx.idisk.su not validated. We can past the process log screenshot for this order in the next report that still preparing. Best Regards, Richard -----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+richard=wosign....@lists.mozilla.org] On Behalf Of Kurt Roeckx Sent: Tuesday, September 6, 2016 4:56 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Incidents involving the CA WoSign On 2016-09-05 22:37, Percy wrote: > In page 11, you mentioned that "System blocked many illegal request every > day, the following screen shot is the reject order log", in which you > attached a log with Google, Microsoft, QQ domains. Those domains are rejected > because of the top domain whitelist. Does that mean those attempts passed > your automatic validation and were only rejected because of the whitelist? > > And as Kurt pointed out, for the flag, why does it happen only AFTER the > certificate is already issued? Since you specifically have the whitelist for > topdomains, you would know mis-used of such certs have particularly high > impacts. I think that was a misunderstanding on my part. In the other e-mail I send I came to the conclusion that what probably happened was that they were flagged for manual review and approved. And so that there really is something wrong with the manual review process. Their solution to that was to move "github.com" from manual review to reject. The document really is hard to follow and seems to more concentrate on defending themselves, how fast they are and show that they do prevent some certificates from being issued. What I'm looking for is just the facts of what happened, why this happened, what is being done to prevent this in the future. My current understanding of what happened with the github.com case is: - It's possible that the list of hostnames is changed between the point of validation and the user pressed the "submit request" button. This change can be caused by both the software adding other hostnames itself, or the user adding new hostnames. I understand that when the user pressed the button a CSR is generated. - Once the CSR is generated, it's trusted that the list of hostnames in it have been validated, which might not be the case. - Because gibhub.com is in the list of hostnames that needs to be checked, it's flagged for review. - The manual review just approved it. What I think is wrong: - There is no check that the hostnames have been validated after the CSR has been generated. - Too many github.com certificates get flagged for manual review causing the reviewers to not look careful and just approve it. The fix they used is to reject "github.com" itself instead of flagging it for review. They should probably also flag less things for review (probably after talking to github.) Looking at Figure 13, the first entry says it has 4 SANs in it, but claims only 1 was validated and 1 was not validated, what happened to the other 2? Kurt _______________________________________________ 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
