I think it's also important to note... you don't need the account key at all if you can re-do the domain verification every time.<p>In most cases I delete the account key right after verifying the domain and getting a cert, and let certbot generate a new one every time.<p>We route the '/.well-known/acme-challenge' request to the standalone server (we use haproxy ACLs 'path_beg' to route it to a dedicated port on localhost) so it hasn't been a problem running the validation every time for every new cert.<p>And per TFA, the timeout for validation on their side (what they call Authz or authorization token) is about the same as the timeout for renewal, so you can't really depend on not needing to validate the domain even <i>with</i> the account key. I'd much rather have the code path be identical every time, rather than different for new cert vs renewal cert, and then also different every other time you renew due to authz expiry.
In general, you'll automate lets-encrypt. That means you'll have some file or group of files (a cronjob, systemd timer, or what have you) that's capable of producing new keys.<p>If an attacker can read files on the filesystem as root, then they can simply read whatever automation scripts you have and issue new certs as well.<p>This isn't always true (e.g. if it depends on an IAM role, they'll have to get data from the instance metadata service as well), but the point is generally true.<p>If an attacker has root filesystem access on a box which can issue certs, it makes miniscule difference whether they need to grab an account key or bash script; either way you've probably lost.<p>You could also, however, have more locked-down boxes which issue certs, encrypt them for their intended hosts, and transport them over, at which point all of your host boxes no longer have account keys to worry about.<p>You could also encrypt-and-ship the account key from the box to elsewhere, and then remove it.<p>Frankly, you're making a lot of fuss about absolutely nothing.
> The surprising aspect is that Authz has a validity of 300 days (which is likely to be increased)<p>This is not true. Authorization lifetimes are only going to get shorter and shorter [1], and have already been reduced to 90 days.<p>[1] <a href="https://community.letsencrypt.org/t/upcoming-api-changes/17947" rel="nofollow">https://community.letsencrypt.org/t/upcoming-api-changes/179...</a>
> I did expect that each request includes a fresh verification of the domain control. 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.<p>This is not correct. Certificate Authorities are allowed to reuse authorizations for (I believe) up to 36 months, so Let's Encrypt is already significantly below that (with 90 days right now, and probably closer to something like ~7 days soon). Many CAs I've used in the past worked like this.
>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.<p>Err... what? I don't think any CA validation process has ever involved <i>sending</i> 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.<p>'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.<p>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. <a href="https://tools.ietf.org/html/draft-ietf-acme-acme-02" rel="nofollow">https://tools.ietf.org/html/draft-ietf-acme-acme-02</a>
If you're upset about the expected operation of a service based on open-source software (github.com/letsencrypt/boulder), then I'd strongly recommend reading the code before use. Additionally:<p>"I also expect that our Enigma Bridge Cloud HSM service (check our PKI product with hardware key security) can securely control storage and use of the account key to prevent thefts of the keys and their subsequent misuse."<p>Using this as a way to promote your product and <i>not</i> reading the code first is a serious failure of tradecraft on your part.
Or just destroy the auth key once a certificate is issued. No need to keep it around. Can go through the expected validation process for a new one when renewing.
My recommendation is to use the DNS challenge implementation with an appropriate DNS provider (I use Route 53): you can do all your certificate generation on a single locked-down machine and then just distribute the certs out to your machines. No need to deal with path_beg or check which host in the fleet is responding to the acme-challenge request.
"This is not true any more with re-usable AUTHZ tokens"<p>I must re-iterate my own 10+ year experiences with Token auth - once authorized, end that token, period, or you're asking for problems.