For https://crt.sh/?id=29884704 , he finished the website control validation.
We and Alibaba are investigating why he can do the website control validation. The is the log, but we can't expose more now since it is related to Alibaba. 2016-06-23 01:34:39: WoSign validation system received domain "alicdn.com" website control request，the url is "http://alicdn.com/alicdn.com.html";, v_random is 2e3baabe989fad9f143517796ed4941c13e7177b, Validation system used Get method, 400 error, then change to use POST method, success. By the way, as I said in the reply, we think the website control validation have potential risk that we need to discuss, so we decided to close this method. Best Regards, Richard -----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+richard=wosign....@lists.mozilla.org] On Behalf Of Ryan Sleevi Sent: Friday, September 2, 2016 9:59 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: website control validation problem On Thursday, September 1, 2016 at 6:16:53 PM UTC-7, Richard Wang wrote: > For this case, WoSign notice Alibaba after getting report. > > I think this case is another case for website control validation problem. > > Now, many CDN, Internet service provider provide a subdomain to its customer > like: myname.CDNprovider.com, this customer can do the website control > validation, then he can get this certificate. You can't say this is > mis-issued or fake cert. If you authenticate myname.cdnprovider.com, then the BRs prevent you - before and after - from issuing the certificate to cdnprovider.com. This was already true under the previous version of the Baseline Requirements to which you were audited, v 1.3.3, Section 3.2.2.4, Method 6. The specific allowance is for FQDN. You can validate that the subscriber has control of myname.cdnprovider.com, however, that is NOT permitted to validate any other subdomain under cdnprovider.com. > > This validation method is allowed by BR, so we need to make clear that if the > ISP/Cloud service provider don't notice CA that which domain's subdomain is > not allowed to issue certificate to customer, then this issued certificate is > OK. Just to confirm, we're talking about https://crt.sh/?id=29884704 , issued on June 23, 2016. You're stating this certificate is misissued, correct? It is certainly revoked in http://crls1.wosign.com/ca6-server1-free.crl , CRL number 0202053E This certificate's misissuance does not match any of the Website Control violations you've mentioned yet. That is, rather than adding the bare domain and www, as you previously suggested you did (in 2015), this appears to have been for a variety of subdomains, clearly of security importance. It suggests that the 2015 issue was not actually resolved, or, if it was, that there's a new issue. It's also important to consider the date - June 23, 2016. At this point, WoSign had already seen and been aware of multiple circulations of the BR pre-ballot to reform the means of domain control validation, an issue I first raised to the CA/Browser Forum and the Management List over two years ago as an area of security concern for CAs to be aware of. Can you please clarify exactly the method you used to authenticate and authorize this request? Given that you're required to maintain unalterable audit logs of CA and Subscriber Certificate Lifecycle management events (per 5.4.1 of the BRs), it would be essential for the community that is considering the trustworthiness of WoSign that you explain how WoSign validated this request, when it was an authorized certificate. _______________________________________________ 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
