Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is:
I ran this command:
Kubernetes Cetrificate manager
It produced this output:
order is in "errored" state: Failed to create Order: 429 urn:ietf:params:acme:error:rateLimited: Error creating new order :: too many certificates (5) already issued for this exact set of domains in the last 168 hours: accounts.thezishi.com,admin.accounts.thezishi.com,api.accounts.thezishi.com,api.live.adaptive.thezishi.com,hr.live.adaptive.thezishi.com,report.adaptive.thezishi.com: see Rate Limits - Let's Encrypt
My web server is (include version):
latest Nginx on Kubernetes 1.18.17
The operating system my web server runs on is (include version):
Ubuntu docker 20.04
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don't know):
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of
certbot --version or
certbot-auto --version if you're using Certbot):
We got a problem and missed our live k8s cluster and recreate it by our Terraform code,
this time I couln't get certificates
check it by this command
kubectl describe certificate tls-secret-new --namespace=production
and got the following error:
tive.thezishi.com,hr.live.adaptive.thezishi.com,report.adaptive.thezishi.com: see Rate Limits - Let's Encrypt
Normal Generated 17m cert-manager Stored new private key in temporary Secret resource "tls-secret-new-w5bz2"
Normal Requested 17m cert-manager Created new CertificateRequest resource "tls-secret-new-snsb2"
Normal Generated 16m cert-manager Stored new private key in temporary Secret resource "tls-secret-new-z4nzk"
Normal Requested 16m cert-manager Created new CertificateRequest resource "tls-secret-new-snbqh"
Warning Failed 15m cert-manager The certificate request has failed to complete and will be retried: Failed to wait for order resource "tls-secret-new-snbqh-2277745711" to become ready: order is in "errored" state: Failed to create Order: 429 urn:ietf:params:acme:error:rateLimited: Error creating new order :: too many certificates (5) already issued for this exact set of domains in the last 168 hours: accounts.thezishi.com,admin.accounts.thezishi.com,api.accounts.thezishi.com,api.live.adaptive.thezishi.com,hr.live.adaptive.thezishi.com,report.adaptive.thezishi.com: see Rate Limits - Let's Encrypt
➜ zishi kubectl describe certificate tls-secret-new --namespace=production
I think the error message explains itself... You issued too many certificates in the duration and are not able to create more until the rate limit expires.
Is there an reason you create this much certificate?
Please use one of the previously issued 5 certificates. Thank you.
Thanks for the answer but as I mentioned, our kubernetes cluster deleted and we don’t have those certificates. Can I delete existing ones from letsencrypt ?
Nope, you can't.
You need to add an additional subdomain, wait a week, or use a different certificate authority.
Only thing I'd add to that linked explanation is that the issuance of the certificate isn't the end of resources Let's Encrypt has to use: Each certificate has to have Online Certificate Status Protocol information generated and signed every few days until the certificate reaches the expiry date, whether it is revoked or valid. Every certificate issued consumes finite signing resources by the hardware security modules for these OCSP responses across its whole 90-day lifespan.
In your organisation presumably you do have some concept of permanent data? The Certificates from Let's Encrypt are permanent data. You should no more delete the certificates than you would for example delete all the source code for your system, or delete all the employment records you keep. This error message is caused by having not merely deleted all the certificate data once, which is a bad idea, but done so over, and over, and over again, which means you've got a fundamental mistake in the way you've approached the problem. You should re-design this part of your system.
@jcjones I have a question about that. If a certificate is revoked, presumably the CA no longer has to sign new OCSP status messages for it (because its status continues to be "revoked" rather than "valid" throughout its subsequent lifetime). If that's so, why wouldn't it be beneficial to revoke unused certificates? We normally tell people that revocation has no benefit and is unnecessary except in cases of compromise, but if it could change the OCSP-related signing load, maybe it could be beneficial?
Typing with my thumbs here, so forgive not providing references, but root store requirements  don't make a distinction in OCSP lifetime between revoked and valid OCSP responses, so there's no advantage for HSM signature processing time.
 pkipolicy/policy.md at master · mozilla/pkipolicy · GitHub
You right, but we had infrastructure as code in terraform which run through a pipeline in Azure DevOps. Unfortunately with a mistake. I put the terraform state key name in a new pipeline and that deleted all live environment. Some resources have backup and we restored them but kubernetes and all it’s secrets are gone.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.