Notification before rate-limit reached

It would be very useful if users were notified about how many requests they have before they reach a rate-limit.

Hi @spooksmus

you can count.

That's all you need.

There is no additional feature required.

Hitting the duplicate certificate limit should never happen. Hitting that limit -> certificates are created, but not used or deleted -> that's wrong.

So the only limit is the 50 certificates per domain per week - limit. But it's very rare that a user hits this limit.

I do hit the duplicate certificate rate limit time to time, actually.

We have about 50 servers deployed in badly-connected, remote areas, serving internal websites, which are configured to request certificates from LE. They all use the same internal domain name and thus request the same certificate.

The servers are not talking to each other though and we currently have no logical central point from where they could securely obtain a shared certificate.

Is this wrong usage of the LE service then? We currently schedule our deployments such, that no more than 5 new servers can be deployed in any 7 day window.

2 Likes

In my opinion: yes. Just because you're not willing to enhance your infrastructure to use a single certificate, you're hogging and hammering the FREE Let's Encrypt services? Newsflash: just because it's free for you, it doesn't mean it's free for Let's Encrypt! I think your current behaviour is not very social. More certificates issued per timeframe means more load on the LE infrastructure and more investments in load-reducing methods.

And on top of that, you're asking for a way so you can keep hogging the service even "better"?

No, just NO. You're abusing the LE systems. You should develop a system to share a single certificate on all systems using the same hostname.

2 Likes

The only reason I would see this being helpful would be for users who don't bother to read the existing documentation about rate limits or the use of the test server. Can you suggest another situation where this information would be useful? Because IMO, if that's the only benefit, it would be a pretty low-value enhancement.

2 Likes

I suggested this elsewhere, but I think what may make more sense is to just add a second duplicate-certificate rate limit, this limit being along the lines of no more than 2 of the same certificate in a one-hour period. That way people just repeating the same thing over and over may see that it's a problem before they've used up all 5 for a week.

3 Likes

Hi @R-VdP

then you need exact one certificate. Use that 60 - 85 days, then create the next.

There is no rate limit problem.

If you are doing things completely wrong, that's

  • your problem, because your design is wrong,
  • a waste of resources

So we learn: A low rate limit is extremely required to stop such things.

2 Likes

Hi @petercooperjr

I don't think that's required.

The difference between 2 and 5 is too small.

If someone has really a problem and asks early enough, 3 or 4 certificates in one hour aren't a problem, if the last certificate is used.

The problem are users with a wrong behaviour - certificate created, not installed, next certificate created .... Or docker users, they don't save the certificate outside.

Then one week is good - that stops.

@JuergenAuer

There might be some confusion here.

2 of the same certificate in a 1-hour period

is a very different rate-limit than:

5 of the same certificate in a 7-day period

The idea that petercooperjr is going for is that it keeps certificate-seekers from being told to "wait a week", which is far too long to have a webserver be non-functional (no SSL).

Keep in mind we're not talking about getting rid of the 5-per-week limit. :slightly_smiling_face: This is just an additional precaution to prevent certificate-seekers from hitting the 5-per-week limit before we've had a chance to help them here.

I have championed and explained the details here:

2 Likes

I don't think there is any confusion here @griffin. @JuergenAuer just argues that people should have read the documentation and that hitting a rate limit is proof of a user not having read that documentation, which is their own fault.

Also, the rate limits aren't there for users not reading any documentation: they are meant to prevent huge peaks in the load on the LE systems due to buggy ACME clients. I personally believe we shouldn't add more rate limits, just for the handful of users having some trouble.

2 Likes

The handful of 40%+ of the users who come to this community having hit a rate-limit they knew nothing about? Let's be realistic: almost nobody reads that extensive amount of (to be honest) rather difficult-to-swallow documentation. Would you rather users come here having two duplicate certificates and needing to wait an hour or having five duplicate certificates and needing to wait a week? Personally, I'd rather they have three more shots when I get ahold of them. :grin:

2 Likes

I think you're a little biassed here. Of the users coming here with rate limit issues, probably about 100 % didn't read the (rate limit) documentation. But if you'd look at all the LE users out there (including the users not seeking help on this Community!), I can guarantee you that number is lower.
The users reporting here on the Community is just a tiny tiny part of the overall huge number of users out there.

Personally, I couldn't care any less. Even if they'd loose thousands of dollars in revenue per day, I wouldn't care. I wouldn't even point someone crying for help because of <insert pathetic excuse> to the 5 duplicate certs per week loophole which is even clearly stated on the rate limit documentation page! Probably any user hitting the duplicate rate limit can bypass it by just reading the documentation page well enough!!!

2 Likes

IMO the rate-limits were made for:

  • people who don't know exactly what they're doing (and probably haven't read the documentation)
  • people who selfishly know exactly what they're doing (and probably have read the documentation and complained about the limits)
2 Likes

Until it's your friend (who isn't very technical) who suffers the consequences. Keep in mind that many people who hit the rate-limit don't have any idea what they're doing wrong. Yes, they should know better, but I don't feel like sentencing them to a week of lost productivity/revenue is fitting of the "crime" they've committed.

2 Likes

That's probably correct, I might nudge a good friend towards the loophole. Although I might also reconsider my choices of friends :wink:

2 Likes

You would... :smirk:

:rofl:

2 Likes

Woah, you're making quite a bit of assumptions there.

I am not the OP, and I didn't ask for any way to "hog" the service better.

Additionally, the fact that those servers are requesting certificates for the same domain name, is rather coincidental, and could change in the future. If they'd used different domain names, we would've requested the same amount of certificates. We are not requesting multiple certificates for loadbalanced servers or such.
These servers are deployed mostly in remote areas and conflict zones, often very badly and only intermittently connected, and need to be able to keep on working as autonomously as possible under a bunch of circumstances. The (non-profit) organisation I work for does not have a lot of resources to setup and maintain a lot of infrastructure ourselves.

Anyway, I don't need to justify myself here.

I understood your message (even though I did not appreciate its tone) and will reconsider our choices, but the environment we work in is pretty constrained.

3 Likes

You keep repeating this, and it keeps not being true. First, as has been repeatedly mentioned in this very topic (including in the text you quote in this very message), that rate limit can be trivially circumvented by anyone with the capacity to read and understand plain English. Of course, that requires that the user actually have some understanding of what they're doing, rather than blindly following some "cookbook" commands. Second, if they're utterly unable to get a cert from LE (because they can't figure out for themselves how the "loophole" works, and nobody has explained it to them--a highly unlikely confluence of events), there are other sources for free certs, or they can even pay a few dollars for a commercial DV cert. There's no reason anyone should be down for a week secondary to this limit (but then, there's no real excuse for hitting it in the first place).

3 Likes

I'm game.

And has the technical prowess to understand the "hack". Regardless, a kludge to override a punishment is not a solution. IMO It's rather ridiculous to even need to hint at a way around the rate-limit. What's the point of even having the rate-limit then telling people how to circumvent it?

They don't, usually. Many if not most of the users we help here often don't know fully (or even partially) what they're doing. I'm not sure if that justifies offlining them for a week rather than getting help sooner. Keep in mind that I don't have sympathy for the users who do know what they're doing and hit the rate-limits due to their disregard for LEs resources. I differentiate between innocence and malice.

"Go somewhere else." Is that seriously a valid reason not to make accommodation for the most vulnerable of your potential userbase? Sure, I recommend Cloudflare Origin CA certificates when appropriate, but that's circumstantial. I do believe there needs to be a certain point where the line is drawn when "simplifying/streamlining" the documentation. I also believe we are far from that point. Even industry veterans have openly criticized the documentation here. What about the novice?

I'm not understanding this fully. When someone burns through five duplicate certificates in an hour running certbot --apache, I'm pretty sure they're going to be down for a week. Don't worry though because we can just tell them to modify their DNS to add a random subdomain via an A or CNAME record then modify their vHost configuration to serve for that new subdomain then add that subdomain to their certbot command to get another certificate. Then tell them to undo all that and undo the changes made by certbot to secure that new subdomain name. Or... we could just immediately stop them once they've acquired one duplicate certificate (so two identical certificates) and tell them to come here and get help. :thinking: I'm almost certain the latter scenario is much better for the volunteers here to deal with than the former.

2 Likes

It's explained quite literally. And Google Translate does actually translate it perfectly (to Dutch anyway), so even non-English-speakers for which a translation isn't available (there are 14!!! translations besides English!) should understand it quite easily.

That's a part of the problem and I for one don't think "but I didn't know" is really a good excuse for anything.. I know there are terrible guides out there. But the responsibility always lies with the end user IMHO.
I recon we're talking about (mostly) adult people here. Not teenagers.

2 Likes