SSL and HTTPS Problems

Let’s Encrypt Certificate Failed

Intermediate Risk: medium

Last reviewed August 7, 2026

Hosting access may not be needed Database access usually not needed

Direct answer

A Let’s Encrypt certificate fails to issue or renew when the ACME client cannot prove you control the domain — most often because HTTP-01 cannot reach port 80, DNS points at the wrong place or a CDN proxy, a CAA record blocks issuance, or the authority has rate-limited recent attempts. Read the exact ACME error from your host or certbot log, fix validation reachability (or switch to DNS-01 when appropriate), then retry once instead of hammering the API.

Let’s Encrypt issues free 90-day certificates through the ACME protocol used by certbot, cPanel AutoSSL, Plesk SSL It!, and many host panels. Failure is almost never “Let’s Encrypt being down”; it is a validation, DNS, firewall, CAA, or rate-limit problem on your side of the path. This host-agnostic Website Repair guide separates those causes from a certificate that already expired, and from panel-specific AutoSSL or Plesk flows covered in related guides.

Intermediate

Key facts

Verifiable numbers and definitions — each claim links to its source.

Let's Encrypt validates domain control with ACME challenge types such as HTTP-01 and DNS-01 before issuing a certificate. (Let's Encrypt — challenge types)
Let's Encrypt recommends keeping port 80 reachable so HTTP-01 validation can complete even when the site redirects to HTTPS. (Let's Encrypt — allow port 80)
CAA DNS records can forbid Let's Encrypt from issuing for a domain until the CAA policy allows the right CA identifiers. (Let's Encrypt — CAA)

What the error means

ACME clients request a certificate only after Let’s Encrypt validates domain control. HTTP-01 expects a token to be reachable over plain HTTP on port 80 at `/.well-known/acme-challenge/…` on every name in the request. DNS-01 instead requires a matching TXT record under `_acme-challenge` and is required for wildcards. If DNS resolves to another server, a proxy answers instead of your origin, a firewall drops port 80, HTTPS redirects break the challenge path, disk quota prevents writing the token, or a CAA DNS record forbids the Let’s Encrypt CA, validation fails and no new certificate is minted. That is different from an already-installed certificate whose dates simply passed — expiry is a clock problem after a successful past issuance; this guide is about the issuance/renewal attempt itself failing.

Common symptoms

Host panel, certbot, or ACME client shows “authorization failed,” “challenge failed,” or similar on issue/renew
Browsers show Not Secure or certificate warnings after renewals stop succeeding
Failure emails from the host mention Let’s Encrypt, AutoSSL, or ACME without a new certificate appearing
Bare domain validates but `www` or a subdomain fails (partial name coverage)
Retries start returning rate-limit errors after several failed attempts
Proxied Cloudflare (or similar CDN) domains fail while DNS-only domains on the same server succeed
Logs show connection timeouts or unexpected responses fetching the HTTP-01 challenge URL

Most likely causes

01 DNS A/AAAA records do not point at the server running the ACME client
02 CDN/proxy (Cloudflare orange-cloud, etc.) intercepts HTTP-01 before it reaches origin
03 Firewall, WAF, security plugin, or `.htaccess` blocking `/.well-known/acme-challenge/` or inbound port 80
04 CAA DNS record that does not authorize Let’s Encrypt’s certificate authorities
05 Let’s Encrypt rate limits after too many failed or duplicate orders for the same names
06 IPv6 AAAA record published while the server is unreachable over IPv6 (dual-stack validation fails)
07 ACME client misconfigured webroot, missing scheduled renewal job, or expired DNS API credentials for DNS-01

What changed before the problem started

Domain moved behind a CDN/proxy or DNS was retargeted during a migration
Port 80 was closed “for security” or a force-HTTPS rule started catching challenge requests
A CAA record was added during hardening without allowing Let’s Encrypt
Host panel SSL automation was disabled, or the renewal cron/systemd timer stopped
Disk or inode quota filled so challenge files or certificates cannot be written
Subdomains were added to the certificate request without matching DNS records

Troubleshooting steps

01
Capture the exact ACME error before changing anything
Open the host SSL log, AutoSSL/Plesk history, or certbot output and copy the full failure text (unauthorized, connection refused, CAA, rate limited, etc.). The wording decides whether you fix DNS, port 80, CAA, or wait on limits — guessing wastes retries against rate limits.
02
Confirm public DNS points at the machine answering ACME
Compare the domain’s A/AAAA records to the server IP your host documents. Fix wrong or stale records first. If a CDN proxies the name, either set DNS-only for the validation window or use a DNS-01 flow your client supports so HTTP-01 is not required through the proxy.
03
Prove HTTP-01 reachability on port 80 when that method is used
From an external network, confirm `http://your-domain/.well-known/acme-challenge/` is not hard-blocked (timeout, 403 from WAF, or a redirect chain that never serves the token). Temporarily allow that path through firewalls and security plugins; keep port 80 open for challenges even if visitors use HTTPS.
04
Check CAA records for Let’s Encrypt authorization
Look up CAA for the domain. If CAA exists and does not permit the Let’s Encrypt CA identifiers your host uses, add the correct issue/issuewild entries or remove an overly strict record, then retry once.
05
Retry issuance once after the root cause is fixed
Trigger a single renew/issue from the panel or `certbot renew` / equivalent. Confirm the new certificate’s not-after date and that every required hostname is listed. Avoid rapid-fire retries while the same error remains.
06
Verify visitors and origin both see a valid cert
Test in a private window and with an SSL checker. If Cloudflare sits in front, confirm whether the failure was edge vs origin and that SSL/TLS mode matches a working origin certificate when using Full (Strict).

Capture the exact ACME error before changing anything

Open the host SSL log, AutoSSL/Plesk history, or certbot output and copy the full failure text (unauthorized, connection refused, CAA, rate limited, etc.). The wording decides whether you fix DNS, port 80, CAA, or wait on limits — guessing wastes retries against rate limits.

Confirm public DNS points at the machine answering ACME

Compare the domain’s A/AAAA records to the server IP your host documents. Fix wrong or stale records first. If a CDN proxies the name, either set DNS-only for the validation window or use a DNS-01 flow your client supports so HTTP-01 is not required through the proxy.

Prove HTTP-01 reachability on port 80 when that method is used

From an external network, confirm `http://your-domain/.well-known/acme-challenge/` is not hard-blocked (timeout, 403 from WAF, or a redirect chain that never serves the token). Temporarily allow that path through firewalls and security plugins; keep port 80 open for challenges even if visitors use HTTPS.

Check CAA records for Let’s Encrypt authorization

Look up CAA for the domain. If CAA exists and does not permit the Let’s Encrypt CA identifiers your host uses, add the correct issue/issuewild entries or remove an overly strict record, then retry once.

Retry issuance once after the root cause is fixed

Trigger a single renew/issue from the panel or `certbot renew` / equivalent. Confirm the new certificate’s not-after date and that every required hostname is listed. Avoid rapid-fire retries while the same error remains.

Verify visitors and origin both see a valid cert

Test in a private window and with an SSL checker. If Cloudflare sits in front, confirm whether the failure was edge vs origin and that SSL/TLS mode matches a working origin certificate when using Full (Strict).

When to stop troubleshooting

Stop retrying once you have the ACME error and the same underlying cause is unchanged — further attempts can trigger rate limits and extend the outage. Escalate if you lack DNS or firewall access, the domain is on managed hosting you cannot reconfigure, rate limits block urgent recovery for checkout/login traffic, or panel tools fail with opaque errors after DNS and port 80 clearly work.

Information to collect before requesting help

01 Full ACME / panel / certbot error text from the failed attempt
02 All hostnames that should be on the certificate (apex, www, subdomains)
03 Current A/AAAA targets and whether a CDN/proxy is enabled
04 Whether port 80 responds publicly and any WAF/security plugin in play
05 CAA lookup results for the domain
06 Hosting panel type (cPanel, Plesk, VPS/certbot, other) and last successful renewal date
07 Whether recent retries returned rate-limit messages

How a professional repairs the problem

We read the ACME failure literally, verify DNS and challenge reachability (HTTP-01 or DNS-01), clear CAA or WAF blockers, issue a valid certificate with the full chain, and restore reliable renewal automation plus independent expiry monitoring. When a host panel is involved we coordinate AutoSSL or Plesk SSL It! settings without treating an expired leftover certificate as the same problem as a failed issuance.

Frequently asked questions

Is this the same as an expired SSL certificate? +

Not quite. Expiry means a certificate was issued earlier and its dates lapsed. This guide covers the issue/renew attempt failing so a replacement never arrives — which often leads to expiry later if ignored.

Why does HTTP-01 need port 80 if the site is HTTPS-only? +

Let’s Encrypt’s HTTP-01 challenge is defined to use port 80. You can still serve visitors on HTTPS; keep port 80 open enough for ACME (and sensible redirects) or use DNS-01 instead.

Does Cloudflare always break Let’s Encrypt? +

No, but proxied records can intercept HTTP-01. Use DNS-only during validation, a compatible DNS-01 setup, or host/Cloudflare workflows designed for proxied origins — then re-enable the proxy.

How is this different from cPanel AutoSSL or Plesk Let’s Encrypt guides? +

Those walk panel-specific buttons and logs. This page stays host-agnostic around ACME validation. Use the cPanel or Plesk guides when you are fixing that exact UI; use this one when the failure is about challenges, DNS, CAA, or certbot-style clients.

What should I do if I am rate-limited? +

Stop issuing production requests, fix the validation problem (ideally prove it on staging), and wait for the limit window to clear. More failed production orders only delay recovery.

Can I install a paid certificate instead? +

Yes for an urgent workaround, but many paid CAs also need domain validation. Fixing DNS, CAA, and port 80 still matters for the next renewal — paid or free.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

You will receive a clear explanation of the likely cause.
We will tell you if the issue falls outside our repair scope.
No additional work will be performed without approval.
A backup should be created whenever access and website condition allow it.

Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form — use Password Pusher (self-destructing link). Prefer a dedicated Rescue 404 admin account, not your personal owner login; if you cannot create one yet, we will add ours after repair.