Introduction

When cert-manager shows a Let's Encrypt order in Pending state, it usually means the ACME challenge has not been validated yet. The fix is rarely on the certificate object alone; you usually have to inspect the related Order and Challenge resources and then correct the DNS or HTTP validation path.

Understand the cert-manager flow

For an ACME certificate, cert-manager typically creates resources in this chain:

• 'Certificate'
• 'CertificateRequest'
• 'Order'
• 'Challenge'

The Order stays pending while Let's Encrypt waits for the challenge to succeed. That is why the right debugging path is to move downward through these objects instead of staring only at the top-level certificate.

Start here:

kubectl describe certificate my-cert -n my-namespace
kubectl get order,challenge -n my-namespace

Then inspect the specific objects:

kubectl describe order my-cert-123456 -n my-namespace
kubectl describe challenge my-cert-123456-0 -n my-namespace

The two most common causes

Most pending orders come from one of two challenge types.

For HTTP-01, the common issues are:

• the ingress or gateway is not routing /.well-known/acme-challenge/... correctly,
• the public host does not point to the correct load balancer,
• or the solver ingress was created but is not reachable from the internet.

For DNS-01, the usual issues are:

• TXT records were not created correctly,
• DNS propagation is still incomplete,
• or the DNS provider credentials used by cert-manager are wrong.

The challenge description usually tells you which case you are in.

Example ClusterIssuer configuration

A minimal Let's Encrypt HTTP-01 issuer might look like this:

1apiVersion: cert-manager.io/v1
2kind: ClusterIssuer
3metadata:
4  name: letsencrypt-prod
5spec:
6  acme:
7    email: [email protected]
8    server: https://acme-v02.api.letsencrypt.org/directory
9    privateKeySecretRef:
10      name: letsencrypt-prod-account-key
11    solvers:
12      - http01:
13          ingress:
14            class: nginx

If the ingress class is wrong, the solver resources may be created but never become publicly reachable, which leaves the order pending.

A practical debugging workflow

A good sequence is:

1. confirm the certificate and issuer are valid,
2. inspect the Order and Challenge,
3. verify that the hostname resolves publicly,
4. check the HTTP or DNS solver path,
5. and only then retry.

For HTTP validation, you can often test the endpoint directly from outside the cluster once the solver ingress exists. For DNS validation, check the TXT record with dig or another public resolver.

If you are still building the configuration, use the Let's Encrypt staging environment first. That prevents rate-limit pain while the challenge flow is still being corrected. In day-to-day operations, this one habit saves a lot of time because it separates challenge debugging from production issuance concerns. It also protects you from unnecessary production failures. Staging is the right place to iterate on challenge configuration.

Common Pitfalls

The biggest mistake is assuming Pending means cert-manager is stuck internally. Most of the time it is waiting for an external validation step to succeed.

Another common issue is debugging only the Certificate object. The real explanation is almost always in the Order or Challenge resource.

Be careful with DNS caching and propagation timing. A TXT record that exists in your provider console may still be invisible to the public resolvers Let's Encrypt uses.

Finally, do not test repeatedly against the production ACME endpoint while the configuration is still wrong. Use staging until the solver path works consistently.

Summary

• 'Order Pending usually means the ACME challenge has not completed yet.'
• Inspect Order and Challenge resources, not just the Certificate.
• 'HTTP-01 problems are usually routing or public reachability issues.'
• 'DNS-01 problems are usually TXT-record or credential issues.'
• Use the Let's Encrypt staging endpoint while debugging to avoid rate limits.