We see an error like this:
Error creating new order :: too many certificates already issued for "io.vn". Retry after 2023-06-23T10:00:00Z: see Rate Limits - Let's Encrypt
Assuming you're also operating some sort of PSL-ish list on your end. Could you support them accordingly?
Thanks!
Related topic: Register cert for new domain
LE staff didnʼt reply there yet, but the support will come sooner rather than later.
as LE follows GitHub - weppos/publicsuffix-go: Domain name parser for Go based on the Public Suffix List. i think they will relase a update soonish
(LE do pin a commit in that repo, as git blame shows if needed)
Boulder's workflow to update the PSL runs on the 1st of the month (and then you will have to wait potentially up to 2 weeks for it to make it to production), so if you want it sooner than that, it might be worth filing an issue asking for it to be updater sooner on the project repository: Issues · letsencrypt/boulder · GitHub
The PSL update action is manually disabled, is that correct?
@_az Thanks.
But right, doesn't look like it's in use anymore: Actions · letsencrypt/boulder · GitHub
The last tag release of GitHub - weppos/publicsuffix-go: Domain name parser for Go based on the Public Suffix List. is also Feb 2023 so it's been outdated.
OK, Update Public Suffix List by mcpherrinm · Pull Request #6957 · letsencrypt/boulder · GitHub
That should be in production within the week, though of course there's no guarantee.
@mcpherrinm Great to see swift manual action, thanks! Quick question tho: if I recall correctly, previously it was quite common for Boulder to pin the @weppos PSL Go library by date/commit instead of tags? As the PSL gets updated very frequently, I can imagine @weppos doesn't tag that often.
That would, of course, hinder keeping the dependency up to date using Dependabot. The last PSL update was done using Dependabot; is that also the reason why the "Update PSL" action was manually disabled, as Dependabot would be able to update the PSL when a release was made?
I’m not sure, but I’ll find out.
We did deliberately disable that workflow because we had to remove the Github PAT that it relied on (we disabled legacy PATs in our org). We're going to look at a new mechanism to keep it up to date, but in the meantime we're going to rely on dependabot and tagged PSL releases, or manually bumping the version.
Hi, I want to check if the ratelimit change has been applied to the new public suffix list yet?
Looking at https://acme-v02.api.letsencrypt.org/build the ACME API is currently running the build from 12-06 (grpc/sa: Implement deep health checks (#6928) · letsencrypt/boulder@124c4cc · GitHub). The PSL update was committed just 3 days ago (Update Public Suffix List (#6957) · letsencrypt/boulder@66cfad1 · GitHub).
So now it's waiting for the ACME API to get a new release of Boulder.
Based on the usual update schedule, I would expect the PSL update to be rolled out to production today between 19-23 UTC. Staging is already running on a newer PSL version. However, there's always something that can get in the way, so don't take this as a promise.
Since this general topic comes up a bit, can I suggest the following be built into this workflow?
https://github.com/letsencrypt/boulder that just states:
Then,
https://letsencrypt.org/docs/supported-domains that appears under the "Subscriber Information" on /docs, and basically says:
/rate-limits, we calculate rate limits based on domains in the Public Suffix ListI suggest a new README, because the line numbers of the PSL import may change so linking to the lines isn't reliable.
I think that just having it in a file in the repo may confuse people if it doesn't also include information about how to check which version is deployed in which environment. I almost wonder if the PSL version should be accessible directly through an endpoint somehow, either through /build or something like it, or maybe something in the meta section of the /directory?
Maybe I'm very pessimistic now (at least sleap deprived), but while I think both ideas above me are GREAT (I do like good quality documentation covering all basis), I do have a "but": is anybody actually going to read that before they open a thread on this Community?
Hahahaha!
So true!
We will just have to point them to it.
[as we always do - RTFM]
Maybe not, but it may be nice if the community had an authoritative place to direct them rather than relying on @Nummer378's separate boulder-build-monitoring and digging into which commits were done when and such.
What about my digging? 
Keep digging!
We can all use the exercise.