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

> My biggest beef with self-hosting is that they expect us to set up the SSL/TLS certificate without explaining the step to set it up. Some guides does have section about it but never provide the details about creating CA for my self-hosting needs. I turn to Google/DDG to find information about it and they are all over the place or leading into dead-end.

If you have your own domain pointed at your server, the Let's Encrypt certbot can automatically pull in a certificate and configure your apache/nginx webserver (alternative webserver caddy has this feature built in as far as I know).

If you don't have your own domain, don't go with self-signed certificates. Get a free https://desec.io/ subdomain, and they have their own certbot plugin to generate automatic certificates.



> If you have your own domain pointed at your server, the Let's Encrypt certbot can automatically pull in a certificate

Yeah, but don't have a mistake too many times, or Let's Encrypt will block you for a week until your rate limit times out.

I hit this. I understand why Let's Encrypt has to do this, but it's very annoying and you have no choice but to do nothing for a week.

There needs to be something in between Let's Encrypt (free) and a couple thousand a year (other CAs).


If you use Caddy, you'll almost never run into rate limits from Let's Encrypt, because Caddy rate limits itself, and will fallback to ZeroSSL instead of Let's Encrypt, and even fallback to LE's staging for additional retries against LE before trying the live one again if it works with staging. See https://caddyserver.com/docs/automatic-https#errors


Use the LetsEncrypt staging server for testing. When you have a process that works, switch to prod.


That's a tautology saying "Don't make mistakes."

A DNS misconfiguration can cause your Let's Encrypt to do weird things on a configuration that was (and still is) perfectly correct.

That was how I hit it. I eventually figured out what people screwed up in DNS. But certificates still didn't clear. So I spent an extra couple hours staring at DNS trying to figure out what I missed when the issue was that we bumped into the rate limit at Let's Encrypt (which is REALLY low--I think 5 failures is enough to trip it) while the DNS was bad and the only thing we could do was sit around for a week with dead certificates.

Not fun.


Sorry, quick comment, didn't mean to be glib.

I've hit the problem you describe, and I feel your pain. I also respect LetsEncrypt's choice to rate limit failures. I renew a couple dozen domains at a time, so one error can quickly cascade into being blocked. IIRC the block timeout starts at 24 hrs and goes up from there if you keep trying -- this is easy to do if you don't see the raw response error message!

After being bitten by this a couple times, I added a dry-run step to my autorenewal script. If the dry-run exits with success and generates a good new cert for the domain, I repeat by pointing to the LE prod server. This works every time (so far, but for years now).

I'm suggesting that any LetsEncrypt certificate automation system (or docs) targeted at relatively low-sophistication users (i.e. not you or me) should include this sort of dry-run check so that the user doesn't paint themselves into a corner with a somewhat persnickety, but essential, service.

Also of course, it should attempt to renew after 60 days, so that if things go badly wrong, there are a few block-timeout retries available before the 90 day expiration.




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

Search: