>And I also expect that substantial majority of people out there believe in this process / data flow as that’s how certificates have always been verified – for

>And I also expect that substantial majority of people out there believe in this process / data flow as that’s how certificates have always been verified – for each new certificate, you either have to send an email from a given domain or put a file to a web server’s folder. Err... what? I don't think any CA validation process has ever involved sending e. mail, and I'd be very concerned if it did, since the origin of an e. mail is not in general authenticated. Unless it's in response to a CA e. mail which includes a token, of course. 'Obtain reusable authorization' followed by 'issue certificate' is hardly unprecedented, and it's a sensible way to structure things if you don't have a commercial interest in applying the friction of a financial transaction to the act of issuance. Startcom, for example, used this model (there are many issues with them, this wasn't one of them). I think CAcert may also use this model, unrecognised though they may be. The ACME protocol is also a standard. It's right there, I'm surprised people aren't reading it, especially when they're rigging up custom solutions. https://tools.ietf.org/html/draft-ietf-acme-acme-02 https://tools.ietf.org/html/draft-ietf-acme-acme-02