Your free certificate will not issue or renew. Read the validation error, then fix DNS, the Cloudflare proxy, blocked .well-known paths, CAA records, port 80 or rate limits.
Your free certificate will not issue or renew. In cPanel, SSL/TLS Status shows domains with a red or yellow warning and a message about domain control validation (DCV). The AutoSSL log mentions NO_UNSECURED_DOMAIN_PASSED_DCV. Plesk, DirectAdmin or Enhance says the Let’s Encrypt certificate could not be issued. On a server you manage, Certbot prints urn:ietf:params:acme:error:unauthorized, Invalid response from http://example.com/.well-known/acme-challenge/..., Timeout during connect (likely firewall problem) or CAA record for example.com prevents issuance. Meanwhile the old certificate is counting down to expiry, or the new site has none at all.
Free certificates are issued automatically only after the certificate authority (CA) checks that you control the domain. Almost every failure is that check not reaching your server, or reaching the wrong one. This guide explains how the check works, shows you how to test it yourself from your own computer, and fixes the causes in order of how often they happen: DNS, Cloudflare, redirects and blocked paths, CAA records, firewalls and rate limits. If the certificate has already expired and visitors see a warning, read our guide on ERR_CERT_DATE_INVALID alongside this one.
cPanel’s AutoSSL, and the Let’s Encrypt features in Plesk, DirectAdmin and Enhance, all follow the same pattern: the panel asks a CA for a certificate, the CA sets a challenge, and the panel has to prove control of every name on the certificate before it is issued. There are two common ways to prove it:
| Method | How it works | What breaks it |
|---|---|---|
| HTTP validation (Let’s Encrypt calls it HTTP-01) | The panel puts a small file under http://example.com/.well-known/acme-challenge/ (cPanel’s Sectigo-powered provider uses /.well-known/pki-validation/), and the CA downloads it over port 80 |
DNS pointing elsewhere, a proxy or firewall in the way, redirects to the wrong place, rules that block the .well-known folder, port 80 closed |
| DNS validation (DNS-01) | The panel publishes a TXT record (for Let’s Encrypt, at _acme-challenge.example.com) and the CA looks it up |
The panel cannot edit your DNS because DNS is hosted somewhere else, slow DNS updates, DNSSEC errors |
Details from Let’s Encrypt’s documentation that matter for troubleshooting:
http: or https: on ports 80 or 443, and when redirected to HTTPS it does not check the certificate. So an ordinary redirect from HTTP to HTTPS, even with an expired certificate, does not break validation.*.example.com) can only be validated by DNS.cPanel also runs its own checks before contacting the CA, and it treats each name separately. AutoSSL usually tries your domain, www, and service subdomains such as mail, webmail and cpanel. Names that fail are left off the certificate and listed as warnings, while the names that pass are still covered. So a page of warnings about service subdomains is often harmless, as long as the names visitors use (example.com and www.example.com) passed. NO_UNSECURED_DOMAIN_PASSED_DCV is the serious one: none of the names that still need a certificate passed, so nothing new was issued.
curl and dig commands below run on your own computer, because you want to see what the outside world sees. On Windows, use curl.exe in PowerShell; dig is not built in on Windows, so use nslookup as shown, WSL, or our DNS lookup tool. Certbot commands run over SSH on the server, as root, and only apply to servers you manage. Replace example.com with your domain./var/log/letsencrypt/letsencrypt.log.Match the message to a cause:
| Message contains | Likely cause | Go to |
|---|---|---|
| does not resolve, NXDOMAIN, resolves to a different IP | DNS points elsewhere or the name does not exist | Step 2 |
| A Cloudflare IP address, or a Cloudflare error code | The domain is proxied through Cloudflare | Step 3 |
| 403, 404, 401, unexpected redirect, Invalid response | Something blocks or rewrites the .well-known path |
Step 4 |
| CAA | A CAA record does not allow your CA, or the CAA lookup failed | Step 5 |
| Timeout, connection refused, firewall | Port 80 blocked or the validator is being dropped | Step 6 |
| too many certificates, too many failed authorizations, rateLimited | A Let’s Encrypt rate limit | Step 7 |
| SERVFAIL, DNSSEC | Broken DNSSEC or a faulty DNS provider | Step 5 |
The most common cause by far: the domain, or www, points somewhere else. That happens after a migration, when DNS is still at the old host, or when www is a CNAME to an old platform.
dig +short A example.com
dig +short A www.example.com
dig +short AAAA example.com
dig +short AAAA www.example.comWhat they do: print the IPv4 (A) and IPv6 (AAAA) addresses published for each name. Windows users can run nslookup example.com and nslookup www.example.com, which show both kinds. Good output: the A records match the server IP shown in your hosting panel, and the AAAA records are either empty or the server’s real IPv6 address. Bad output: an old host’s IP, a Cloudflare address (Step 3), nothing at all for www, or an AAAA record left over from a previous host. A stale AAAA record is easy to miss: validation can be sent to the old IPv6 address and fail even though IPv4 is correct. Delete or correct it.
Fix the records at whoever hosts your DNS (our who hosts tool and domain lookup show the nameservers), wait for the old TTL to pass, then run AutoSSL again. Our guides on DNS changes not showing up and subdomains not working cover the DNS side in depth. If you do not use a name, such as a mail subdomain whose email is hosted elsewhere, its failure is only a warning and can be ignored, or excluded from AutoSSL if your panel offers that.
When a DNS record is proxied (orange cloud), the domain resolves to Cloudflare, not to your server. Visitors then see Cloudflare’s own edge certificate, and the certificate on your server is only used on the hidden connection between Cloudflare and the server. Two consequences:
/.well-known/, as described in our Cloudflare block errors guide.Pick one of these fixes:
www records to DNS only, run AutoSSL, wait for the certificate, then switch the proxy back on. This works, but it has to be repeated if renewal later fails, so option 1 or 3 is better long term.If you are moving DNS to Cloudflare for the first time, our guide on moving DNS to Cloudflare explains the SSL mode choice, and the Cloudflare settings cheat sheet lists every mode.
Test the exact path the CA uses. Create a test file through SFTP or your file manager: inside your site folder (the document root, often public_html), create the folders .well-known/acme-challenge/ if they do not exist, and put a file named test.txt in it containing the word ok. Then, on your own computer:
curl -sS -i -L http://example.com/.well-known/acme-challenge/test.txt
curl -sS -i -L http://www.example.com/.well-known/acme-challenge/test.txtWhat they do: request the file over plain HTTP, as the CA does. -i prints the response headers, -L follows redirects, and -sS hides progress but shows errors. Good output: the last response is HTTP/1.1 200 OK (or HTTP/2 200) followed by ok. Redirects to HTTPS on the same name before that are fine. Bad output, and what it means:
| Result | Cause and fix |
|---|---|
| 403 Forbidden | A rule blocks dot folders or the path. On Nginx, a rule like location ~ /\. { deny all; } blocks .well-known too; add location ^~ /.well-known/acme-challenge/ { allow all; } above it. On Apache, look in .htaccess for rules denying files or folders that start with a dot. Security plugins and ModSecurity rules can also block it: check their logs. See our 403 guide. |
| 404 Not Found, or your WordPress 404 page | The request reached a different folder or server than the one AutoSSL writes to. Check the document root for the domain in your panel, and whether DNS points here (Step 2). An addon domain or subdomain whose document root was changed is a common cause. |
| 401, or a login form | Password protection (HTTP authentication on a staging site, a “coming soon” or maintenance plugin, or a members-only plugin) is blocking all visitors, including the CA. Exclude /.well-known/ from it, or switch it off while the certificate issues. |
A redirect to another domain, a /login page or the home page |
A redirect rule catches everything. Add an exception for /.well-known/ before the redirect. See finding unknown redirects. |
| Timeout or connection refused | Port 80 is not answering (Step 6). |
Delete the test file and folders you created when you are done, unless the folder already existed.
A CAA record is a DNS record that lists which CAs may issue certificates for your domain. Most domains have none, and then any CA may issue. If one exists and does not list the CA your panel uses, issuance is refused.
dig +short CAA example.com
dig +short CAA www.example.comWhat they do: print any CAA records. Windows: nslookup -type=CAA example.com. Good output: nothing, or a record that names your CA, such as 0 issue "letsencrypt.org". Bad output: records that name only other CAs. Add a record for yours: letsencrypt.org is Let’s Encrypt’s documented identifier. For cPanel’s default AutoSSL provider, powered by Sectigo, the identifier Sectigo documents is sectigo.com (Sectigo also still accepts older Comodo-era values such as comodoca.com). Ask your host which provider your server uses before you add the record. Let’s Encrypt checks the CAA record closest to the name being issued, so a CAA record on a subdomain overrides the one on the main domain, and CAA checks follow CNAMEs.
If the error mentions SERVFAIL, Let’s Encrypt’s documentation says this most often means DNSSEC validation failed. That usually happens after a move to new nameservers while the old DS record is still published at the registrar. Check the domain with a DNSSEC debugger such as dnsviz.net, and either fix the DNSSEC setup or remove the DS record at the registrar. A DNS provider that answers CAA queries with an error rather than an empty answer also blocks issuance; that is a fault for the DNS provider to fix.
HTTP validation needs port 80 open to the whole internet, even if your site only uses HTTPS. Check with our open port check, which tests ports 80 and 443 from outside. If 80 is closed:
/.well-known/acme-challenge/ from geographic blocking, or use DNS validation.Let’s Encrypt limits how often you can try. The limits most often hit while troubleshooting, as documented by Let’s Encrypt at the time of writing:
| Limit | Documented value | What triggers it |
|---|---|---|
| Authorization failures per identifier per account | 5 per hour, refilling one every 12 minutes | Retrying a failing validation over and over |
| New certificates per exact set of identifiers | 5 every 7 days, refilling one every 34 hours | Reissuing the same certificate repeatedly, reinstalling a client, deleting its configuration |
| New certificates per registered domain | 50 every 7 days | Many subdomains each getting their own certificate |
Rate limit errors follow a fixed format, for example too many certificates (5) already issued for this exact set of identifiers in the last 168h0m0s, retry after ..., and give the time when you can try again. Let’s Encrypt says it cannot reset a limit early and revoking certificates does not reset it. Wait until the time shown, fix the cause, then try once. Renewals coordinated through ACME Renewal Info (ARI) are exempt from all limits, which is one reason renewals rarely hit them. Your panel’s own provider (such as cPanel’s Sectigo-powered AutoSSL) has different limits; ask your host if you suspect one. Developers testing their own setup should point their client at Let’s Encrypt’s staging environment, which has much higher limits.
certbot renew --dry-run first: it tests renewal against the staging environment without saving anything, and Congratulations, all simulated renewals succeeded is the good result. Then run the real renewal.example.com and www.example.com are listed. A missing www is the cause of NET::ERR_CERT_COMMON_NAME_INVALID.Send your host:
dig commands for A, AAAA and CAA records.Related guides: expired certificates, self-signed certificates and incomplete chains, mixed content, redirect loops after switching to HTTPS and the OpenSSL and TLS cheat sheet for inspecting certificates from the command line.
Did this fix it?
Still stuck? Start again from what you can see in the Emergency Room.
Still stuck?
Print a free one-page checklist to keep, or open the Emergency Room if the symptom does not match.
Get the free checklistsKeep reading
Search the field manual
Or jump straight to a symptom
Press / to search from any page, Esc to close