Why ACME Renewal Fails on Client Websites: An Agency Troubleshooting Guide

When acme renewal fails, it usually means the certificate authority could not validate control of the domain. The failure is rarely "SSL broke" in isolation. It is usually DNS pointing somewhere unexpected, an HTTP-01 challenge path being blocked, port 80 being closed or intercepted, a CAA record authorizing the wrong certificate authority, CDN or WAF rules changing the validation request, or a wildcard certificate that needs DNS-based validation.

For an agency, one failed renewal is not just a technical ticket. It can become a client-facing browser warning, an emergency DNS access chase, and a question about whether the agency is actually watching the client's website. The practical fix is to troubleshoot the validation path before renewal day, document the owner of each moving part, and use checks like 47-Day Renewal Pre-Flight to find public readiness signals before the certificate window gets tight. For a broader portfolio view, run the free 10-domain agency audit.

CertPilot's methodology explains how it uses public certificate, DNS, and RDAP data. Pre-flight checks reduce surprises, but they do not guarantee certificate issuance or replace your ACME client, host, DNS provider, or certificate authority.

What "ACME renewal failed" usually means

ACME is the protocol many certificate automation systems use to request and renew public TLS certificates. The public standard is RFC 8555. In plain English, ACME lets a certificate client ask a certificate authority for a certificate, then prove it controls the domain through a validation challenge.

When renewal fails, the certificate authority is usually saying one of these things:

• I could not reach the validation file.
• The DNS record I expected was missing or wrong.
• The domain did not resolve to the expected place.
• The domain's CAA policy does not authorize this CA.
• The request asked for a wildcard certificate but used the wrong validation method.
• The validation result changed before I could complete issuance.

That is why ACME troubleshooting should start with validation, not with the certificate file itself.

Why this becomes harder for agencies managing client websites

Single-site owners can often reason about one host, one DNS zone, and one renewal method. Agencies inherit mixed stacks:

• WordPress on cPanel.
• Webflow, Shopify, or managed SaaS platforms.
• Cloudflare in front of origin hosting.
• Client-owned registrar accounts.
• DNS zones managed by old vendors.
• Paid certificates mixed with Let's Encrypt certificates.
• Staging and production domains that look similar but renew differently.

Shorter public certificate lifetimes make every weak assumption show up more often. A renewal path that failed silently once a year can become a recurring operational risk. The agency needs a repeatable troubleshooting model, not a heroic scramble.

Failure cause 1: DNS does not point where the agency thinks it points

ACME validation depends on the public DNS answer, not the spreadsheet answer, the old launch checklist, or what someone remembers from the migration.

Common DNS causes include:

• The apex domain points to one platform while www points to another.
• The client changed nameservers after launch.
• A stale A record points to an old server.
• A CDN proxy changes what the certificate authority reaches.
• Split responsibility means the agency controls hosting but not DNS.

Before debugging the ACME client, confirm the public A, AAAA, CNAME, NS, and relevant TXT records. If DNS has drifted, read how to monitor DNS changes across client websites and the agency guide to DNS drift.

Failure cause 2: HTTP-01 challenge path is blocked

HTTP-01 proves domain control by serving a token from a public URL under /.well-known/acme-challenge/. Let's Encrypt documents the common challenge types in its challenge type guide.

The site can look normal while the challenge path fails. Common causes include:

• Security plugins blocking dot directories.
• Rewrite rules redirecting every unknown path to the homepage.
• Basic auth on staging or recently launched sites.
• WAF rules blocking unfamiliar user agents.
• Static hosting rules that do not serve the challenge directory.
• A deployment process that removes the challenge file too early.

The important test is not "does the homepage load?" It is "can the certificate authority reach the expected token path during validation?"

Failure cause 3: port 80 is closed or intercepted

HTTP-01 validation uses HTTP. A clean HTTP-to-HTTPS redirect is often fine. A blocked, intercepted, or captive response is not.

Port 80 risk appears when:

• Firewall rules block HTTP entirely.
• The load balancer only listens on 443.
• The CDN handles HTTP differently than HTTPS.
• A redirect loop prevents the challenge URL from resolving.
• A security rule redirects the challenge path to a login page.

If the renewal method is DNS-01, port 80 may not matter. If the renewal method is HTTP-01, port 80 and the challenge path matter a lot. The dedicated guide on port 80 and ACME renewal covers this in more detail.

Failure cause 4: CAA records block the issuing CA

CAA records let domain owners specify which certificate authorities may issue certificates for a domain. CAA is useful, but misaligned CAA can block the certificate authority your host or ACME client is trying to use.

The failure pattern is common after migrations:

1. The client previously used one certificate provider.
2. DNS contains a CAA policy for that provider.
3. The site moves to a host using a different CA.
4. Renewal fails because the old CAA policy is still active.

Let's Encrypt has a CAA documentation page, and the CAA standard is RFC 8659. For an agency-focused version, use the CAA record check guide.

Failure cause 5: CDN, WAF, or redirect rules interfere

CDNs and WAFs are useful, but they add another layer between the certificate authority and the origin host. ACME failures can happen when edge rules treat validation traffic differently from normal browser traffic.

Check for:

• "Always use HTTPS" rules that break HTTP-01.
• Page rules that redirect /.well-known/*.
• Bot protection that blocks validation requests.
• Origin certificates that do not match public certificates.
• Proxy modes changed during a migration.
• Different behavior for apex and www.

The agency question is simple: which layer handles the validation request? If nobody knows, renewal risk is higher.

Failure cause 6: wildcard certificates require DNS-based validation

Wildcard certificates normally require DNS-01 validation. That means the renewal depends on DNS access, TXT record creation, propagation, and any DNS provider automation used by the ACME client.

Wildcard failures are often ownership failures:

• The agency controls hosting but not DNS.
• The client owns DNS but does not respond quickly.
• The DNS API token expired.
• The wrong zone is being updated.
• CAA issuewild does not authorize the intended CA.

For more detail, read wildcard certificate renewal risks for agencies.

Failure cause 7: expired domains or registrar/DNS ownership gaps

Sometimes the certificate process is healthy but the domain is not. If the domain expired, nameservers changed, or the registrar account is inaccessible, ACME validation can fail because public DNS no longer behaves as expected.

Agencies should track domain ownership alongside certificates. Certificate renewal risk and domain expiry risk are separate issues, but they collide on renewal day. The domain expiry monitoring guide for agencies explains how to treat domain registration as part of client operations.

Failure cause 8: staging/production or webroot confusion

ACME clients need to place validation material in the right place. Renewal can fail when:

• The client was configured against a staging hostname.
• The webroot path changed during deployment.
• The active server differs from the server running the ACME client.
• A container rebuild removed challenge storage.
• The certificate covers names that point to different platforms.

This is common after migrations. The site may work because production traffic reaches the new stack, while the renewal job still runs on the old stack.

Failure signal table

| Failure signal | Likely cause | What to check | Agency risk | |---|---|---|---| | HTTP challenge returns 404 | Token is not being served | Webroot, rewrite rules, challenge directory | Renewal fails close to expiry | | HTTP challenge redirects to homepage | Redirect rule catches challenge path | Redirect rules, CMS plugins, CDN rules | Hard-to-debug false "site is up" state | | Connection refused on port 80 | HTTP listener or firewall missing | Firewall, load balancer, host config | HTTP-01 cannot validate | | CAA unauthorized error | CAA excludes intended CA | CAA issue/issuewild records and current issuer | Host cannot issue expected certificate | | DNS TXT never appears | DNS-01 automation failed | DNS API token, zone, propagation | Wildcard renewal blocked | | Apex works, www fails | Different DNS or host path | A/CNAME records and certificate SANs | Partial client outage | | Renewal job runs on old server | Migration left automation behind | ACME client location and active DNS | Hidden operational debt |

A practical ACME renewal troubleshooting checklist

Use this order when a client renewal fails:

1. Confirm the exact hostname that failed.
2. Check current certificate expiry and issuer.
3. Check A, AAAA, CNAME, and NS records publicly.
4. Identify the validation method: HTTP-01, DNS-01, TLS-ALPN-01, or platform-managed.
5. If HTTP-01, test port 80 and the challenge path behavior.
6. If DNS-01, confirm the TXT record can be created in the authoritative zone.
7. Check CAA records for the apex and relevant parent domains.
8. Review CDN, WAF, and redirect rules.
9. Confirm who owns DNS, hosting, and the ACME client.
10. Document the fix and the renewal owner.

Do not change DNS or certificate automation blindly. A quick CAA or SPF-style "cleanup" can break another platform if you do not know the full sender or certificate context.

What to check before renewals become shorter and more frequent

Before certificate lifetimes shrink further, agencies should inventory:

• Domains and hostnames covered by each certificate.
• Current issuer and renewal method.
• ACME challenge type.
• DNS owner.
• Hosting owner.
• CAA policy.
• Whether wildcard certificates are used.
• Whether port 80 is expected to be reachable.
• Who receives renewal failure notices.
• Whether the client gets proof reports showing the checks.

This is where monitoring becomes a client-service process. A certificate dashboard helps technical teams, but a monthly proof report helps account managers show clients that the agency is protecting the site.

How 47-Day Pre-Flight helps reduce renewal surprises

47-Day Renewal Pre-Flight checks public readiness signals such as SSL expiry, DNS basics, CAA records, port 80 reachability, and HTTP-to-HTTPS behavior. It is useful before onboarding a client, before a hosting migration, before a renewal window, or during a care-plan review.

Pre-flight is not a certificate authority, ACME client, or hosting provider. It does not issue or renew certificates. Its value is earlier visibility: finding the conditions that may increase renewal risk before the browser warning appears.

Related 47-Day SSL Resources

• How to test if a host is truly ACME-ready
• HTTP-01 vs DNS-01 for client websites
• The CAA record gotcha that can break client SSL renewals
• SSL certificate renewal workload calculator
• 47-day SSL agency care plan guide

Frequently Asked Questions

Why does ACME renewal fail if the website still loads?

ACME renewal can fail because validation uses a specific path, DNS record, or certificate authority rule, not just the homepage. A client site may load normally over HTTPS while /.well-known/acme-challenge/ is blocked, port 80 is unreachable, CAA excludes the intended CA, or the DNS-01 TXT record is being written to the wrong zone. For agencies, the fix is to check the validation method and the public validation path instead of assuming a working homepage means renewal is safe.

Does an ACME renewal failure mean Let's Encrypt is down?

Usually no. A failed Let's Encrypt or ACME renewal is more often caused by local domain, DNS, HTTP, CAA, or hosting configuration. Certificate authorities can have incidents, but agency troubleshooting should first confirm DNS resolution, challenge reachability, CAA authorization, and whether the ACME client still has the access it needs. If those checks pass, then reviewing CA-side status or rate limits may make sense.

Can CertPilot fix an ACME renewal failure?

No. CertPilot does not issue certificates, renew certificates, update DNS, or replace your ACME client. CertPilot helps agencies check public SSL, DNS, CAA, RDAP, and readiness signals so they can see risk earlier and document it in client operations. The actual fix may need to happen in the hosting panel, DNS provider, CDN, WAF, registrar, or ACME client configuration.

Is HTTP-01 or DNS-01 better for agencies?

Neither is universally better. HTTP-01 can be simpler for normal websites where the web server is reachable and the challenge path is not blocked. DNS-01 is often better for wildcard certificates, locked-down hosts, and cases where DNS automation is reliable. Agencies should document the challenge type per client because each method creates different ownership and failure risks.

Should agencies check CAA even when no CAA record exists?

Yes, but a missing CAA record is not automatically a problem. The important question is whether the domain's CAA policy, if present, allows the certificate authority used by the host or ACME client. Agencies should check CAA during onboarding, migrations, CA changes, wildcard certificate setup, and renewal-readiness reviews.

How often should agencies run ACME readiness checks?

Agencies should run readiness checks during onboarding, before migrations, before certificate renewal windows, after DNS or CDN changes, and as part of recurring care-plan operations. Shorter certificate lifetimes make these checks more important because renewal events happen more often. A one-time check is useful, but recurring visibility is better for client portfolios.