3 ms·
Use the LetsEncrypt staging server for testing. When you have a process that works, switch to prod.
by quesera 5y ago
Use the LetsEncrypt staging server for testing. When you have a process that works, switch to prod.
- bsder 5y agoThat'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.
- quesera 5y agoSorry, 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.