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:
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?
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>".
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.
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.
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.
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.
