On Sun, Oct 2, 2016 at 6:23 PM, Nick Lamb <tialara...@gmail.com> wrote: > On Sunday, 2 October 2016 20:53:15 UTC+1, Peter Bowen wrote: > >> Under the new rules, which should be in >> effect as of 1 March 2017, validating www.<domain> will not be a valid >> method of showing control of <domain>. The name is true for any valid >> hostname under <domain>. The only note is that names in the form >> _<something>.<domain> (that is starting with an underscore) can be >> used to validate <domain>. > > I wish I shared your confidence. My expectation is that if we leave this as > it is, in April 2017 subscribers will still be able to get a certificate > issued using this lackadaisical validation, and the issuing CA will say they > feel it's not "really" disobeying the rules, that it's just a "technicality" > and anyway what's the harm, it's so much more convenient for their customers > this way?
I'm rather confident, but then I was one of the authors of 169 and will be pushing hard to ensure all CAs get this right. > On https://community.letsencrypt.org/ more than once users who've previously > had certificates from elsewhere have expressed confusion or dismay when they > realise that Let's Encrypt doesn't automatically issue them a certificate for > both www.example.com and example.com after they only asked for one of the > two. So this practice has apparently been widespread enough for some > subscribers to assume it's "just how it works" even though it was never > actually permitted by the BRs... >From my experience running a CA, it does seem customers are surprised if certs don't automatically contain both www.example.com and example.com. However that is unrelated to how validation works -- in this case the simple answer for the CA to validate control of example.com which allows issuance for both names. The incorrect method is to validate www.example.com and then issue for example.com. Thanks, Peter _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
