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 subdomain telling you that
they are authorized to own a certificate that covers 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 -, which belongs to Microsoft
Azure. I'm fairly certain this certificate was not authorized by Microsoft:



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 <>
>> 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 
>>>, 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 when the person validation
>> 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 mailing list

Reply via email to