To be clear, the failure here is not that DigiCert issued for .arpa, which is not forbidden, but that they gave the reporter, Cynthia Revström, the ability to issue for all of in-addr.arpa even though she had only demonstrated control over 5.168.110.79.in-addr.arpa. This vulnerability could have applied to regular non-arpa domains too; e.g. someone with control over example.github.io might have been able to get a certificate for any github.io domain.
However, since issuing for .arpa is weird (and maybe should be forbidden), the discussion got sidetracked talking about .arpa issuance.
Great example of vigilence here. I can’t see anything in your report that would lead me to think this only happened to you, but you seem to be the first to notice and follow through on the hunch. Nice work!
Thank you :) I got a bit suspicious when I just saw in-addr.arpa in the verification email and asked my friend if I should test it, and they said yes so :P
> someone with control over example.github.io might have been able to get a certificate for any github.io domain
I think that, realistically, that's a lot less likely. I think the "weirdness" of the in-addr.arpa hierarchy contributed to the "manual validators" just shrugging and pushing through.
I think the main issue raised is that whois record checking is becoming manual and silly because of whois throttling and captchas and GDPR concerns ... in many cases it's not really working well enough to issue certificates based on.
I understand the need for manual checks in some places, but if the natural reaction to seeing in-addr.arpa is to shrug and push through, then there's a definite policy violation here.
However, since issuing for .arpa is weird (and maybe should be forbidden), the discussion got sidetracked talking about .arpa issuance.
DigiCert's analysis of the vulnerability can be found here: https://groups.google.com/d/msg/mozilla.dev.security.policy/...