Free tool

Why won't Let's Encrypt give me a certificate?

Certbot timing out, renewals suddenly failing, a CAA error you've never seen before? Enter the domain and how you validate, and we run the checks Let's Encrypt's own validation implies - then explain what's in the way.

How this works
  • We look up the domain's public DNS records (A, AAAA, CAA, TXT), including the _acme-challenge name your ACME client uses.
  • For HTTP-01 and TLS-ALPN-01 we briefly connect to the domain's server on port 80 or 443 - the same way Let's Encrypt would - and request a harmless test path.
  • We count recent certificates in crt.sh, the public Certificate Transparency database, to estimate rate-limit usage.
  • We don't store the domain or the result, and nothing is shared unless you copy the link.

Not sure? Pick HTTP-01 - it's what most clients use by default.

You're viewing a shared result.

Diagnosis

Should work - with warnings

Issuance for cactus.net using http-01 can probably succeed, but the warnings below are the kind of thing that comes back to bite at renewal time.

Issuance outlook

Recommended action

Fix what you can from the warnings, then try issuing against the staging environment first - its rate limits are generous and failures there cost you nothing.

What we checked

Findings

3 findings

Couldn't test IPv6 from here

Warning

Our server has no IPv6 route, so we couldn't verify 2606:4700:3037::ac43:d2d8, 2606:4700:3033::6815:1779. Let's Encrypt WILL try these addresses first - test them from an IPv6-capable network (a phone on mobile data works) before trusting them.

Behind Cloudflare

Warning

Requests are answered by Cloudflare's edge, which normally passes /.well-known/acme-challenge/ through to your origin. Keep in mind the HTTPS certificate visitors see is Cloudflare's; the one you're issuing here protects the Cloudflare-to-origin leg. If validation fails, look at WAF rules and Under Attack mode.

No CAA restrictions

Info

No CAA record exists between your name and the registered domain, so any certificate authority - including Let's Encrypt - may issue.

Server reachability

Port 80, address by address

  • 2606:4700:3037::ac43:d2d8 Couldn't test from here
  • 2606:4700:3033::6815:1779 Couldn't test from here
  • 172.67.210.216 Reachable

    Server header: cloudflare

    http://cactus.net/.well-known/acme-challenge/cactus-security-probe-8827bebfdf71 307 → https://cactus.net/.well-known/acme-challenge/cactus-security-probe-8827bebfdf71 404
  • 104.21.23.121 Reachable

    Server header: cloudflare

    http://cactus.net/.well-known/acme-challenge/cactus-security-probe-8827bebfdf71 307 → https://cactus.net/.well-known/acme-challenge/cactus-security-probe-8827bebfdf71 404

Certificate authority permissions

CAA records

No CAA records anywhere on the path, so any certificate authority may issue. That's the default for most domains, and it's fine.

Rate limits

Recent Let's Encrypt certificates

Issued for cactus.net, last 7 days
0 of 50 allowed
Identical certificates (same exact names)
0 of 5 allowed

Counted from public Certificate Transparency logs, Let's Encrypt only, with precertificate duplicates removed. Renewals made through ARI are exempt from these limits but still appear in the logs, so real usage may be lower than the count. Capacity refills continuously - roughly one certificate every 3.4 hours for the per-domain limit and one every 34 hours for duplicates. There is no weekly reset moment.

Important limitation

We test from one location in Canada. Let's Encrypt validates from at least four vantage points around the world and needs most of them to agree, so a firewall that geo-blocks or rate-limits can pass our check and still fail theirs. We also can't see your ACME account: per-account limits and paused accounts only show up in the error your client prints.

Let's Encrypt is a trademark of the Internet Security Research Group. Cactus is not affiliated with or endorsed by ISRG.

Once issuance works: grade cactus.net's HTTPS with the SSL/TLS checker