A few days ago, I misconfigured my ACME client, causing it to attempt a certificate renewal every other day (instead of my intended setting of one day before expiration). Theoretically, this should have triggered the [New Certificates per Exact Set of Identifiers] rate limit (5 certificates per week) mentioned in the documentation. However, checking the logs, the daily renewals have been successful. I also tested requesting certificates in rapid succession, and it was rejected on the fifth attempt as expected. Does this imply that shortlived certificates have a faster rate limit recovery speed? (Or perhaps standard certificates do as well, but I haven't had enough time to test it.)
as LE's ratelimit use leaky bucket that allows new one every ~34 (168/5)hours, 2 day renewal likely worked.
ratelimit code itself doesn't care about profile.
5 Likes
Why were there daily renewals if you were trying every other day?
Did you have two different sets of identifiers on alternate days?
Mind you, you should be using ARI for your renewals. That would have avoided the problem you had. ARI also exempts renewal rate limits if you use its "replaces" value and honor the suggested window it provides. See this section: Rate Limits - Let's Encrypt
4 Likes
It's everyday, sorry for my typo
No they are the same, that's why I tried to test my renew logic for 5 times and try to trigger the limit
Thatk you, I konw that and I have no depoly problem, I just wrote a incorrect code and found the strange behavior (client is able to issue 7 certs per week) so I opened this
We won't be able to look into that without the actual domain name.
I don't understand how you get a reject after 5 certs with this test but you say you can get 7 certs in a week. The 34H "refill rate" for that limit should not allow 7 certs in a week.
I'm not sure how you expect us to try to reproduce the problem without seeing your exact history.
4 Likes
Remember that renewals are exempt from rate limits. As long as you're not changing the set of identifiers on the certificate (or better yet, using the ARI replaces field), you won't need a different rate limit for shortlived certs.
This is the same logic as laid out in our recent blog post: Shorter Certificate Lifetimes and Rate Limits - Let's Encrypt
3 Likes
Well, this was asking about the "New Certificates per Exact Set of Identifiers", which does still apply for non-ARI renewals (which is kind of its entire point, if I'm understanding correctly). Or are you saying that the Non-ARI Renewals Rate Limits documentation is going to be updated soon with something else?
4 Likes
Not to detract from Peter's question, which I am also interested in. But, I don't interpret the LE Rate Limit page as saying any renewal is exempt
Below is from the LE Rate Limit section on ARI. It describes waiting for the "optimal renewal window" and using its "replaces" option. Is that just a suggestion? Or can you continuously renew a cert using "replaces" regardless of the suggested window?
When the optimal renewal window is reached the client requests a new order explicitly indicating the certificate it replaces. If the new order includes at least one identifier matching the certificate it intends to replace and the certificate has not been previously replaced using ARI, the order will not be subject to any rate limits.
Further, this indicates only "reaching" the window is sufficient. A thread not long ago had @Nummer378 showing Boulder code looking at both the start and end periods for rate limit checks. Has Boulder changed since then?
3 Likes
I provided the crt.sh link in my reply, if you missed, it's here https://crt.sh/?q=2A0E%3A97C0%3A3F0%3A1%3A0%3A0%3A0%3A2573&deduplicate=Y
It's easy, token bucket algorithm. According to the doc, the limit is [size=5 refill=34h], but according to my test, the limit is [size=5 refill<24h] that's why I can issue a cert everyday but can not issue 6 certs in one minutes.
1 Like
I had missed it. Thanks
Well, sure it's easy if we ignore the docs 
But, we can't well explain what you have seen from the published material.
Your test doesn't prove that 24H is the bucket refill cutoff. You only tested non-ARI renewal at 24H and rapid renewals (1min) so it could be anywhere between that. Or, it could be something entirely different as a limiting factor. What you proved is there is some rate limit on a non-ARI renewal.
Your cert uses a single IPv6 address as the identifier (not mixed with a domain name) so perhaps that is a factor. IP address certs are fairly new so you may be running into an LE bug.
We'll likely need to wait for @aarongable to clarify or someone to review the Let's Encrypt Boulder code.
2 Likes
Yes, at first I thought there might be a bug that IP cert might able to bypass the rate limit so I tried quick issue. Then I encountered 5 certs restrictions normally. That's why I guess shortlived certs may have undocumented refill rate (or other special rules, I am not doing reverse engineering, so I choose to directly inquire here 
)
1 Like
It was very helpful that you did that quick succession test. It does look like an LE problem. And, providing info to help clarify a problem is not reverse engineering You have described the problem well. I just don't have the ability to pursue it further.
The reason for this post is to make clear that certs with IP address identifiers require the "shortlived" profile. But, you can also use "shortlived" profile for certs with domain names. That is why I said this problem might be unique to IP address certs and not necessarily all "shortlived" profile certs.
5 Likes