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

4 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.

Couldn't check rate limits

Info

crt.sh, the public certificate log we count from, didn't answer. Everything else on this page still stands; the rate-limit picture is simply unknown right now.

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
  • 104.21.23.121 Reachable

    Server header: cloudflare

    http://cactus.net/.well-known/acme-challenge/cactus-security-probe-86ab671be36c 307 → https://cactus.net/.well-known/acme-challenge/cactus-security-probe-86ab671be36c 404
  • 172.67.210.216 Reachable

    Server header: cloudflare

    http://cactus.net/.well-known/acme-challenge/cactus-security-probe-86ab671be36c 307 → https://cactus.net/.well-known/acme-challenge/cactus-security-probe-86ab671be36c 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

crt.sh (the public certificate log) didn't answer, so we couldn't count recent certificates. Rate limits are simply unchecked - everything else on this page still stands.
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.