[geofft]

If you're running in a standard config. If your config is nonstandard (you have multiple servers that need a cert to stay in sync, you're not running a common web server, you're on a private network, you're pinning a client to a public key etc.), it's still easy but not a single command.

For sufficiently nonstandard setups, it's often easier to do the commonplace email-based verification than make Let's Encrypt work. I'd love to switch all of our internal services at $dayjob over to LE, but emails to webmaster@ already go somewhere useful, and setting up externally-visible DNS and fake servers is much more involved. (Either we write some code, or we do it by hand each time, and if we're doing it by hand, it's easier to just handle an email.)

[tracker1]

Why not terminate public TLS/SSL at the proxy level, then use internal PKI for proxy to backing servers... It's be easy enough to have a single ACME server that handles all acme requests forwarded from the firewall(s), then federate that configuration out as needed.

[geofft]

The configs I was describing in my first paragraph don't involve proxies. Adding proxies doesn't really solve the problems, and even if it did, writing an in-house ACME server is a lot more work than "run this magic command".

The config I'm describing in my second paragraph is for internal web services within a corporate network, that aren't public-internet-facing at all. I don't want to have all my clients (including people's phones) add an internal PKI because that's just bad security practice.