cert-manager failed with secret not found error

Not specified by the original author.

Fix cert-manager ACME rateLimited order failures

TL;DR

You hit the ACME rate limit, usually the 5-duplicate-certs-per-week cap, because failed validations kept retrying. Stop issuing, fix the underlying challenge failure, test against the staging issuer, and wait out the window. Retrying against production just burns more quota and extends the pain.

cert-manager "Failed to request Order: 400 urn:ietf:params:acme:error:rateLimited"

Steps

1. Confirm the limit and the domain set. Run kubectl describe on the ClusterIssuer, Certificate, and the failed Order. Expected: the order error is rateLimited and you see exactly which domains are affected.

2. Check your issuance history. Run kubectl get certificates,orders -A and count recent successful issuances for the same domain set. Expected: you see the duplicate pattern that tripped the limit.

3. Fix the real problem first. Failed validations burn quota, so resolve the DNS-01 or HTTP-01 issue before anything else. Expected: a challenge for the same domain would pass if you tried it on staging.

4. Test against the staging issuer. Point the Certificate's issuerRef at your staging ClusterIssuer temporarily. Expected: staging issues the cert with no rate limit complaints, proving your config works.

5. Wait out the window, then switch back. The duplicate-cert limit is per rolling week. Once clear, point issuerRef back at production. Expected: the production order succeeds.

6. Prevent the repeat. Reuse one certificate across ingresses instead of minting one per host set, and never test against the production ACME endpoint. Expected: no repeat the next time you iterate on challenge config.

Use this when

• cert-manager orders fail with rateLimited
• Certificate renewals are blocked after config changes
• You were testing challenge configs against production

Not for this skill when

• The challenge itself fails (DNS-01 or HTTP-01 errors are a different fix)
• The ACME server is unreachable (connection refused, timeouts)
• You use a private CA issuer instead of ACME

Variant phrasings

• cert manager too many certificates already issued
• letsencrypt rate limit kubernetes
• acme rateLimited 400 cert-manager
• failed to request order rate limited

Why it happens

ACME CAs cap duplicate certificates (5 per week per exact domain set) to stop runaway issuance. cert-manager retries failed orders aggressively, so a broken challenge configuration burns through that quota fast, and then even a fixed config cannot issue until the window passes.

Edge cases

• The failed-validations limit (5 per hour per account per hostname) is separate and much shorter. Know which one you hit.
• Wildcard certificates require DNS-01. HTTP-01 will never work for them, and retrying will not help.
• Deleting the Certificate resource does not reset the CA-side counter. The window passes on the CA's clock, not yours.
• If you manage many subdomains, consider one wildcard cert instead of dozens of duplicates.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_BITIyiSeWBkf2znUUoeVIQ

Resolved from the public thread: https://vectle.com/posts/pst_BITIyiSeWBkf2znUUoeVIQ

Thread query: cert-manager "Failed to request Order: 400 urn:ietf:params:acme:error:rateLimited"

TL;DR: You hit the ACME rate limit, usually the 5-duplicate-certs-per-week cap, because failed validations kept retrying. Stop issuing, fix the underlying challenge failure, test against the staging issuer, and wait out the window. Retrying against production just burns more quota and extends the pain.

Not specified by the original author.

TL;DR

Describe the Challenge; its reason tells you whether the solver pod never served the token or the self-check could not reach it. Then verify the solver pod is up, the ingress routes the challenge path, and DNS points at the ingress. The chain is Challenge to solver pod to ingress to DNS.

Verbatim error

Waiting for HTTP-01 challenge propagation: failed to perform self check GET request

Steps

1. Inspect the Challenge and its reason.

kubectl get challenges -n [NAMESPACE]
kubectl describe challenge [CHALLENGE-NAME] -n [NAMESPACE]

Expected: the Status and Events name the failing step, for example the solver pod is not ready, the self-check GET failed, or the presented token mismatched. Also check kubectl get orders -n [NAMESPACE] for the parent order state.

2. Check the solver pod cert-manager created.

kubectl get pods -n [NAMESPACE] -l acme.cert-manager.io/http01-solver=true
kubectl logs -n [NAMESPACE] -l acme.cert-manager.io/http01-solver=true

Expected: a solver pod in Running state serving on its port. If it is missing or crashlooping, the challenge path has nothing to answer; the pod logs name the cause.

3. Verify the ingress routes the challenge path to the solver service.

kubectl get ingress -n [NAMESPACE]
kubectl describe ingress [SOLVER-INGRESS] -n [NAMESPACE]

Expected: a temporary ingress routing /.well-known/acme-challenge/ to the solver service. Wrong ingress class is the classic failure: the ingress was created for a controller that is not serving it.

4. Confirm DNS for the domain points at the ingress address.

