All tools

Guides Certificates

Certbot renew failed: what the error means

Updated 11 min read

Short answer

The Type and Detail lines under “The Certificate Authority reported these problems” name the cause. The type says what kind of check failed; the detail says where, and what Let’s Encrypt saw.

What to do: run sudo certbot renew --dry-run, find the type in the table, fix the cause, and repeat the dry run until it passes. Dry runs use the staging server, so retries don’t spend your real limits.

A renewal that fails stays quiet until the certificate expires. Expiry Watch checks the certificate your site serves every day and emails you when its renewal looks late. Free, with no account. Watch a domain

Read the output

Run the renewal as a test. --dry-run goes through the whole renewal, validation included, against Let’s Encrypt’s staging server, and saves nothing (Certbot User Guide):

sudo certbot renew --dry-run

We ran it with Certbot 5.8.0 on October 23, 2026, on a test certificate for boringutils.com kept in a scratch directory. Our site doesn’t serve files from that test’s webroot, so it failed the way a wrong webroot does. The scratch directory’s path is shortened to …; on a normal install those paths start with /etc/letsencrypt and /var/log/letsencrypt.

Saving debug log to …/logs/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing
…/config/renewal/boringutils.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Simulating renewal of an existing certificate for boringutils.com

Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
  Identifier: boringutils.com
  Type:   unauthorized
  Detail: 2606:4700:3035::ac43:89e2: Invalid response from http://boringutils.com/.well-known/acme-challenge/4bx9BdnlvObPNPizwWW8fu9mOzHuKMSD8kWbvl_bAwM: 404

Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed identifiers serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.

Failed to renew certificate boringutils.com with error: Some challenges have failed.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
All simulated renewals failed. The following certificates could not be renewed:
  …/config/live/boringutils.com/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 renew failure(s), 0 parse failure(s)
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile …/logs/letsencrypt.log or re-run Certbot with -v for more details.

What each part tells you:

  • Processing …/renewal/<name>.conf starts one block per certificate. With several certificates, each gets its own block, and only the failing ones show problems.
  • authenticator: webroot is the plugin that proved control of the domain. The fix depends on it: a webroot problem lives in your web server, a DNS plugin problem in your DNS.
  • Identifier is the name that failed. A certificate with several names can fail on just one of them.
  • Type is the kind of failure, one of the error types defined in RFC 8555, section 6.7 (urn:ietf:params:acme:error:unauthorized in the debug log).
  • Detail is what Let’s Encrypt saw. It starts with the IP address it connected to, here an IPv6 one, and then the URL it fetched and the HTTP status it got back.
  • Hint is Certbot’s generic advice for that plugin, not a diagnosis.
  • The summary lists every certificate that failed. A dry run calls them “simulated renewals”; a real run just says “renewals”, and exits with status 1 if any failed.

Match the type to the cause

This guide covers six error types: four ways validation fails, the rate limit, and a name the CA won’t sign.

Type The detail looks like Likely cause
unauthorized Invalid response from http://…/.well-known/acme-challenge/…: 404, No TXT record found at _acme-challenge.… The challenge file isn’t served where Certbot wrote it (wrong webroot, another site’s configuration, another server answering), or with a DNS plugin, the TXT record wasn’t in place.
connection Timeout during connect (likely firewall problem), Connection refused Port 80 is closed or filtered, or an IPv6 address points at a server that doesn’t answer.
dns DNS problem: NXDOMAIN looking up A for …, SERVFAIL The name has no record, or its DNS is broken, often DNSSEC.
caa CAA record for … prevents issuance A CAA record that doesn’t list letsencrypt.org.
rateLimited too many … retry after … Too many certificates or failed validations in a short time.
rejectedIdentifier Cannot issue for "…": … forbidden by policy The CA won’t issue for that name at all.

unauthorized: Let’s Encrypt didn’t find the proof

With the webroot plugin, Certbot writes a file to <webroot>/.well-known/acme-challenge/ and Let’s Encrypt fetches it over plain HTTP, on port 80, “potentially multiple times from multiple vantage points” (Challenge Types). A 404 means the server that answered didn’t serve the file Certbot wrote. Things to check:

  • The webroot changed. The site moved to another directory, or the configuration now serves it from elsewhere. Point Certbot at the new place: sudo certbot reconfigure --cert-name example.com --webroot-path /path/to/new/location (Certbot 2.3.0 and later, from its user guide).
  • Your server treats /.well-known/ specially, for example with a rewrite rule or a framework’s router. Certbot’s guide warns that “your server must be configured to serve files from hidden directories”.
  • Another server answers. If the IPv6 address in your AAAA record belongs to a different machine, Let’s Encrypt asks that one, because it “will always prefer the IPv6 addresses for the initial connection” (IPv6 Support). The same goes for every server behind a load balancer: “you have to make sure the file is available on all of them” (Challenge Types).
  • A redirect leads somewhere else. Let’s Encrypt follows up to 10 redirects, to http: or https: on ports 80 and 443 only. The final URL still has to serve the file.

To see what each address returns, request the challenge path over IPv4 and over IPv6 separately. This is our site, which answers 404 on both:

curl -4 -s -o /dev/null -w '%{http_code} %{remote_ip}\n' \
  http://boringutils.com/.well-known/acme-challenge/check
curl -6 -s -o /dev/null -w '%{http_code} %{remote_ip}\n' \
  http://boringutils.com/.well-known/acme-challenge/check
404 172.67.137.226
404 2606:4700:3035::ac43:89e2

On your own server, first put a test file named check in <webroot>/.well-known/acme-challenge/. Both lines should then show 200. A 404 on one family and 200 on the other points at the server behind that family’s address.

