My domain is:
We issue wildcard certificates for MongoDB Atlas cluster hostnames. The identifiers fall into a few tiers:
- Top-level wildcards:
*.mongodb.net,*.azure.mongodb.net,*.gcp.mongodb.net - Per-project wildcards:
*.<pin>.mongodb.net(e.g.*.mrjc8kox.mongodb.net), where the pin is a unique per-project label we generate
(These are already public via Certificate Transparency. I can provide the specific per-project identifiers that were mid-issuance during the incident window if that helps the investigation.)
I ran this command:
Not applicable in the traditional sense. We issue certificates programmatically over ACME using the acme4j Java client (v4.0.0) against the v2 production directory (https://acme-v02.api.letsencrypt.org/directory), not an interactive CLI like certbot. The order call is effectively:
Session session = new Session(URI.create("https://acme-v02.api.letsencrypt.org/directory"));
Login login = session.login(accountUrl, accountKeyPair);
Order order = login.getAccount().newOrder().domains(domains).create();
It produced this output:
org.shredzone.acme4j.exception.AcmeUnauthorizedException: Account blocked :: your account has been blocked due to excessive traffic
This error occurred repeatedly between 2026-07-09 18:43:25 and 2026-07-09 20:28:14 UTC on account ID 69013297. Full timeline below.
My web server is (include version):
Not applicable. We validate using DNS-01 challenges (answered via DNS TXT records), so no web server serves validation tokens. Issued certificates are served by our cluster proxy fleet rather than a single host.
The operating system my web server runs on is (include version):
Not applicable for the same reason. The issuance service is a backend Java application (built for Java 17), not a single web-serving host. Happy to share more runtime detail if useful.
My hosting provider, if applicable, is:
Internal MongoDB infrastructure.
I can login to a root shell on my machine (yes or no, or I don't know):
Yes.
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
No. Issuance is fully automated through our own service using acme4j.
The version of my client is:
acme4j (Java) v4.0.0, using the ACME v2 production directory.
Between 2026-07-09 18:43:25 and 2026-07-09 20:28:14 UTC, our account (ID 69013297) received a surge of AcmeUnauthorizedException errors on certificate issuance calls, with the message above.
Timeline:
- ~18:05:00 — brief spike to ~219 orders/minute
- ~18:15:00 — order rate dropped back to ~25 orders/minute
- 18:43:25 — first "Account blocked" error observed
- ~18:55:00 — our systems automatically halted all issuance requests in response to the errors
- 20:26:00 — we resumed requests
- shortly after — the blocked errors subsided and stopped entirely
A few things we want to highlight:
We did not observe any standard rate-limit errors (e.g. urn:ietf:params:acme:error:rateLimited) in the 24 hours before or during this window, nor any sign of degradation on our end before the spike.
Our issuance is designed around Let's Encrypt's published rate limits. Each certificate identifier carries a unique per-project DNS label, so we are not repeatedly requesting the same identifier, and we have historically stayed within the documented per-identifier Duplicate Certificate limit (5 per identifier per 7 days). Because of that, the Account blocked :: excessive traffic response looks like a separate account-level protection rather than one of the documented per-identifier limits, which is consistent with us seeing no rateLimited errors leading up to it.
What we'd like to understand:
- Whether the 18:05–18:15 spike to ~219 orders/minute is what triggered the block, or whether something else caused it.
- If it was traffic-related, what threshold or signal we crossed, so we can build safeguards (client-side pacing / concurrency caps) to stay under it going forward.
Thanks in advance for any detail you can share.