HN uses ycombinator's wildcard certificate, and it's not up until August 2019. It's likely that they don't want to go through the trouble until it's really needed.
> may take the trouble to actually make a small statement however
Another move in the direction of political correctness and making decisions according to optics. Have you considered valid business purposes for a company doing a particular act or are you just deciding that everyone thinks this was a "scumbag" action?
Supporting a non-profit organization working for a more secure Internet could easily fall under a "valid business purpose" for a site like HN.
HN's entire business mandate, such as it is, seems to be to encourage technological growth in the interest of profiting tangentially off the growing pie.
It's surreal. He tries to shift the blame to Let's Encrypt for choosing 90 days as their default certificate expiration date, somehow implying that 90 days is Comodo IP.
Sometimes magic isn't a good thing, especially when you're operating a service used by as many people as hn daily. Magic means things happened that I didn't explicitly instruct.
"Magic" is automation that is hidden from you. That one is not universally good. The one thing you don't want on the configurations of a server farm is "magic". It is simply impossible to manage.
But it's a good thing LE is available without the magic too.
Yeah until two hours later when you notice it messed with random shit it wasn't even supposed to touch. At least, that was my experience; I suppose it depends on how common your setup happens to be.
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.
The auto mode just confused me. Every setup is different. Some use Apache, nginx, or both -- and proxied behind Haproxy or varnish. Then there's stuff like cpanel or virtualmin. So you got to expect any combination of those -- one or more, or combined. Their scripts would have to accommodate for so many different things. How could I anticipate what it would do?
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.
Depends on where you want SSL termination, and if you want it federated out... The default Let's Encrypt project(s) integration tooling afaik isn't used by many people, but there have been a lot of tools to do more simple ACME integration into various web servers, reverse proxies and other configurations. It's pretty cool.
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.
Dynamic DNS providers that are on the Public Suffix List are essentially treated like TLDs in terms of rate limiting, meaning each client subdomain has a separate counter. They should probably be on the PSL anyway; browsers rely on it for cookie scoping.
There's always the option of running certbot in certonly mode - in fact, that's what I do for the majority of my setups (mostly because certbot doesn't support nginx).
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.)
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.
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.