With a DNS plugin, the proof is a TXT record at _acme-challenge.<name>, and the detail reads No TXT record found at _acme-challenge.<name> when there was none, or Incorrect TXT record "…" found at _acme-challenge.<name> when it held another value, such as a stale one from an earlier attempt (Boulder’s DNS check). Either way, Let’s Encrypt looked before your DNS provider had published the new record everywhere, or the plugin couldn’t create it, for example because its API credentials stopped working. Let’s Encrypt suggests configuring the client to wait long enough for changes to spread, “often as much as an hour” with slow providers, and cleaning up old TXT records (Challenge Types).

connection: Let’s Encrypt couldn’t reach the server

The detail comes from the validation code in Boulder, Let’s Encrypt’s CA software. Each message means something specific:

  • Timeout during connect (likely firewall problem): nothing answered on port 80 at that address. Usually a firewall, a cloud security group or the ISP drops the traffic. HTTP validation “can only be done on port 80”, so the port has to be open to the internet, not just to you.
  • Connection refused: the address answered, but nothing listens on port 80: for example, a web server that listens on IPv4 only, behind an AAAA record that advertises IPv6.
  • Timeout after connect (your server may be slow or overloaded): the connection opened, but the answer never came.

If the address in the detail is an IPv6 one you don’t recognize, fix or remove the AAAA record. Let’s Encrypt falls back to IPv4 only after a connection timeout, and only on the first request, and there is “not a way to request Let’s Encrypt prefer IPv4” (IPv6 Support).

dns: the name didn’t resolve

We asked for a name that doesn’t exist, with certbot certonly --dry-run, to see the error. The problem lines read:

  Identifier: no-such-name.boringutils.com
  Type:   dns
  Detail: DNS problem: NXDOMAIN looking up A for no-such-name.boringutils.com - check that a DNS record exists for this domain; DNS problem: NXDOMAIN looking up AAAA for no-such-name.boringutils.com - check that a DNS record exists for this domain
  • NXDOMAIN: the name has no DNS records. Check for a deleted record, a typo, or a domain whose registration has lapsed.
  • SERVFAIL: the name servers failed to answer. In Let’s Encrypt’s words, “Most often this indicates a failure of DNSSEC validation”; test the domain with a DNSSEC debugger such as DNSViz (CAA documentation).
  • With a DNS plugin, a dns error means the lookup of the _acme-challenge TXT record itself failed, for the same reasons; a missing or wrong record is unauthorized.

caa: a DNS record forbids Let’s Encrypt

A CAA record names the certificate authorities allowed to issue for a domain. Let’s Encrypt checks it before every certificate, and if your records don’t include it, the detail reads CAA record for <name> prevents issuance (Boulder’s CAA check). Look at what your domain allows:

dig +short CAA google.com
0 issue "pki.goog"

That record lets only Google’s own CA issue for google.com, so Let’s Encrypt would refuse it. If CAA blocks your renewal, add a record such as example.org CAA 0 issue "letsencrypt.org" beside the others. A few rules from Let’s Encrypt’s CAA page:

  • The CA uses the CAA record closest to the name, walking up from www.community.example.org to example.org, and follows CNAMEs.
  • issuewild records control wildcard certificates separately.
  • A CAA lookup that fails, with a SERVFAIL or a timeout, also blocks issuance, even for a domain with no CAA records: “there’s no way to tell whether we are allowed to issue.” That one is for your DNS provider to fix.

The CAA record checker shows which record applies to a name and whether Let’s Encrypt may issue for it, and Fix “CAA record prevents issuance” goes through each cause.

rateLimited: too many attempts

Let’s Encrypt’s rate limit errors follow one format, ending in the time you can try again, for example “too many new registrations (10) from this IP address in the last 3h0m0s, retry after 1970-01-01 00:18:15 UTC.” (Rate Limits). Renewals skip some limits, and all of them when the client uses ACME Renewal Info (ARI). Two still apply to other renewals:

  • 5 certificates for the exact same set of names every 7 days. Common causes, in Let’s Encrypt’s words: “Reinstalling your client multiple times to troubleshoot an unknown error, or deleting your ACME client’s configuration data each time you deploy your application”.
  • 5 failed validations per name, per account, every hour.

There is no reset: “we don’t have a way to temporarily reset it.” Wait until the time in the error, and use --dry-run while you troubleshoot, because staging has “significantly higher limits” and keeps your production ones untouched.

rejectedIdentifier: the CA won’t issue for the name

Some names can’t get a public certificate from Let’s Encrypt at all. Asking for example.com gave us this:

An unexpected error occurred:
Error creating new order :: Cannot issue for "example.com": The ACME server refuses to issue a certificate for this domain name, because it is forbidden by policy

RFC 8555 defines the type as “The server will not issue certificates for the identifier.” Nothing on your server changes that. Check the name for typos, and remove names from the certificate that don’t belong on it.

After the fix

  1. Run sudo certbot renew --dry-run again. When it passes, the summary reads “Congratulations, all simulated renewals succeeded” (Certbot’s renewal.py).
  2. Leave the real renewal to the scheduled job: certbot renew only renews certificates that are due, so it is safe to run as often as the timer likes. To renew right away, run sudo certbot renew without --dry-run.
  3. Check that your site serves the new certificate. A successful renewal still needs a reload to take effect; site still shows the old SSL certificate covers that, and the deploy hook that does it for you.

The full debug log of each run is in /var/log/letsencrypt/letsencrypt.log. By default, Certbot keeps up to 1,000 log files there before deleting the oldest; some distributions, including Debian and Ubuntu, leave rotation to logrotate instead (Certbot User Guide).

Sources

All sources were checked on October 23, 2026. The Certbot, curl and dig output comes from our own runs on that date, against Let’s Encrypt’s staging server.

Keep reading