Context
A DNS01 challenge marked Presented can still remain pending. The solver may have created a TXT record, but cert-manager's self-check or the public certificate authority may not see the expected answer. Trace the ACME resources and DNS authority instead of repeatedly deleting the certificate request.
Follow the certificate resource chain
Record the Certificate, CertificateRequest, Order, and Challenge associated with the request. Inspect conditions, events, selected issuer, solver configuration, DNS name, and challenge state. Avoid posting private keys or provider credentials in diagnostic output.
Useful starting points include:
kubectl describe certificate NAME -n NAMESPACE
kubectl get certificaterequest,order,challenge -n NAMESPACE
kubectl describe challenge NAME -n NAMESPACE
Use resource names from the actual request. Multiple concurrent orders or stale resources can otherwise cause a successful record from one attempt to be mistaken for the failing attempt's evidence.
Verify the correct public authority
Identify the authoritative zone for the exact _acme-challenge name, including any delegation or CNAME arrangement supported by the solver. A record created in an internal zone with the same suffix may look correct in the provider console while being invisible to the public authority.
Query the relevant authoritative servers and appropriate recursive paths. Compare the TXT value, response code, and timing. A provider accepting an API write is different from all authoritative servers serving the new record.
Review the DNS provider identity's zone permissions. The solver should have the access it needs for the intended zone without exposing broad unrelated administration. A wrong zone selection or denied update requires correction; waiting longer will not make an unauthorized write succeed.
Understand the self-check resolver
cert-manager performs a self-check before presenting the challenge for external validation. Its DNS view can differ from the public internet because of cluster DNS, split-horizon zones, upstream filtering, or restricted network egress.
Compare the result from inside the cluster with the public authoritative answer. Review the installed cert-manager version's supported recursive-nameserver and self-check configuration before changing controller flags. A resolver override should fit the organization's DNS policy and remain able to resolve required authoritative information.
Also examine negative caching. A resolver that queried before the TXT record existed may retain a negative answer. Repeatedly creating new orders can add noise, consume rate limits, and make the original propagation problem harder to understand.
An illustrative split-horizon challenge
A company uses an internal private zone for its application domain. The solver writes the challenge to the correct public provider, but cluster queries are answered by the private zone, where the TXT record is absent. Public diagnostic queries succeed while the self-check continues to fail.
The team documents the split and configures a supported, policy-approved resolution path for the self-check. It verifies the exact public delegation and completes a staging-issuer test before relying on production renewal. Copying the challenge into arbitrary private zones would not establish a maintainable renewal design.
Quick diagnostic map
| Evidence | Hypothesis | Next check |
|---|---|---|
| Provider update error | Solver identity or zone mismatch | Challenge events and provider permissions |
| TXT public; self-check cannot see it | Split DNS or resolver path | In-cluster versus authoritative answer |
| TXT absent on authority | Publication or delegation issue | Correct zone and authoritative servers |
| Validation succeeds; served certificate old | Deployment handoff issue | Secret adoption and endpoint certificate |
A focused operator exercise
Use a test hostname and the ACME staging service supported by the issuer configuration. Record the selected solver, public zone, delegation, TXT value, and self-check result. Test resolution from both the controller's network and an appropriate public path.
Complete issuance, then verify the certificate actually served by the application endpoint. Rehearse renewal and confirm cleanup does not remove another active challenge's record. Keep provider credentials and private key material out of screenshots and reports; resource identifiers and public DNS evidence are sufficient for most troubleshooting.
Monitor the certificate users receive
Alert on renewal failures and the expiry of the externally served certificate. A fresh Secret alone does not prove ingress or another proxy adopted it. Keep DNS ownership and solver access in the certificate lifecycle runbook.
Frequently asked questions
Does Presented mean the certificate authority validated the domain?
No. It indicates a stage in challenge handling. Inspect self-check and ACME validation outcomes separately.
Should I delete and recreate the request until it works?
First identify the failing resource and DNS path. Repeated new orders can obscure evidence and encounter provider or authority limits.
Continue the investigation
- Certbot renewal: verify the HTTP challenge path
- Split DNS: test the resolver and client view together
Browse the cloud, server and infrastructure guide library for related operational questions.
Explore Clouvenix Secrets & Certificate Lifecycle Engineering to discuss implementation, validation and operational handover.
Technical reference
Troubleshooting Problems with ACME / Let's Encrypt Certificates - cert-manager Documentation