Let’s Encrypt troubleshooter — why certbot fails

An online tool for diagnosing failed Let's Encrypt and ACME issuance. Certbot reports almost every problem as the same "authorization failed", which hides whether the cause is DNS, a closed port, a redirect that swallows the challenge path, or a CAA record forbidding the authority. This checks all three preconditions from outside your network, the way the certificate authority will, and names the specific cause.

How to use it

1
Enter the exact name

The name you pass to certbot with -d. If issuance fails for www.example.com, check that, not the bare domain — they can behave differently.

2
Pick the challenge type

HTTP-01 unless you need a wildcard or port 80 is closed, in which case DNS-01.

3
Read the errors first

Problems come before observations, most serious first. Anything marked as an error is a reason issuance will fail right now.

4
Fix, then re-check

Results are cached only briefly, so re-running after a change shows the new state rather than the old one.

Check the three things a certificate authority looks at before you run certbot again

Enter the exact name that goes into -d. If certbot fails on www.example.com, check www.example.com, not example.com.
The CA fetches a file over plain HTTP from your web server. This is what certbot uses by default.

What it checks

Whether the name resolves, and to what
A and AAAA records, with a warning for the IPv6-only case: Let's Encrypt prefers IPv6 and never falls back to IPv4, so a server that is not really listening on IPv6 fails validation while the site looks healthy to most visitors.
Whether the challenge path is reachable
Fetches /.well-known/acme-challenge/ over plain HTTP from outside. A 404 is the correct answer — it proves the request reached your web server. A refused connection, a 403 from a dotted-directory rule, or a catch-all redirect to the homepage are the real failures, and each is reported separately.
Whether CAA permits the authority
CAA records are checked at the name and at every parent, because a record on example.com governs www.example.com too. A CAA record that names a different CA is one of the most time-consuming causes, because the ACME error does not say so plainly.
Redirects examined, not just followed
A redirect from HTTP to HTTPS is fine and never breaks validation — that is worth knowing, because it is a common false suspicion. A redirect that lands somewhere other than the challenge path is not, and the tool distinguishes them.
The command to run next
A certbot invocation matching the challenge type you picked, with the flags that correspond to what was found.

Frequently asked questions

My site is HTTPS-only. Why does port 80 matter?

Because the HTTP-01 challenge always begins on port 80. The certificate authority connects there first, regardless of what your site does afterwards, and a firewall that drops port 80 makes the challenge impossible. Redirecting port 80 to HTTPS is fine — the CA follows the redirect and does not check the certificate while doing so. Closing the port is not. If you genuinely cannot open it, DNS-01 is the alternative.

The tool says 404 and calls it good. Is that right?

Yes. Before issuance there is no challenge file, so a 404 is what a correctly configured server must return. What matters is that the request reached your web server at all. During validation certbot places the real token at that path and the CA finds it. A connection failure or a 403 means the request never got there, and that is the actual problem.

What is a CAA record and why would I have one?

A DNS record naming which certificate authorities may issue for your domain. Certificate authorities are required to check it and refuse if they are not listed. People acquire them from a previous provider's setup wizard, from a hosting panel, or inherited on a parent domain — a record on example.com applies to www.example.com as well, which is why "I never created one" is so often wrong.

I hit a rate limit. Does this help?

Indirectly, and that is the point. Let's Encrypt limits how many certificates you can request per domain per week, and repeated failed attempts are what exhaust it. Checking the preconditions before rerunning certbot is what keeps you from burning the allowance on attempts that were always going to fail.

Does this issue a certificate?

No, and it never will. It performs no ACME operations, holds no key and talks to no certificate authority — it only observes your domain from outside. Issuance belongs on your server where the private key lives and where renewal can be automatic, which a web page cannot provide.

You May Also Like

📝 CSR generator ⛓️ Certificate chain fixer 🔄 Certificate format converter 🔗 Key and certificate matcher 🔐 SSL Checker 📜 SSL certificate decoder 🏷️ Self-signed certificate generator

How do you rate this tool?

Thank you for your rating!
Want to share more? Leave a comment!
Thank you! Your comment will appear after moderation.
Who is this tool for?
💻 Developers & IT Pros 🔒 Security & Privacy
Published Updated Author: