How to Fix Let’s Encrypt Auto-Renewal Failures

Start with certbot renew --dry-run. Read the first authorization or hook error, then repair the renewal profile and challenge path it identifies. For HTTP-01, that usually means making the token reachable at http://YOUR_DOMAIN/.well-known/acme-challenge/TOKEN on public port 80. For DNS-01, it means publishing the exact TXT value at _acme-challenge.YOUR_DOMAIN and waiting for authoritative DNS to serve it.

Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.

Do not repeatedly request production certificates while diagnosing the problem. Inspect the certificate lineage under /etc/letsencrypt/renewal/ (the location varies by installation), test the corrected configuration with staging or a dry run, and verify that your web server or proxy serves the new chain after issuance.

#	Preview	Product	Price
1		Network Security: Private Communication in a Public World (Prentice Hall Series in Computer...	$63.20	Buy on Amazon
2		CompTIA Security+ Certification Kit: Exam SY0-701 (Sybex Study Guide)	$41.83	Buy on Amazon
3		Cybersecurity For Dummies (For Dummies: Learning Made Easy)	$13.53	Buy on Amazon
4		Network Security, Firewalls, and VPNs	$66.62	Buy on Amazon
5		The Practice of Network Security Monitoring: Understanding Incident Detection and Response	$48.65	Buy on Amazon

As an Amazon Associate I earn from qualifying purchases.

What a failed renewal actually tells you

A failed renewal is not one single fault. Certbot first loads a renewal profile, obtains authorization for every identifier, stores or installs the resulting certificate, and may run reload or deployment hooks. Failure at any stage can produce a message that looks similar from a scheduler’s point of view. The first actionable error is usually the first authorization failure, DNS response mismatch, hook exit code, or file-access error in the log.

Let’s Encrypt describes renewal failure as a recoverable operational error rather than a permanently fatal condition. That does not mean an unattended job can be ignored: a certificate can still expire while the service appears healthy. Treat the error as an incident, preserve its details, fix the failing stage, and monitor the next cycle.

#1 Best Overall

Network Security: Private Communication in a Public World (Prentice Hall Series in Computer Networking and Distributed Systems)

$63.20

Buy on Amazon

Capture the complete error before changing anything

Run:

certbot renew --dry-run

Save the output and identify:

• The certificate lineage and domains being renewed.
• The challenge type, such as HTTP-01 or DNS-01.
• The HTTP status, redirect destination, or DNS response reported by the validation attempt.
• Any authenticator, installer, deploy, pre, or post-hook exit code.
• The exact time of the attempt, so you can distinguish a transient propagation problem from a persistent configuration error.

Do not discard a warning that appears before the final summary. A later “renewal failed” line is only the result; the earlier authorization or hook message usually identifies the repair.

Inspect the renewal profile and certificate lineage

Certbot stores renewal profiles in /etc/letsencrypt/renewal/ on many installations, although package layouts and container images can use another path. Each profile records the domains, authenticator, installer, credential-file references, and hooks used for that lineage. A certificate can be valid at the public endpoint while its profile points to an old server block, a deleted webroot, or a credential file that no longer exists.

Check the profile before changing the live service

1. List the renewal profiles and identify the file corresponding to the hostname shown in the dry-run error.
2. Confirm that every intended domain is present and that an obsolete hostname has not been retained.
3. Check whether the authenticator is the one you expect: a webroot or web-server plugin for HTTP-01, or a DNS plugin and credential file for DNS-01.
4. Verify that referenced credential files still exist, are readable by the account running Certbot, and contain current values.
5. Review installer and deploy hooks. A successful issuance can still be unusable if the hook reloads the wrong proxy or exits nonzero.
6. Confirm the lineage is enabled and is the certificate actually configured on the public listener, rather than an unused older lineage.

Avoid deleting the client state to “start over.” Removing profiles, account data, or private keys can make recovery harder and can cause a replacement request to consume issuance limits without fixing the underlying routing or DNS problem.

Fix HTTP-01 validation failures

HTTP-01 requires Let’s Encrypt to retrieve a token from http://YOUR_DOMAIN/.well-known/acme-challenge/TOKEN. Let’s Encrypt states that “The HTTP-01 challenge can only be done on port 80.” The validation service follows redirects only to HTTP or HTTPS on ports 80 or 443. A redirect to another port, an unreachable port 80 listener, or a path that never reaches the token therefore fails even when the normal website works over HTTPS.

Rank #2

Sale

CompTIA Security+ Certification Kit: Exam SY0-701 (Sybex Study Guide)

$41.83

Buy on Amazon

Test the public path, not only localhost

From a network outside the server, request a harmless test object under the same directory used by Certbot, such as http://your-domain.example/.well-known/acme-challenge/test. The response should come from the intended public edge and should not be replaced by a login page, application error, or unrelated virtual host. Testing only with curl localhost can hide a firewall, NAT, load-balancer, or CDN problem between the internet and the origin.

Check the common HTTP-01 breakpoints

• Port 80 filtering: Open public TCP port 80 at the cloud firewall, host firewall, security group, and load balancer. If a provider blocks it permanently, HTTP-01 is the wrong method; use DNS-01.
• Wrong DNS destination: Confirm that the public A and AAAA records resolve to the edge that owns the challenge path. An old IPv6 record can send validation to a different server even when IPv4 is correct.
• Virtual-host selection: Ensure the requested hostname has a port-80 server block. A default site that returns a different document or redirects to another application will not expose the token generated for the intended lineage.
• Webroot mismatch: The directory configured in the renewal profile must be the directory served for /.well-known/acme-challenge/. A deployment that copies files to one webroot while the proxy serves another produces a consistent 404.
• Authentication and access rules: Remove login requirements, IP allowlists, rewrite rules, and application middleware from the challenge location. The validation request must be able to read the token without a session or custom header.
• CDN or cache interception: Bypass rules that cache, rewrite, compress, or protect the challenge directory. A stale 404 or a CDN-generated security page is not the token Certbot created.
• Redirect behavior: Redirects to HTTPS on port 443 are allowed, but a redirect chain ending on another port or an unsupported scheme is not. Test the complete chain from an external network.

Repair the webroot or web-server plugin

Use one consistent method for the lineage. With a webroot authenticator, ensure the account running Certbot can create files beneath the configured directory and that the web server can read them. With a web-server plugin, verify that the plugin selects the intended virtual host and that configuration tests and reloads succeed. After correcting the mapping, repeat the dry run rather than immediately requesting a production certificate.

Fix DNS-01 validation failures

DNS-01 proves control by asking for a TXT record at _acme-challenge.YOUR_DOMAIN. The record must contain the exact value requested for that authorization. The web server does not need to accept traffic on port 80, which makes DNS-01 suitable for private services, networks that cannot expose port 80, and wildcard certificates.

Verify the exact name and value

1. Read the hostname and TXT value printed by Certbot; do not substitute the apex name for the _acme-challenge label.
2. Query authoritative DNS from outside the DNS provider’s management interface and confirm that the requested value is visible.
3. Check both the record name and the zone being edited. A token for www.example belongs under the corresponding challenge name, while a token for the apex and a wildcard may be presented together at the same label.
4. Allow for provider and recursive-resolver propagation before retrying. A management console showing the record does not prove that authoritative servers are returning it.
5. Remove stale TXT values when accumulated records make DNS responses too large or when old automation leaves conflicting data. Keep every currently requested value until its authorization has completed.

Secure and automate DNS updates

Unattended renewal needs a supported Certbot DNS plugin or a delegated validation zone. A narrowly scoped API token should be able to edit only the required DNS zone and should be stored in a protected credential file. Check that the token has not expired, been rotated, or lost permission to create and remove TXT records.

Rank #3

Sale

Cybersecurity For Dummies (For Dummies: Learning Made Easy)

$13.53

Buy on Amazon

Delegating _acme-challenge with a CNAME or an NS record can isolate validation from the main zone. The delegated zone still has to publish the TXT value correctly, and the renewal profile must target the provider that controls that delegated name. Delegation is useful when the web host and DNS administration are separate, but it adds another record and ownership boundary to document.

Wildcards and blocked port 80

HTTP-01 cannot issue wildcard certificates. DNS-01 is required when a certificate includes a wildcard identifier, and it is the practical choice when policy or network design prevents any public port-80 route. Switching methods requires updating the renewal profile and proving that the new plugin or hook can create the TXT record without interactive input.

Replace unattended manual renewals

Certificates originally obtained with --manual do not renew unattended unless an authentication hook script supplies the required HTTP or DNS changes. Certbot documentation states: “Certificates created using --manual do not support automatic renewal unless combined with an authentication hook script.” If a scheduled job pauses for a person to paste a token, it is not an automated renewal system.

Choose a maintainable replacement

• Use a webroot or web-server plugin when the service can expose the HTTP-01 path on port 80.
• Use a supported DNS plugin when port 80 is unavailable, a wildcard is needed, or DNS automation is easier to secure than web exposure.
• Keep a manual authentication hook only when an unavoidable external process controls the challenge, and test that the hook can run non-interactively with the scheduler’s environment.

When migrating, create the new profile deliberately and confirm which lineage the service uses. Do not assume that obtaining a second certificate automatically replaces the first one in a proxy or web-server configuration.

Rank #4

Sale

Network Security, Firewalls, and VPNs

$66.62

Buy on Amazon

Check hooks, schedulers, and concurrent jobs

Renewal often succeeds through authorization and then fails while deploying. Pre, deploy, and post hooks must return success, use absolute paths where appropriate, and reload the correct service. A hook that works in an interactive shell may fail under a timer because environment variables, a home directory, a secret mount, or a shell profile is missing.

Hook checks

• Run the hook command as the same user and execution context used by the scheduler.
• Confirm that a configuration test runs before reload and that the reload targets the active web server or proxy.
• Check that rotated credentials, socket paths, and secret files are available at renewal time.
• Make hooks idempotent: a repeated dry run should not corrupt configuration or append duplicate directives.
• Capture hook stdout, stderr, and exit status in a log that the monitoring system can read.

Prevent overlapping renewals

Ensure that only one scheduled renewal process runs at a time. Overlapping jobs can both edit challenge files, replace temporary DNS records, or reload a service while the other process is still deploying. Use the scheduler’s locking facility or an equivalent single-instance mechanism, and keep a record of which timer, cron entry, or container performs the renewal.

Rule out time, permissions, and storage problems

ACME authorization and certificate validation depend on correct system time. Confirm that the host clock and time synchronization service agree with reliable time sources. A significant clock error can make a newly issued certificate appear not yet valid or make an account request fail even when the challenge path is correct.

Check ownership and permissions on the Certbot configuration, renewal profiles, credential files, and private keys. Files should be readable only by the users that need them, while the scheduled Certbot process must be able to read its profile and write temporary challenge data. Tightening permissions without checking the scheduler’s user can turn a previously working renewal into a file-access failure.

Best Value

Sale

The Practice of Network Security Monitoring: Understanding Incident Detection and Response

• Used Book in Good Condition

$48.65

Buy on Amazon

Verify free disk space and available inodes on the filesystems used for configuration, temporary files, logs, and webroot content. A full filesystem can prevent token creation, certificate storage, or atomic configuration updates. Clean up logs and temporary files according to your retention policy, but preserve the failure evidence before removing it.

Understand rate limits before retrying

Repeated production attempts can turn a configuration mistake into a rate-limit incident. Published Let’s Encrypt figures for 2026 include:

The exact response may include a Retry-After value or another reset time. Follow that instruction rather than estimating. Staging is intended for testing issuance logic without consuming production certificate limits; it does not prove that a production account, policy, or credential has the same state, so perform a final production attempt only after the underlying cause is corrected.

Use a safe end-to-end recovery runbook

1. Capture the failure: Run certbot renew --dry-run and preserve the first authorization, DNS, HTTP, or hook error.
2. Identify the lineage: Open the matching renewal profile and verify domains, authenticator, installer, credential paths, and hooks.
3. Test the selected challenge externally: For HTTP-01, request the challenge path through public DNS and port 80. For DNS-01, query authoritative DNS for the exact TXT value.
4. Repair routing or DNS: Correct firewall, NAT, load-balancer, virtual-host, authentication, webroot, API-token, zone, delegation, propagation, or stale-record problems identified by the test.
5. Validate the execution context: Check scheduler locking, hook exit codes, system time, file permissions, disk space, and inodes.
6. Test without production issuance: Run the dry run again and use the staging environment for changes that require a real ACME transaction.
7. Renew once the test passes: Allow the normal scheduled job or run the production renewal deliberately; do not launch parallel retries.
8. Verify deployment: Inspect the live endpoint and certificate chain, not just the files written under the Certbot directory.
9. Record the fix: Document the lineage, challenge method, DNS zone or webroot, proxy path, hooks, and monitoring thresholds so the next incident starts with known facts.

Why a successful issuance can still leave an old certificate online

Certbot can obtain and save a new certificate while the public service continues serving the previous one. This happens when the installer was not used, a deploy hook failed, the wrong virtual host was reloaded, or a load balancer and origin use different certificate stores. After renewal, inspect the certificate presented by every public endpoint, including IPv4 and IPv6 paths and any separate proxy or load-balancer listener.

Check the expiration date, subject names, and certificate chain shown by the live service. Then confirm that the reload completed without a configuration error and that all active instances received the new files. A restart is not automatically safer than a reload: use the service’s supported reload operation and verify its result in the hook log.

HTTP-01 or DNS-01: which method should you use?

Choose the method that matches the service’s actual control plane. Switching to DNS-01 does not help if the account cannot edit the authoritative zone, and keeping HTTP-01 does not help when port 80 is intentionally unreachable. The reliable method is the one that can be automated, externally verified, and documented for the hostname’s real DNS and proxy layout.

Build prevention into the next renewal cycle

• Keep Certbot and its authenticator plugins updated through your normal package-management process.
• Use a supported automated authenticator instead of an unattended job that expects manual token entry.
• Store DNS credentials with least privilege and rotate them in a controlled way, updating the renewal profile when they change.
• Keep port-80 routing intentional for every hostname that uses HTTP-01, including firewall, CDN, IPv6, and load-balancer rules.
• Run staging or dry-run tests after changes to DNS, proxies, webroots, plugins, credentials, or hooks.
• Serialize scheduled jobs so only one renewal process can modify a lineage at a time.
• Reload services only after successful issuance and alert when a hook fails.
• Monitor certificate expiry independently of Certbot’s local logs. Alert before the remaining lifetime becomes a service risk.
• Document each hostname’s challenge method, renewal lineage, DNS zone, delegated validation records, proxy route, and deployment hook.
• Preserve enough historical logs to correlate a failed dry run with DNS, firewall, credential, or deployment changes.

Let’s Encrypt’s current certificates have a 90-day lifetime and are generally renewed about 30 days before expiration. That schedule gives time to investigate a failed attempt, but only if monitoring notices the failure and the renewal job continues to run. A passing issuance test is useful evidence; the operational goal is a repeatable, externally verified renewal and deployment path.

Quick Recap

Bestseller No. 1

Network Security: Private Communication in a Public World (Prentice Hall Series in Computer Networking and Distributed Systems)

$63.20

SaleBestseller No. 2

CompTIA Security+ Certification Kit: Exam SY0-701 (Sybex Study Guide)

$41.83

SaleBestseller No. 3

Cybersecurity For Dummies (For Dummies: Learning Made Easy)

$13.53

SaleBestseller No. 4

Network Security, Firewalls, and VPNs

$66.62

SaleBestseller No. 5

The Practice of Network Security Monitoring: Understanding Incident Detection and Response

Used Book in Good Condition

$48.65

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.