On Monday, August 29, 2016 at 12:08:36 PM UTC-4, mar...@marcan.st wrote: > On Monday, August 29, 2016 at 5:41:06 PM UTC+9, 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 > > > 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 > > Not only that, I see *two* certs issued for GitHub subdomains plus the parent > domain: > > https://crt.sh/?id=29647048 > https://crt.sh/?id=29805567 > > Why wasn't this additional cert identified and disclosed prior to the > aforementioned list being posted? It seems a no-brainer to manually audit the > list for obvious cases of mis-issuance (i.e. not only the domain was not > validated, but the customer clearly has no ability to validate it if asked).
Both of those certificates were generated by me. The 'motorstoiclathe' cert was a pseudonym made up to do more testing. Note that it's only valid for github.io because the 'schrauger' account was grandfathered into an old DNS redirect, and the new account didn't have that rule. Hence, it wasn't able to be created for the .com domain. It is interesting that WoSign followed the redirect. I suppose it is assumed that with a 301 permanent redirect that the new domain is controlled by the same person, but that seems a bit sketchy. I had forgotten about the second github.io certificate, but looking back on my emails, it was also revoked the day after it was created. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
