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.
> 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.
agwa|7 years ago
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/...
bitcynth|7 years ago
ploxiln|7 years ago
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.
icedchai|7 years ago