Infra Notes

cert-manager Certificate Ready False: trace CertificateRequest and ACME

Troubleshoot cert-manager Certificate Ready False by following Certificate, CertificateRequest, Order, and Challenge resources instead of repeatedly deleting Secrets.

Published

Kubernetescert-managerCertificate Ready FalseLet's EncryptACME ChallengeTLS

Problem

A cert-manager Certificate remains Ready=False, the target TLS Secret is absent, or an Ingress continues serving a default certificate. The Certificate is only the start of the issuance chain; the actionable error may be on its Issuer, CertificateRequest, Order, or Challenge.

Quick answer

Follow the resource chain in the same namespace:

bash

kubectl describe certificate <certificate> -n <namespace>
kubectl get certificaterequest -n <namespace>
kubectl describe certificaterequest <request> -n <namespace>
kubectl get order,challenge -n <namespace>
kubectl describe challenge <challenge> -n <namespace>

Read status.conditions, reason, message, and Events at each level. The lowest failing resource usually contains the most specific explanation.

Verify the issuer boundary

Check whether the Certificate references an Issuer in its namespace or a cluster-scoped ClusterIssuer:

bash

kubectl get certificate <certificate> -n <namespace> \
  -o jsonpath='{.spec.issuerRef.kind}{"/"}{.spec.issuerRef.name}{"\n"}'
kubectl describe clusterissuer <name>

An Issuer cannot be referenced from another namespace. Confirm its Ready condition, account registration, credentials, and CA endpoint before debugging the application Ingress.

HTTP-01 checks

For HTTP-01, cert-manager creates a solver path that the public ACME server must reach over HTTP. Verify:

  • Public DNS resolves the certificate hostname to the intended ingress endpoint.
  • Port 80 is reachable from the internet.
  • Ingress class selection sends the solver route to the correct controller.
  • Redirect, authentication, WAF, or allowlist rules do not block /.well-known/acme-challenge/.
  • Split-horizon DNS does not make internal success look like public success.

Inspect the Challenge’s presented URL and test it from outside the cluster network when possible.

DNS-01 checks

For DNS-01, verify the DNS zone, credential scope, delegated zone, and authoritative nameservers. A TXT record visible through one recursive resolver may not yet be available from the authoritative path used during validation.

Do not grant broad DNS administration merely to solve AccessDenied. Restrict the identity to the required hosted zone and record operations.

Secret and renewal checks

The Certificate Ready condition requires a target Secret containing a non-expired certificate and matching private key. Inspect metadata without dumping private key material:

bash

kubectl get secret <secret-name> -n <namespace>
kubectl get certificate <certificate> -n <namespace> -o yaml

Deleting the Secret forces issuance but destroys evidence and may consume CA rate limits. Use it only when the diagnosed recovery procedure requires replacement.

Prevention

Alert on certificate expiry and Ready status, retain Kubernetes events centrally, test issuers with staging ACME endpoints, and treat DNS/WAF changes as part of certificate delivery.

References