Automatic certificate renewal usually works quietly until the day it does not. The first visible symptom may be a browser warning, a monitoring alert, or a control panel saying an ACME challenge failed. At that point it is easy to focus on the certificate itself even though the real problem may be DNS, CAA policy, HTTP routing, a CDN rule, or a stale challenge record.
A useful renewal investigation starts by identifying which ACME challenge method the certificate authority attempted, then checking the public path that the authority must validate. The certificate authority cannot see your internal configuration. It sees public DNS and public HTTP behavior. That makes external validation especially important.
Start with the exact renewal error
Do not begin by deleting certificate files or reissuing repeatedly. Record the failure message first. Look for phrases such as:
- unauthorized or invalid response;
- DNS problem or NXDOMAIN;
- CAA record forbids issuance;
- timeout or connection refused;
- incorrect TXT record;
- too many redirects;
- rate limit reached.
The error often tells you which layer to inspect. A DNS-01 failure and an HTTP-01 failure have very different troubleshooting paths.
HTTP-01 requires a public challenge path
For HTTP-01, the ACME client places a token at a predictable path under the website:
http://example.com/.well-known/acme-challenge/<TOKEN>Let's Encrypt documents that HTTP-01 validation uses port 80. Its validator follows redirects, but only within defined limits and only to HTTP or HTTPS destinations on the permitted ports. If a firewall blocks port 80, a reverse proxy sends the challenge somewhere unexpected, or an application catches the path and returns its own page, validation can fail even though normal HTTPS traffic looks healthy.
Before changing the certificate configuration, check whether the challenge path is publicly reachable from outside your network. A common mistake is an application-wide redirect or authentication rule that treats /.well-known/acme-challenge/ like an ordinary route.
Check CDN and reverse-proxy behavior
CDNs and proxies can make HTTP-01 failures confusing because the origin server and the public response are not the same thing. An ACME client may write the correct token on the origin while the CDN serves a cached 404, redirects to another hostname, or applies a security rule before the request reaches the origin.
Check the public response, not only the file on disk. If a CDN is involved, confirm that the challenge path is not cached incorrectly, rewritten, blocked by a WAF rule, or redirected to a host that is not covered by the current validation flow.
Vulnify's Redirect Chain Checker can help show how a public URL is being redirected, while the SSL Certificate Checker and TLS Deep Analysis can confirm the current public certificate and TLS state. These checks do not run your ACME client or repair the renewal job.
DNS-01 failures are usually about the public TXT record
DNS-01 proves control by publishing a TXT value below _acme-challenge for the name being validated. It is also the challenge type commonly used when a wildcard certificate is required.
_acme-challenge.example.com. 300 IN TXT "challenge-value"If validation fails, check the authoritative DNS response. Problems often come from the wrong DNS zone being edited, stale delegation, a record created at the wrong hostname, DNS propagation timing, or automation using credentials that no longer have permission to update the zone.
Do not trust only the DNS provider's control panel. Query what the public DNS returns. Vulnify's DNS Record Lookup is useful for that public-state check.
Wildcard certificates change the challenge requirement
HTTP-01 cannot be used to validate a wildcard identifier such as *.example.com. DNS-01 is the standard ACME path for wildcard issuance. If an automated renewal suddenly tries to obtain a wildcard through a configuration that only supports HTTP-01, the problem is architectural rather than a transient network error.
For production wildcard renewals, DNS automation is usually safer than asking someone to publish a new TXT record by hand every few months. The automation account should have the narrowest DNS permissions the provider supports and should be protected like any other production credential.
CAA can block an otherwise valid renewal
Certification Authority Authorization records let a domain owner specify which certificate authorities are permitted to issue certificates for the domain. RFC 8659 defines the mechanism. A restrictive CAA policy is valuable, but it also means a provider change can break renewal if the new CA is not authorized.
For example:
example.com. 3600 IN CAA 0 issue "letsencrypt.org"This kind of record expresses an issuance policy. If your certificate platform later switches to a different CA, renewal may fail until the CAA policy is intentionally updated.
Use Vulnify's CAA Record Analyzer to inspect the public CAA state. The tool can help show what the DNS currently advertises. The decision about which CA should be authorized still belongs to the domain owner.
Remember CAA lookup behavior for subdomains
CAA troubleshooting can be misleading when the certificate name is a subdomain. The relevant policy may be inherited from a parent domain when no closer CAA record exists. Do not check only the exact host and assume that an empty answer means there is no policy affecting issuance.
Also check for DNS errors. A broken authoritative response can prevent a CA from determining the applicable policy. If the failure message mentions CAA and DNS together, investigate DNS health before changing the authorization record.
Check the names being requested
Renewal jobs often evolve. A certificate that once covered example.com and www.example.com may later be configured to include api.example.com, an old staging name, or a hostname that no longer resolves. ACME validation generally has to succeed for the identifiers in the order.
Review the requested Subject Alternative Names. Remove names the service no longer uses rather than keeping them in the certificate forever. For names that should remain, confirm DNS points to infrastructure that can complete the selected challenge.
Separate certificate renewal from certificate installation
Sometimes the CA issued the renewed certificate successfully, but the web server is still presenting the old one. That is not an ACME validation failure. It is a deployment or reload problem.
Compare the certificate files on the server with what an external client receives. Check whether the web server or load balancer reloaded after renewal. In multi-node environments, make sure the new certificate reached every node. A CDN may also terminate TLS before traffic reaches your origin, so the certificate users see may be managed in a different system.
Vulnify's SSL Certificate Checker is helpful here because it inspects the public endpoint. If the certificate on disk says November but the public checker still sees October, you have narrowed the problem to deployment rather than issuance.
Check expiration before it becomes an incident
Automatic renewal should be monitored, not merely configured. A cron job can fail silently for weeks while the existing certificate remains valid. By the time users see an error, the organization has lost the recovery window that automation was supposed to provide.
Monitor both the renewal job and the public certificate expiration date. The public check matters because a successful local job does not guarantee the new certificate is being served.
Avoid turning troubleshooting into a rate-limit problem
Repeatedly requesting production certificates while experimenting can trigger certificate-authority rate limits. Use staging environments or the CA's testing endpoint when available, especially while fixing challenge automation. Once the validation path works reliably, return to the production issuance endpoint.
Keep logs from the ACME client. A clean timeline of challenge creation, validation request, DNS or HTTP response, and issuance is more useful than repeatedly pressing a renewal button.
A practical ACME troubleshooting order
- Capture the exact ACME error and requested certificate names.
- Identify whether the challenge is HTTP-01, DNS-01, or another supported method.
- For HTTP-01, verify port 80 and the public
/.well-known/acme-challenge/path. - Inspect redirect, CDN, WAF, and proxy behavior.
- For DNS-01, query the public TXT record and confirm authoritative DNS.
- Check CAA authorization for the requested names.
- Confirm stale or retired hostnames are not still part of the order.
- If issuance succeeded, verify that the new certificate was actually installed and served.
- Use a staging CA endpoint while testing repeated changes.
- Add monitoring so the next failure is detected before expiration.
Use Vulnify to compare the public layers
Vulnify does not operate your ACME client or renew certificates for you. It is useful for checking the public conditions around the failure. The CAA Record Analyzer shows the authorization policy visible in DNS. DNS Record Lookup checks public records. Redirect Chain Checker can expose challenge-path redirection behavior. SSL Certificate Checker and TLS Deep Analysis show the certificate and TLS configuration that visitors actually receive.
That combination is useful because certificate incidents often cross several systems. The CA sees DNS and public HTTP. Your browser sees the edge certificate. Your server sees local files. Troubleshooting becomes much faster when you compare those views instead of assuming they are identical.
Final renewal check
Once renewal works again, test the whole path rather than stopping at "certificate issued." Confirm the intended names, the public certificate chain, the expiration date, the HTTPS endpoint, and the next automatic renewal schedule. Document any CAA or DNS changes so another administrator understands why they exist.
Certificate automation is reliable when the validation path is simple, externally verifiable, and monitored. Most renewal failures become manageable once you identify which public proof the CA expected and check that proof directly.