Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
Start with certbot renew --dry-run and fix the first authorization or hook error it reports. Then inspect the affected certificate lineage under /etc/letsencrypt/renewal/ (the path can differ by installation), confirm whether it uses HTTP-01 or DNS-01, repair that validation path, and run another dry run before requesting a production certificate.
What a renewal failure actually means
Certbot does not renew a certificate merely because its local files are present. It must complete a fresh ACME authorization for every identifier in the certificate, obtain a new certificate, and then run any configured deployment or reload hooks. A failure can therefore occur before issuance, during validation, or after issuance while the new files are being deployed.
Free tools Windows power users keep installed
One-click scans. No signup required.
Let’s Encrypt certificates currently last 90 days. Let’s Encrypt generally recommends renewing about 30 days before expiration and treating a failed renewal as a recoverable operational error that should trigger monitoring and repair, not an automatic fatal shutdown.
The first error in a renewal run is normally the useful one. Later messages often describe cleanup or skipped certificates after the original authorization, DNS, permission, or hook problem has already occurred.
#1 Best Overall
Fast triage: capture the failure without spending rate-limit budget
- Run a dry run. Execute
sudo certbot renew --dry-run, or the equivalent dry-run command for the ACME client you actually use. Save the complete output. - Record the failure context. Note the certificate name, every domain identifier, the challenge type, HTTP status or DNS response, and any pre-, deploy-, or post-hook exit code.
- Stop repeated production attempts. Do not place the command in a tight retry loop while authorizations are failing. Use the staging environment for repeated troubleshooting and wait for any stated reset time when a limit has been reached.
- Identify the renewal lineage. List the configured certificates with
sudo certbot certificates, then match the failed certificate name to its renewal file.
A dry run can still fail because it exercises your authenticator, DNS plugin, web-server configuration, hooks, credentials, and routing. Passing a dry run is a useful signal that the renewal path works; it does not by itself prove that the newly issued certificate is being served by your public endpoint.
Inspect the renewal profile before changing anything
Open the relevant file in /etc/letsencrypt/renewal/ with an account that can read it. The exact directory can differ when Certbot was installed through a package, container, virtual environment, or another ACME client.
Check these values together, rather than changing only the line named in the error:
- Authenticator: Identify whether the lineage uses webroot, a web-server plugin, a DNS plugin, or manual mode.
- Installer: Confirm which service is expected to receive the renewed files. A certificate can be issued successfully while the wrong proxy or virtual host continues serving the old one.
- Domains: Verify that all current hostnames are still intended to be on this certificate. A retired hostname with broken DNS can block renewal of every identifier in the lineage.
- Credential paths: Check that referenced DNS API tokens, account files, and hook scripts still exist and are readable by the scheduled job.
- Hooks: Review pre-, deploy-, and post-hook commands. Confirm they target the intended service and return a zero exit status.
- Lineage state: Do not delete renewal files or account data as a first response. Removing client state can make recovery harder and can discard the configuration needed to reproduce the original authorization method.
After making a backup of configuration, correct one class of problem at a time and rerun the dry run. This makes the next error attributable instead of masking several changes behind one production request.
Fixing HTTP-01 challenge failures
With HTTP-01, Let’s Encrypt places a token at http://YOUR_DOMAIN/.well-known/acme-challenge/TOKEN and fetches it from the public internet on port 80. The HTTP-01 challenge can only be done on port 80. Let’s Encrypt follows redirects only to HTTP or HTTPS on ports 80 or 443.
Test the path from outside your network
- Create a harmless test file in the webroot that the renewal profile uses, for example
.well-known/acme-challenge/test. - From a network that is not the server’s LAN, request
http://example.com/.well-known/acme-challenge/test. Use the real hostname and the exact webroot configured for the lineage. - Confirm that the response comes from the expected public edge, returns the file contents, and does not require a login, cookie, JavaScript challenge, or client certificate.
- Remove the test file after the check and rerun the dry run.
Open and route port 80 correctly
A local web server listening on port 80 is not enough if a cloud firewall, host firewall, NAT rule, security group, or load balancer blocks the public connection. Check each layer from the internet to the origin. If a load balancer terminates traffic, ensure it routes the challenge path to the backend that owns the webroot rather than to a default service.
Keep port 80 routing intentional even when normal visitors are redirected to HTTPS. An HTTP-to-HTTPS redirect is acceptable when it remains on port 80 or redirects to HTTPS on port 443. Redirects to another port, an internal hostname, or a non-HTTP scheme will not satisfy HTTP-01.
Correct virtual-host and CDN behavior
Multiple sites on one address can cause the challenge request to reach the wrong virtual host. Verify the requested hostname in the web server’s host matching rules, including IPv4 and IPv6 records. A CDN or reverse proxy must pass the /.well-known/acme-challenge/ path without rewriting it, caching an old token, injecting authentication, or sending the request to a different origin.
If DNS has both an A and an AAAA record, test both paths. A correctly configured IPv4 origin does not help if Let’s Encrypt reaches a broken IPv6 listener first.
Check the webroot and permissions
The webroot plugin writes a temporary token beneath the configured document root. Confirm that the directory exists, the web server can read it, and the scheduled Certbot user can create files there. Common mistakes include pointing Certbot at an application source directory instead of the published document root, using a container path that is not mounted into the web server, and applying a rule that denies all dot-prefixed directories.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
After correcting the path, test the exact URL externally again. A local curl result can be misleading when split DNS, a proxy environment, or a hosts-file override bypasses the public route.
Fixing DNS-01 challenge failures
DNS-01 proves control by publishing the requested TXT value at _acme-challenge.YOUR_DOMAIN. The web server does not need to be reachable, so DNS-01 is the practical option when port 80 cannot be exposed and the required method for wildcard certificates.
Verify the exact TXT record
- Start a dry run and copy the TXT value requested by Certbot. Do not substitute a previous token or a value copied from another hostname.
- Query the authoritative DNS service for
_acme-challenge.example.com, not only a local recursive resolver. Confirm that the exact value is visible. - Allow for provider and resolver propagation before retrying. A successful API response means the provider accepted the update; it does not guarantee that every authoritative server is already returning it.
- Remove stale TXT values when they are no longer required. Multiple simultaneous values are valid in some ACME workflows, but accumulated records can make DNS responses too large and can cause validation or truncation problems.
Check zone names and API permissions
DNS APIs often distinguish between the full record name and the name relative to a zone. Supplying _acme-challenge.example.com to a provider that expects only _acme-challenge can create a record at the wrong location. Confirm which authoritative zone contains the hostname, especially when the domain uses delegated subzones.
The API token must be valid for that zone and have the narrow permissions needed to create, update, and remove TXT records. A rotated, expired, or over-restricted token can produce an authentication error even when the DNS plugin itself is installed correctly. Store the credential outside publicly served directories and ensure the scheduled renewal user can read it.
Use a supported automation design
For unattended renewals, use a supported Certbot DNS plugin or delegate the _acme-challenge name through a CNAME or NS record to a zone whose updates can be automated. Delegation can limit the credentials exposed to the primary production DNS zone, but the delegated zone must be authoritative and correctly maintained.
Rank #4
When a DNS plugin waits for propagation, do not shorten its delay blindly. Increasing the wait can be appropriate for a provider with slow authoritative updates; the correct value depends on the provider’s behavior and the resolver path used by validation.
When the certificate was created with --manual
Certificates originally obtained with --manual do not support automatic renewal unless an authentication hook script supplies the required HTTP or DNS changes. A scheduled certbot renew job cannot answer an interactive prompt while unattended.
For HTTP validation, replace manual mode with a webroot or web-server plugin when the service can expose port 80. For DNS validation, use a supported DNS plugin or a carefully designed authentication hook that creates the TXT record, waits for propagation, and removes the record afterward. Make the hook non-interactive, give it explicit paths and environment handling, and test both success and cleanup in the staging environment.
Hooks, scheduled jobs, and system conditions
Prevent overlapping renewals
Ensure that only one scheduled renewal job runs at a time. Two concurrent runs can overwrite temporary challenge files, race while updating TXT records, or reload a service while another process is still writing the certificate. Use the scheduler’s locking facility or an equivalent single-instance mechanism.
Make hooks deterministic
- Use absolute paths to executables and scripts.
- Do not assume an interactive shell, a login profile, or user-specific environment variables.
- Verify that rotated secrets are available to the scheduler account.
- Return a nonzero status when a required operation fails; otherwise Certbot may report an apparently successful renewal while deployment did not occur.
- Reload the correct web server or proxy only after issuance has succeeded.
A deploy hook that fails after certificate issuance needs separate handling from an authorization failure. First confirm whether new certificate files exist, then repair the hook and reload the service deliberately. Avoid repeatedly requesting certificates when the remaining problem is only deployment.
Best Value
- Used Book in Good Condition
Check time, permissions, and storage
- Confirm that system time and timezone synchronization are correct. Significant clock errors can invalidate ACME timestamps and make certificates appear not yet valid or already expired.
- Check ownership and permissions on Certbot configuration, account data, renewal files, private keys, and hook credentials. Files should be readable only by the users and services that need them.
- Check free disk space and available inodes. A full filesystem can prevent temporary challenge files, logs, or renewed keys from being written even when network validation is healthy.
- Inspect service logs as well as Certbot output. A web server may log a permission denial or virtual-host mismatch that is not obvious in the ACME client’s summary.
Rate limits: know when to stop retrying
Let’s Encrypt’s currently published figures include:
| Limit | Published value | What to do |
|---|---|---|
| Failed authorizations | 5 per identifier per account per hour | Stop production retries, fix the authorization path, and wait for the stated reset time. |
| Certificates per registered domain | 50 every 7 days | Use staging while testing and avoid repeatedly issuing the same certificate. |
| Certificates per exact identifier set | 5 every 7 days | Keep the identifier set stable while troubleshooting and wait for the limit to reset if reached. |
The applicable limit message can include a Retry-After value or another reset time. Follow that value rather than guessing. A failed dry run is preferable to consuming production authorizations, but it does not replace fixing the underlying routing, DNS, credential, or hook error.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Retry safely after the repair
- Run
certbot renew --dry-runagain and confirm that the previously failing lineage completes. - If the dry run passes, allow the normal scheduled job to perform production renewal or run the client once during an approved maintenance window. Do not launch several production attempts.
- Inspect the resulting certificate files, expiry date, subject names, and chain.
- Connect to every public endpoint, including load-balanced and IPv6 paths, and inspect the certificate actually served by the proxy or web server.
- Confirm that the service reload succeeded and that applications using the certificate did not retain the old chain in memory.
A newly issued certificate is not proof of a complete fix if the live endpoint still serves the previous certificate. Deployment verification closes that gap.
HTTP-01 versus DNS-01: choose the method that fits the service
| Axis | HTTP-01 | DNS-01 |
|---|---|---|
| Network requirement | Public port 80 and a correctly routed challenge path | A DNS provider able to publish TXT records; the web server need not be reachable |
| Wildcard support | No | Yes |
| Main failure surface | Firewall, NAT, CDN, redirects, virtual-host routing, and port 80 | API credentials, wrong zone or record name, propagation delay, and stale TXT records |
| Automation | Webroot or web-server plugins are usually straightforward | A DNS plugin or delegated validation zone is required for unattended operation |
| Primary security concern | Exposing the challenge path and maintaining port 80 routing | Protecting narrowly scoped DNS API credentials |
Choose HTTP-01 when the hostname has reliable public port-80 routing and a stable webroot. Choose DNS-01 for wildcard names, private or non-HTTP services, or environments where port 80 cannot be exposed, provided DNS updates can be automated securely.
Build prevention into the next renewal cycle
- Keep Certbot, its plugins, and the operating system’s ACME dependencies updated through your normal maintenance process.
- Document the authenticator, certificate lineage, DNS zone, CDN or proxy, origin service, and deployment hook for every hostname.
- Keep port 80 routing intentional for every HTTP-01 hostname, including firewall, load-balancer, IPv6, and redirect rules.
- Use a supported automated authenticator rather than leaving a production lineage in manual mode.
- Store DNS credentials with least privilege, rotate them deliberately, and verify that the scheduler can still read the replacement credential.
- Serialize renewal jobs so that only one process changes a lineage or reloads the service at a time.
- Test renewal in staging and with dry runs after changes to DNS, CDN, firewall, web-server, container, or proxy configuration.
- Alert on failed dry runs, hook failures, and certificate-expiry thresholds rather than waiting for an outage.
- Reload services only after successful issuance and confirm the live chain afterward.
- Keep logs long enough to correlate a failed authorization with DNS, firewall, proxy, and service changes.
The durable fix is not simply running Certbot again. It is a repeatable validation path, a non-interactive authenticator, a serialized scheduler, and monitoring that reports a failed renewal while there is still time to repair it.
Quick Recap
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.
