For now, you can “cheat” that rate limit by – and i know this is unintuitive – adding a fourth, useless name to any new certificates. ("www.aperturegroup.co", “i-love-rate-limits.theaperturegroup.co”, whatever, as long as it’s valid.)
You may still run into the other rate limits, though.
More importantly, why are you issuing so many identical certificates? Is something going wrong with your software? Or maybe you should use a different architecture?
Truth is I’m not trying to issue multiple certificates. I’m running an email server on mailinabox.email which has an integrated and automated certificate provisioning tool that works via Letsencrypt - I suspect it is running the autocert-bot behind the scenes but I’m not certain. The certificates for this server expire in about a week now, starting 14 days ahead the system is supposed to replace them with new ones. Each attempt (one every 24 hours) has failed with this error and I don’t understand why unless the system is requesting them far more often than it indicates. I realize my problem may be as much about the mailinabox system as it is about letsencrypt, but I use this email server in 3 locations and this is the first issue with the provisioning - the others are working just fine.
This definitely looks like an issue with Mail-in-a-Box. It’s probably running into a problem after renewal where it fails to store the new certificate (or something like that), and this causes the renewal to be attempted again and again whenever the next cron run occurs. According to crt.sh, you should be able to issue certificates today. I’d say try to renew again and look for relevant logs in /var/log/syslog.