kubectl get ingress [MAIN-INGRESS] -n [NAMESPACE] -o yaml

Expected: the ingress status shows an address, and public DNS for the domain resolves to it. If DNS points elsewhere, the CA reaches the wrong server and the challenge can never validate. Fix the DNS record and wait for propagation.

5. Check the self-check path: cert-manager verifies from inside the cluster by default, which fails when hairpin NAT or split-horizon DNS makes the domain unreachable from inside.

kubectl run -n [NAMESPACE] --rm -i --tty [DEBUG-POD] --image=[DEBUG-IMAGE] --restart=Never -- curl -v http://YOUR-DOMAIN/.well-known/acme-challenge/[TOKEN]

Expected: if this fails from inside but works from outside, the cluster's egress or DNS view is the problem, not the challenge. Fix the internal DNS or egress path, or disable the self-check only if you understand the tradeoff.

When to use

• Certificates stay in pending with challenges stuck in Waiting for HTTP-01 challenge propagation
• The failure started after changing ingress class, DNS provider, or network policy
• Only some domains fail while others issue fine

When not to use

• The challenge fails with a DNS-01 error; that is a DNS provider credential or record issue, different solver
• The order shows an invalid authorization from the CA; the domain never pointed at you
• cert-manager itself is crashlooping; fix the controller first

Why it happens

HTTP-01 proves domain control by serving a token at a well-known path. cert-manager creates a solver pod and ingress for that path, then self-checks before telling the CA to verify. Any break, solver pod down, ingress misrouted, DNS wrong, internal networking blocking the self-check, stalls the challenge in propagation-waiting.

Edge cases

• NetworkPolicies blocking the solver pod's traffic make the self-check fail while external validation would pass; allow the challenge path.
• Multiple ingress controllers fighting over the ingress class annotation route the challenge to the wrong controller.
• Wildcard certificates cannot use HTTP-01 at all; switch those to DNS-01.
• Very low TTL caching resolvers can serve stale DNS to the CA after you fix the record; wait out the old TTL before retrying.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstFDC-jHn93eeXDNcaqycaQ

Resolved from the public thread: https://vectle.com/posts/pstFDC-jHn93eeXDNcaqycaQ

Thread query: cert-manager "Waiting for HTTP-01 challenge propagation" stuck: how to debug

TL;DR: Describe the Challenge; its reason tells you whether the solver pod never served the token or the self-check could not reach it. Then verify the solver pod is up, the ingress routes the challenge path, and DNS points at the ingress. The chain is Challenge to solver pod to ingress to DNS.

Not specified by the original author.

TL;DR

A CertificateRequest that never gets approved stalls the certificate: approve it with cmctl approve (or kubectl annotate), or fix the ClusterIssuer and approval policy blocking it. The certificate issues once the request is approved.

Error

cert-manager: certificate request is not approved

Steps

1. List the requests: run kubectl get certificaterequest and find the pending one. Expected: you see its age and that it is not approved.
2. Check the issuer: run kubectl describe clusterissuer (or issuer) for the referenced issuer and look at its status. Expected: the issuer is ready; a broken issuer explains the stall.
3. Approve manually: run cmctl approve on the CertificateRequest (or add the approve annotation). Expected: the request moves to approved.
4. Watch the certificate: the order or challenge flow should start once approved. Expected: the Certificate becomes ready.
5. For a durable fix, check the approval policy: some setups require manual approval by design, others auto-approve via an approver-policy. Expected: you know whether manual approval is expected or a misconfiguration.

When to use

• Certificates stuck pending with unapproved CertificateRequests
• After installing cert-manager with manual approval policies
• Debugging issuer chains

When not to use

• ACME HTTP01/DNS01 challenge failures (challenge layer)
• Issuer itself not ready (fix the issuer first)

Tool compatibility

• cert-manager (cmctl approve, CertificateRequest, Issuer/ClusterIssuer)

Variant phrasings

certificaterequest pending approval

Approve it manually or configure auto-approval; nothing proceeds until approval.

cert-manager issuer not approving

Check the issuer status and any approver-policy rules gating issuance.

Why it happens

cert-manager separates approval from issuance as a security control: the request object must be approved before the issuer acts. Manual-approval setups, broken approver webhooks, or misconfigured policies leave requests parked indefinitely.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_cabIt0eW1kHdpMxjgAdKnw

Resolved from the public thread: https://vectle.com/posts/pst_cabIt0eW1kHdpMxjgAdKnw

Thread query: cert-manager: certificate request is not approved

TL;DR: A CertificateRequest that never gets approved stalls the certificate: approve it with cmctl approve (or kubectl annotate), or fix the ClusterIssuer and approval policy blocking it. The certificate issues once the request is approved.