Let's Encrypt Certificate Not Issued: Errors and Fixes

A free SSL certificate from Let's Encrypt is usually issued in one click — in the hosting panel or with the certbot command. But sometimes you get an error instead of a certificate, and the website keeps opening with a "Not secure" warning.

If the error message names a specific cause, you'll find a specific fix below. If the panel only says "Verification failed" without details, or the error comes and goes, the checklist at the end of the article will help.

How Let's Encrypt verifies a domain

Before issuing a certificate, Let's Encrypt checks that you really control the domain. Most often this is done with an HTTP check: the server creates a temporary file on the website at /.well-known/acme-challenge/, and Let's Encrypt tries to open it over HTTP on port 80.

If the file opens and its contents match, the certificate is issued. If not, you get an error. So almost every problem comes down to one thing: for some reason Let's Encrypt can't get this file.

💡 Important: Let's Encrypt checks every domain in the certificate separately. If the certificate is issued for example.com and www.example.com, both addresses must point to your server.

DNS problem: NXDOMAIN

DNS problem: NXDOMAIN looking up A for example.com - check that a DNS record exists for this domain

Cause: the domain has no A (or AAAA) DNS record, so Let's Encrypt doesn't know which server to go to. This happens when the domain has just been registered, the records haven't been created yet or there's a typo in the subdomain name.

Fix: create an A record with your server's IP address in your registrar's or DNS hosting panel and wait for it to update. You can check the record with the dig command or with dns.google:

dig +short example.com A

Invalid response: 404 or 403

Invalid response from http://example.com/.well-known/acme-challenge/...: 404

Cause: Let's Encrypt reached the server but couldn't find the verification file. Most often the culprit is .htaccess rules that redirect all requests to index.php or another folder, a wrong website root folder or blocked access to hidden folders that start with a dot. A 403 code means the file exists but access to it is denied.

Fix: exclude the verification folder from redirects. In Apache, add a rule at the top of .htaccess, right after RewriteEngine On:

RewriteRule ^\.well-known/acme-challenge/ - [L]

In Nginx, add a separate location block to the website configuration:

location ^~ /.well-known/acme-challenge/ {
    root /var/www/example.com;
}

If the error shows a different IP address or someone else's page in the response, the domain doesn't point to your server. In that case, see the checklist section.

Timeout during connect

Timeout during connect (likely firewall problem)

Cause: Let's Encrypt couldn't connect to the server in time. Most often port 80 is closed by the server's or hosting firewall. Sometimes the hosting blocks requests from other countries, while Let's Encrypt checks the domain from several servers in different parts of the world at once.

Fix: open port 80 in the server firewall and in the hosting panel, if it has its own. For ufw in Ubuntu it's one command:

sudo ufw allow 80/tcp

If the server has country blocking enabled, turn it off at least for port 80.

⚠️ Important: don't close port 80 even after the certificate is issued. It's needed for automatic renewal every few months, and for visitors it's enough to set up a redirect from it to HTTPS.

Connection refused

Connection refused

Cause: the server is reachable, but nothing is running on port 80: the web server is stopped or set up for HTTPS only.

Fix: check that the web server is running and listening on port 80. If the website is set up on port 443 only, add an HTTP version for it with a redirect to HTTPS, but keep the /.well-known/acme-challenge/ folder accessible.

CAA record prevents issuance

CAA record for example.com prevents issuance

Cause: the domain has a CAA DNS record that allows only certain certificate authorities to issue certificates, and Let's Encrypt isn't on that list.

Fix: delete the CAA record or add Let's Encrypt to it:

example.com.  CAA  0 issue "letsencrypt.org"

Too many failed authorizations

too many failed authorizations recently

Cause: Let's Encrypt has limits. For example, no more than 5 failed checks of the same domain per hour. If you press the issue button again and again, the limit runs out quickly, and even after you fix the real cause, the certificate won't be issued.

Fix: wait an hour and try again — but only after you've found and fixed the cause. A similar error, too many certificates already issued, means that 5 certificates have already been issued for the same set of domains in the past week. In that case you'll have to wait longer — up to a day and a half. The exact time when you can try again is usually stated in the error message itself.

If the error has no details or comes and goes

Control panels often show a general error like "Verification failed for the following domain(s)" without any explanation. Sometimes the certificate is issued one time and fails the next. Then check, in order:

DNS has already updated. If you recently changed the domain's IP address, old data may be cached for a few more hours. Check the address with dns.google and try again once it shows the new IP.
www and other subdomains point to the server. Panels often add www.example.com to the certificate automatically. If www points to the registrar's parking page, the check fails. Point www to your server or remove it from the certificate.
There's no stray AAAA record. If the domain has an IPv6 address, Let's Encrypt checks it first and falls back to IPv4 only on a timeout. When the AAAA record is left over from an old server or a different website answers over IPv6, the check fails. Delete the stray record or set up the website over IPv6 too.
There's no CAA record blocking Let's Encrypt. It's easy to miss if someone else set up the DNS.
The verification folder is accessible. Create a test file and open it in the browser over HTTP — you should see the text test, not a 404 error or the website's home page.
Port 80 is open to the whole world. Let's Encrypt checks the domain from servers in different countries, so the website must be reachable not only from yours.
The Cloudflare proxy isn't in the way. If the domain is on Cloudflare with proxying enabled, switch the record to "DNS only" while issuing the certificate.
You haven't hit the attempt limit. If you've already tried to issue the certificate several times in a row, wait an hour.

To check the verification folder, create a file in the website's root folder and request it:

mkdir -p .well-known/acme-challenge
echo test > .well-known/acme-challenge/test.txt
curl http://example.com/.well-known/acme-challenge/test.txt

Don't forget to delete the test file after the check.

The detailed cause can almost always be found in the logs. For certbot it's /var/log/letsencrypt/letsencrypt.log, and control panels have their own log section or a separate folder in /var/log. The log shows the specific domain that failed the check and what Let's Encrypt got in response.

Summary

Almost every Let's Encrypt error means one thing: the verification file couldn't be fetched over HTTP. If the error has details, look for the fix by its text. If the error is general or comes and goes, check DNS, www, AAAA and CAA, access to the /.well-known/acme-challenge/ folder and port 80, and wait an hour before trying again so you don't hit the limit.

🔒 If the certificate still isn't issued, message me — I'll figure it out and set up HTTPS.

Published October 20, 2026

← All articles