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.

▲

inahga an hour ago | parent | next [-]

You should persist certs somewhere. Otherwise your availability is heavily tied to LE’s uptime.

▲

cube00 2 hours ago | parent | prev [-]

Pretty risky given the rate limits of Let's Encrypt are non negotiable with no choice but to wait them out.

▲

muvlon 2 hours ago | parent [-]

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.

	▲	dextercd 33 minutes ago \| parent [-]
		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.