Hacker News Reader

Comment by lllorddino | Hacker News Reader

Hacker News should switch from Comodo to Let's Encrypt. Scumbags attempted to trademark Let's Encrypt. https://letsencrypt.org/2016/06/23/defending-our-brand.html

View on HN

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.

With Let's Encrypt, the trouble became "Whoaaa I just ran a command and everything works like magic!"

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.

That's called automation and it's a good thing.

Automation is not a universal good, it can be useful and it can be detrimental. Like all tools it should be used with care.

Exactly. Value is a vector: automation increases the magnitude, but the direction depends on exactly what is being automated (and how reliable it is).

"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.

> The one thing you don't want on the configurations of a server farm is "magic". It is simply impossible to manage.

Are you managing all your TCP connections manually then? It's a miracle that "magic" works without you having to manage it.

not for wildcards, also if you don't want to take your website down during the process, the command line becomes slightly more convoluted

There are multiple ways of using Let's Encrypt that don't have to take the website down.

Yes which are more convoluted that the one liner to generate one automatically

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.

Use lego. It works brilliantly in DNS mode

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.

True enough, but would be nice if it detected that the SOA IP corresponds to a public suffix dns provider.

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.

The process is described here[1]. It needs to be performed by the domain owner.

[1]: https://publicsuffix.org/submit/

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).

Well, last time I tried, the compilation failed. I didn't understand why it had to do compilation.

Instead of magic, I would rather prefer simple and clear steps.

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.

HN, of all places, may take the trouble to actually make a small statement however. People would actually notice here.

> 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?

Have you considered valid personal purposes for shoplifting or are you just deciding 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.

Edit: as for whether Comodo had a "valid business purpose" for the action, sure, in the same sense that patent trolls have a valid business purpose. Read this statement by their CEO: https://forums.comodo.com/general-discussion-off-topic-anyth...

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.

True, that was really ugly.

However, I think some nuance is important here. Comodo has some really good people (like Rob Stradling) that are doing a lot of good work for PKI.

eg, the https://crt.sh tool is fantastic.

Reply on news.ycombinator.com