Comment by bob1029
7 days ago
I've changed my mind about the short lived cert stuff after seeing what is enabled by IP address certificates with the HTTP-01 verification method. I don't even bother writing the cert to disk anymore. There is a background thread that checks to see if the current instance of the cert is null or older than 24h. The cert selector on aspnetcore just looks at this reference and blocks until its not null.
Being able to distribute self-hostable software to users that can be deployed onto a VM and made operational literally within 5 minutes is a big selling point. Domain registration & DNS are a massive pain to deal with at the novice end of the spectrum. You can combine this with things like https://checkip.amazonaws.com to build properly turnkey solutions.
Pretty risky given the rate limits of Let's Encrypt are non negotiable with no choice but to wait them out.
They are quite literally negotiable: https://isrg.formstack.com/forms/rate_limit_adjustment_reque...
There are also a bunch of rate limit exemptions that automatically apply whenever you "renew" a cert: https://letsencrypt.org/docs/rate-limits/#non-ari-renewals. That means whenever you request a cert and there already is an issued certificate for the same set of identities.
Your comment is 100% correct, but I just want to point out that this doesn't negate the risks of bob's approach here.
LE wouldn't see this as a legitimate reason to raise rate limits, and such a request takes weeks to handle anyway.
Indeed, some rate limits don't apply for renewals but some still do.
If you’ve hit a rate limit, we don’t have a way to temporarily reset it. [1]
From your link
move the adjustments to production twice monthly.
I don't know about your use case but I couldn't risk being unable to get a new certificate for at least a fortnight because my container was stuck in a restart loop.
[1]: https://letsencrypt.org/docs/rate-limits/
You should persist certs somewhere. Otherwise your availability is heavily tied to LE’s uptime.
Technically, because Let's Encrypt always publishes all requested certificates to the logs (this isn't mandatory, it's just easier for most people so Let's Encrypt always does this) your tool can go look in the logs to get the certificate. You do need to know your private key, nobody else ever knew that so if you don't have that then you're done.
X509 certificates published in CT logs are "pre-certificates". They contains a poison extension so you don't be able to use them with your private key.
The final certificate (without poison and with SCT proof) is usually not published in any CT logs but you can submit it yourself if you wish.
4 replies →
Now you depend on CT log providers uptime, which as far as I can tell is worse than LE.
3 replies →