With Let's Encrypt, the trouble became "Whoaaa I just ran a command and everything works like magic!"
But it's a good thing LE is available without the magic too.
Are you managing all your TCP connections manually then? It's a miracle that "magic" works without you having to manage it.
I still love Let's Encrypt for its principle, but I don't dare running it in full auto mode anymore. A few custom shell scripts get the job done easily enough.
Am I missing something that would make this magically work?
Installing a SSL certificate is relatively easy anyhow. It's one of the most common things you do with a http server.
I'm overall, very happy that it works at all... Some things I'd like to see...
Namely, automatically allow higher thresholds for domains used/provided by dynamic dns providers such as freedns, that have more domains that may want/need to register than limits allow.
Have a more transparent interface for requesting higher thresholds, or for submission of virtual tlds for those domains that offer subdomains to others.
Also, not sure where to put public suffix list additions for such a provider... I was going to add bbs.io, as well as say the top 25 domains for freedns.afraid.org, but wasn't sure where to add them.
Instead of magic, I would rather prefer simple and clear steps.
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.)
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.