Good point 
Perhaps the rate limit form would be the answer for @dreamerworks problem.
From the rate limits documentation:
To make sure you can always renew your certificates when you need to, we have a Renewal Exemption to the Certificates per Registered Domain limit. Even if youâve hit the limit for the week, you can still issue new certificates that count as renewals. An issuance request counts as a renewal if it contains the exact same set of hostnames as a previously issued certificate. This is the same definition used for the Duplicate Certificate limit described above. Renewals are still subject to the Duplicate Certificate limit.
Yes, as I said - it doesnât âapply toâ renewals. But that doesnât change the fact that if you did 20 (or 30 or 100 or whatever) renewals that week - youâre over â20 certsâ, and therefore cannot register any NEW certificate. Itâs effectively a denial of service to anyone else in the same domain.
Hm, I assumed renewals didnât count for the 20/week cert limit at allâŚ
So did I⌠Till I got bit by that last week⌠Was a royal pain.
From my perspective - it effectively will render the service unusable once you have around 160 certificates, since the default will be around 8 weeks for renewal. Since that averages out to 20/week, once you hit that point, youâll probably never be able to get new certs unless you time it just right.
Good to know. Itâs also known at Letâs Encrypt and is a wonât fix issue.
You can renew many certificates at once. If youâd plan your renewals every two weeks (weekly wouldnât work), you just have to plan a new certificate in the period between renewal+7 and next renewal at renewal+14 days.
But indeed, youâve got a period of 7 days after a massive renewal in which you canât issue any certificate for domains which would have hit the rate limit.
Yep, essentially itâs a choice between âlikely unusable for new certs all of the timeâ and âcompletely unusable for new certs for 7 daysâ, and unfortunately - the latter requires either central point of control of all renewals or coordination amongst everyone who could possibly get a cert for the domain.
If you have self service deployments - where users/developers/students/whoever can get their own certs for their own hostnames, the above coordination/central control is effectively impossible.
@serverco you are correct, I just reuse a script someone else made (GitHub - will-in-wi/letsencrypt-webfaction: LetsEncrypt utility client for WebFaction hosts.) and I already created certificates with this script. Now, due to "something" on letsencrypt or on the script itself, the script gives an error. first you think maybe you did something wrong and try again, then re-read the documentation and try some different alternative (like passing the arguments instead of reading from a config file) then it doesn't work and you try again (like "now with quotes") and when you finally find a way that works you get the nice "too many certificates". This use case is very different from docker images reissuing certificates or some build script that always regenerates certificates. I feel many "users" like me (that are front-end or backend developers for some client) do run into this issues. And the site for unblocking would solve our problems.
[quote=âOsiris, post:122, topic:4772â]
Perhaps the rate limit form would be the answer for @dreamerworks problem.
[/quote]Yes, it would be a form like that, but just for unblocking.
I personally donât have that big number of certificates to issue, just an occasional new client or an occasional new app on a new sub-domain.