Richard, the problem with this approach is that the *subscriber* might not be authorized to make this decision for the parent domain. To go back to the GitHub case, the "owner" of a github.io subdomain telling you that they are authorized to own a certificate that covers github.io is irrelevant, as they have never demonstrated ownership of that domain.
The right approach would be to revoke the affected certificates immediately and inform your subscribers that they will need to re-issue their certificates (while also verifying ownership of the root domain). Here's another similar case - cloudapp.net, which belongs to Microsoft Azure. I'm fairly certain this certificate was not authorized by Microsoft: https://crt.sh/?id=29805555 Thanks, Patrick On 29/08/16 11:30, Richard Wang wrote: > Yes, we plan to revoke all after getting confirmation from > subscriber. We are doing this. > > Regards, > > Richard > >> On 29 Aug 2016, at 16:38, Gervase Markham <g...@mozilla.org> >> wrote: >> >>> On 29/08/16 05:46, Richard Wang wrote: For incident 1 - >>> mis-issued certificate with un-validated subdomain, total 33 >>> certificates. We have posted to CT log server and listed in >>> crt.sh, here is the URL. Some certificates are revoked after >>> getting report from subscriber, but some still valid, if any >>> subscriber think it must be revoked and replaced new one, please >>> contact us in the system, thanks. >> >> Er, no. If these certificates were issued with unvalidated parent >> domains (e.g. with github.com when the person validation >> foo.github.com) then they need to all be revoked. You should >> actively contact your customers and issue them new certificates >> containing only validated information, and then revoke these ones. >> >> Gerv >> >> >> _______________________________________________ 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
