Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It is hard to set up. Creating a cert and trusting it is easy – a Powershell script can do that in 3 lines.

But then, trouble begins. You have to configure every server to use the certificate (or use a proxy) and every client to accept the certificate. Sometimes the proxies eat headers, or they have trouble with WebSockets and hot reloading or whatever.

We also use IPs instead of domains to find our locally running prod servers so that our customers don't have to configure anything DNS on their maybe-offline WiFi network. We also have to test with external devices, such as iPads. How do you automate getting your certificate onto them?

..And then your IP changes and all is lost again.

Yeah, if you have a 50 line Svelte "app" that you serve as site it's easy. But who does that?



> It is hard to set up.

Really?

> You have to configure every server to use the certificate

A couple of lines in apache/nginx/other config? The same lines each time. You probably don't want your dev box to be doing things required for LE renewal (allowing external in for HTTP(S) validation, making public DNS changes for DNS01, …) but I have a small container doing that and other boxes pull the resulting cert from there (a small cron task, again the same in each instance).

> and every client to accept the certificate

> external devices, such as iPads. How do you [get] your certificate onto them?

I suggested using a public name and an LE cert or similar. Clients will trust without extra effort.

> We also use IPs instead of domains

I did say “more devs don't” not “all devs don't”, there will of course be special cases. Though using addresses rather than names just feels broken.

> And then your IP changes and all is lost again

That is an argument against using address based config rather than name based config, not an argument against using HTTPS!




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

Search: