Add an Hourly Duplicate Certificate Rate Limit

I cannot take credit for this suggestion, but I felt it to be so excellent that I just had to champion it.

Multitudes of times per week we see several common ways that certificate-seekers hit the five-duplicate-certificates-per-week rate-limit:

  • Misguided efforts to debug certificate installations (which is a compelling reason to segregate acquisition and installation behavior)
  • Ephemeral environments (like certain Docker setups) that treat certificate issuances like tissues
  • Multiple devices serving the same certificate (like when the workers behind a load-balancer terminate TLS)

Allowing only two duplicate certificates (one original and one duplicate) per hour along with an appropriate message from Boulder (like coming here to get help) would likely:

  • Effectively combat the issuance of duplicate certificates
  • Virtually eliminate wasteful spin-up processes of ephemeral environments
  • Drastically reduce the number of sad/angry help-seekers being told to "wait a week"

This limit is intended to be in-addition-to the current five-duplicate-certificates-per-week rate-limit.


I do not feel that the following response is in the spirit of this community:

I sentence you to a long session of RTFM and a lost week of productivity/revenue!

5 Likes

A couple of concerns I see with this:

  • Rate limits are complicated enough already; adding yet another one will make it that much harder for a user (who hasn't and won't RTFM--because if they had or would, the situation wouldn't arise) to figure out which one they've hit and how long they have to wait.
  • As noted above, this problem affects, pretty much exclusively, people who have trouble with willingness and/or ability to read the extant documentation. Why expect that they'd do a 180 at this point?
3 Likes

You make a valid point. Clarifying the rate limits in the messages from Boulder would be nice. For now though, I'm thinking about just rewriting the rate limits page.

They would at least have a chance. Does the "sentence" of a week of lost productivity/revenue fit the "crime" of not reading the documentation and not understanding what's wrong? Would you rather help-seekers who come here have 3 more chances within 3 hours or no more chances for a week?

Yes. If you can't find the loophole which is quite clearly stated in the rate limit page currently, you deserve such a "sentence" IMHO.

It's also the mindset of most people coming here with a rate limit problem. It's almost never a request for "I don't really understand the page, please help me understand and learn more", it's almost exclusively "Please help me get a brand new cert even if I just issued 5 previously and they magically disappeared and now some stupid error popped up, but I need MOAR CERTS, please help me I'm begging, I want HTTPS <crying user>".

1 Like

That's because their business/career may be in danger.

I almost can't believe that I, of all people, who have used the term "survival of the fittest" almost continuously, am actually fighting for clemency for the less-fortunate/less-willing. What a philanthropic misanthrope I've become.

1 Like

Better do change your dayjob then!

2 Likes

Keeping this topic alive for further discussion.

I like this suggestion and in particular I think it's somewhat in the spirit of "random entries in the directory" thing—trying to make an issuance process fail quickly if it's based on a mistaken assumption, so that it can be changed as quickly as possible.

I think if Let's Encrypt doesn't want to make this change, it would be a useful thing for clients to implement ("WARNING! Your certificate issuance is duplicative of a very recent issuance, please ensure this doesn't happen repeatedly or you will be rate limited and unable to continue issuing certificates for 1 week"). Unfortunately in the particular case of people using ephemeral Docker containers, there's no way for the client to notice this unless it checks CT logs, which will probably slow down issuance unreasonably.

My other suggestion would be an ACME extension to report the rate limit status. I know that this, too, has been proposed before and is difficult to achieve in various ways, but I wonder whether there would be a straightforward way just to report duplicate certificate count via a protocol extension, without having a fully general mechanism to check the status of all rate limits. One idea would be an HTTP header like

Duplicate-Count: 2

that appears when issuing a duplicate that would be within the scope of the rate limit. Then clients could gradually add mechanisms for displaying warnings as appropriate within the context of their own UI.

4 Likes

I was just having a separate discussion with @griffin about this general topic elsewhere on the forum and now on GitHub, and I noted that a ton of people don't read or review any of Let's Encrypt's own documentation before attempting their first issuance.

I find this sad and frustrating (and I do feel for Jürgen, always having to tell people to "read some basics" about Let's Encrypt!), but I want to suggest that we stay creative about both encouraging people to read (and learn) more, and mitigating some of the consequences of their not having done so.

5 Likes

I'd just like to say that I think this is an idea worth considering -- not promising to do it, but certainly worth considering -- but that we probably won't put serious thought into it until the new year, as most of us are taking various amounts of vacation. If someone wants to file a feature request issue in the Boulder repo, that would be great.

3 Likes

Done and done. :grin:

5 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.