Hacker News new | past | comments | ask | show | jobs | submit login

> Putting a TLS certificate on your shit with LE takes minutes. Doing it through another CA is minutes

if you have one server, yes. else it's the other way around, because if you have multiple servers you need to do a lot of fancy stuff. And LE also does not work in your internal network if you do not have some stuff publicy accessible. And it also does not work against different ports.

Oh and it's extremly hard to have a proxy tls <-> tls server that talks to tls backends, useful behind NAT if you only have one IP, but multiple services behind multiple domains.

IPv6 fixes a lot of these issues.

You can use Let's Encrypt certificates for non-publicly reachable hosts by using the dns-01 challenge type. That, of course, means that you need some way of properly automating your DNS infrastructure to add the necessary TXT records which, admittely, is sadly not the case in many organizations. It's a solvable problem, though.

I don't understand your last point. Where do you see the problem with letting a reverse proxy talk to a TLS backend? You get the requested server name from the SNI extension and can use that to multiplex multiple names onto a single IP address. The big bunch of NATty failure cases apply to plaintext HTTP just as well, no?

Well the last point means that I need to rollout the cert to multiple servers (as the poster below writes)

In the most common setups, the reverse proxy usually terminates the TLS session and uses a different connection to make requests to the backend servers (e.g. nginx proxy_pass directive).

This means the backend server certificates are only ever exposed to your reverse proxy. There's no need to use publicly-trusted certificates for that. Just generate your own ones and make them known to the proxy (either by private CA cert or by explicitly trusting the public keys).

This new version issues wildcard certificates. Get one certificate. Use Puppet, Chef, Ansible, Salt, Bolt, multissh, or GNU parallel to put it on multiple servers for that domain.

If you need lots of different domains, use one of the auto certificate tools.

If you can't use one of those yourself, consider hosting on a platform that can automatically do this for you for all your sites, like cPanel (disclaimer: I work for cPanel, Inc).

If your stuff is never publicly accessible because you're in a fully private network, just run your own CA and add it to the trust root of your clients.

If you need an SNI proxy, search for 'sniproxy' which does exist.

If you're so small that you can't afford an infrastructure person, a consultant, or a few hours to set such things up yourself, then maybe you should shorten the HN thread bemoaning doing it and use the time to learn how.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact