SSL certificate cannot be issued or installed: Let's Encrypt, DNS and panel fixes

What cannot be issued actually means

Before a certificate authority signs a certificate, it must check that you control every name on it. Let's Encrypt and other automatic authorities do this with the ACME protocol, using one of two common challenges:

• HTTP-01. Your server places a small file at http://example.com/.well-known/acme-challenge/<token> and the authority fetches it over port 80. Redirects to https are followed, so a normal HTTPS redirect is fine.
• DNS-01. You publish a TXT record at _acme-challenge.example.com. This is the only option for wildcard certificates, and it works when port 80 is closed.

The authority fetches the file or record from several places on the internet, not from your server's point of view. So if DNS is still pointing at an old host, a firewall blocks port 80 from outside, or a security rule returns a 403 for the folder, the check fails and nothing is issued. Hosting panels such as Plesk and cPanel run the same process behind a button, and when they show SSL as not available for a domain it is usually because the name does not yet resolve to that server.

A certificate that cannot be installed is different: it has been issued, but the server or panel rejects the files. That is covered further down.

Reading the error message

The error text tells you which check failed. These are the messages you are most likely to see from Let's Encrypt, Certbot or a panel:

In Plesk the message appears under the domain's SSL/TLS Certificates page after a failed request; in cPanel, open SSL/TLS Status and view the AutoSSL log for the domain. Both quote the authority's response, so look for the phrases above inside the longer text.

How to test the challenge yourself

Start with DNS. Every name on the certificate must resolve to the server that is requesting it, for both IPv4 and IPv6:

dig +short A example.com
dig +short AAAA example.com
dig +short A www.example.com
dig +short CAA example.com

Compare the A record with your server's public IP address. If there is an AAAA record, Let's Encrypt prefers IPv6, so a stale or wrong IPv6 address breaks validation even when IPv4 is right. Either fix the AAAA record so it reaches your server or remove it.

Then place a test file in the challenge folder and fetch it from outside your network:

sudo mkdir -p /var/www/example.com/.well-known/acme-challenge
echo ok | sudo tee /var/www/example.com/.well-known/acme-challenge/test
curl -i http://example.com/.well-known/acme-challenge/test

You want HTTP/1.1 200 and the body ok, or a redirect to https that ends in the same file. A 404 means the file is not where the web server looks, a 403 means a rule blocks it, and a page from a different site means DNS or the virtual host is wrong. Remove the test file afterwards.

Unblocking the well-known folder

Security rules that hide files starting with a dot are the most common reason for a 403. Add an exception before any deny rule.

nginx

location ^~ /.well-known/acme-challenge/ {
    root /var/www/example.com;
    default_type "text/plain";
    allow all;
}
location ~ /\. { deny all; }

The ^~ prefix makes nginx use this block instead of any regular expression rule that matches dot folders. Test with sudo nginx -t and reload.

Apache and .htaccess

Place this at the top of the site's .htaccess, before WordPress or security plugin rules, so the challenge path is never rewritten:

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

Also check WordPress security plugins, web application firewalls and country blocking. Let's Encrypt validates from several regions, so blocking whole countries can block the authority too. Behind Cloudflare, an HTTP-01 challenge normally passes through, but a strict firewall rule, bot challenge or Under Attack mode on that path will stop it; add a rule that skips them for /.well-known/acme-challenge/, or use the DNS challenge. Cloudflare's own redirect settings are covered in Cloudflare redirects.

CAA records and rate limits

A CAA record lists which authorities may issue for your domain. If one exists and does not include your authority, issuance is refused. With no CAA records at all, any authority may issue. To allow Let's Encrypt alongside a paid authority, add a record for each:

example.com.  3600  IN  CAA  0 issue "letsencrypt.org"
example.com.  3600  IN  CAA  0 issuewild "letsencrypt.org"
example.com.  3600  IN  CAA  0 issue "example-ca.com"

The authority checks CAA on the exact name and then on each parent, so a CAA record on a subdomain overrides the one on the main domain.

Let's Encrypt limits that small sites hit

Limits change from time to time, and the error message says which limit and when it resets. The cure is to stop, fix the cause, test with a dry run, and then request once.

When a certificate cannot be installed

If the authority issued the certificate but the panel or server rejects it, the files are usually the problem. Check that the certificate and the private key belong together by comparing their public keys:

openssl x509 -in cert.pem -noout -pubkey | openssl sha256
openssl pkey -in privkey.pem -pubout | openssl sha256

The two hashes must be identical. If they differ, the key is from a different request; find the key generated with the CSR, or create a new CSR and reissue. Other common install failures:

• Wrong format. Panels such as Plesk and cPanel expect PEM text that starts with -----BEGIN CERTIFICATE-----. Windows servers expect a PFX, as covered in IIS SSL bindings.
• Missing CA bundle. Paste the intermediate certificates into the CA certificate box, or the site will install but show as untrusted on some devices; see untrusted certificate fixes.
• Encrypted private key. A key beginning -----BEGIN ENCRYPTED PRIVATE KEY----- must be decrypted before most panels accept it.
• Domain not added. The panel only installs certificates for domains it hosts. Add the domain or subdomain first.

The fix, step by step

Edge cases worth knowing

• Just moved host. The new server cannot pass HTTP-01 until DNS points at it. Either switch DNS first and accept a short gap, or use the DNS challenge to issue in advance.
• www not resolving. Panels often add www automatically. If www has no DNS record, the whole request fails; add the record or untick www.
• Plesk webmail and mail names. Ticking the option to secure webmail adds webmail.example.com to the request, which also needs a DNS record.
• Wildcards. These always need DNS-01, so a panel offering a wildcard asks you to add a TXT record or connect its DNS. If Plesk manages your DNS, it can add the record for you.
• Issued but wrong name. If the certificate issues but browsers report the wrong name, see hostname mismatch fixes.

Keeping renewals working

Every cause above can also break a renewal months later, and Let's Encrypt certificates last 90 days or less, so renewal runs often. Run sudo certbot renew --dry-run after any change to DNS, firewall rules, security plugins or CDN settings. In Plesk and cPanel, check the renewal or AutoSSL log after such changes. When a renewal fails, the site keeps working until the old certificate expires, which gives you time to fix it if you notice. Run the security audit regularly to see the expiry date, and if the certificate installs but the site still says not secure, move on to a certificate that is installed but not working.