The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →iTechGuides 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.
Most Let’s Encrypt errors on Apache are not certificate-cryptography problems. They are validation or deployment problems: the hostname resolves to the wrong server, port 80 cannot be reached, Apache selects the wrong virtual host, a rewrite hides the challenge file, or Apache is using the wrong certificate file. Fix the failing stage first, then test renewal separately.
This guide covers HTTP-01 and DNS-01 validation, Apache virtual-host and listener checks, certificate-file selection, safe reloads, and renewal failures.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errors
Identify which stage is failing
Certbot performs two different jobs. An authenticator proves that you control a hostname by answering an ACME challenge. An installer changes Apache configuration to use the resulting certificate. A failure during validation has a different remedy from a failure while Apache is being edited or reloaded.
Validation errors
Messages such as “connection refused,” “timeout,” “404,” “unauthorized,” or “invalid response” mean that Let’s Encrypt could not retrieve the expected challenge response. Troubleshoot DNS, routing, the challenge method, Apache’s port listeners, virtual hosts, rewrites, and file permissions.
#1 Best Overall
Installation or reload errors
Errors from Apache syntax checks, missing files, unreadable private keys, duplicate directives, or a failed service reload occur after validation. The certificate may already have been issued; correct the Apache configuration and reload it safely.
Renewal errors
A certificate that worked previously can still fail at renewal. DNS may have changed, a firewall or load balancer may have been introduced, the webroot may have moved, or a manual authentication step may no longer run. Treat renewal as a separate operational test rather than assuming a working HTTPS site proves renewal will succeed.
Start with a five-minute triage
- Write down every hostname in the certificate request, including
wwwnames and any other aliases. - Check each hostname’s public
AandAAAArecords. Confirm that they point to the endpoint where the intended Apache instance runs. - Determine whether Certbot is using HTTP-01 or DNS-01. HTTP-01 needs public HTTP access; DNS-01 needs an authoritative TXT record.
- For HTTP-01, test a file in the exact
/.well-known/acme-challenge/path from a network outside the server. - After correcting the cause, run one validation attempt. Do not repeatedly request certificates while the same error remains; repeated failures can trigger CA rate limits.
Use the error text as a routing clue. A 404 normally means the request reached a web server but not the expected token. A timeout or refusal usually means that the request never reached a usable port-80 listener.
Check DNS before changing Apache
Let’s Encrypt validates every requested hostname independently. A single stale alias can make the whole order fail even when the main site works.
Verify both address families
Query the public DNS view for both record types:
dig +short A example.com
dig +short AAAA example.com
dig +short A www.example.com
dig +short AAAA www.example.comReplace the names with every hostname in the Certbot request. If an AAAA record leads to an old machine, an IPv6-capable validator can reach that machine instead of the IPv4 server. Remove the stale record or configure the IPv6 endpoint to serve the same challenge.
Confirm the actual public endpoint
Check that the returned address belongs to the server, reverse proxy, load balancer, or NAT device that is supposed to handle Apache traffic. If several front ends exist, each one must preserve the challenge path or route it to the same webroot. Internal DNS answers are not sufficient; validation comes from the public Internet and may use multiple vantage points.
Recommended Free Tools
Fix HTTP-01 challenge failures
With HTTP-01, Let’s Encrypt requests a URL in this form:
http://example.com/.well-known/acme-challenge/TOKENCertbot places the token in a webroot or serves it through an Apache authenticator. A working HTTPS home page does not prove that this HTTP challenge URL is reachable or returns the token.
Test the exact path and webroot
- Find the webroot configured for the failing virtual host. If Certbot uses
--webroot -w /var/www/example, the token must be under/var/www/example/.well-known/acme-challenge/. - Create a harmless test file in that directory:
sudo mkdir -p /var/www/example/.well-known/acme-challenge
printf 'acme-testn' | sudo tee /var/www/example/.well-known/acme-challenge/health.txt- Request it externally, not only with a local browser:
curl -i http://example.com/.well-known/acme-challenge/health.txtThe response should be HTTP 200 with the exact text acme-test. Test each hostname, including its www alias. Delete the test file when finished.
Correct virtual-host selection
Inspect the port-80 virtual hosts and confirm that the intended one has the right ServerName and ServerAlias. The request must not land on a default site, an old deployment, or a redirect-only host whose document root differs from the Certbot webroot.
sudo apachectl -SOn systems where the binary is named differently, the equivalent Apache control command is commonly apache2ctl -S. Compare the output with the hostname and address returned by DNS. If a proxy or load balancer fronts Apache, verify that it forwards /.well-known/acme-challenge/ without changing the host header or path.
Make sure Apache listens on port 80
HTTP-01 normally requires public TCP port 80. Check the configuration for Listen 80 and verify a process is actually bound:
sudo ss -ltnp | grep ':80'Also inspect cloud firewalls, host firewalls, NAT rules, security groups, and provider-level filters. A local listener cannot help if the public address forwards port 80 elsewhere. A timeout commonly indicates filtering or a broken route; “connection refused” commonly indicates that no reachable service is listening or that a firewall is actively rejecting the connection.
Remove rewrites and access rules that intercept the challenge
Global HTTP-to-HTTPS redirects are normally acceptable when they preserve the challenge path, but custom rewrite rules can send the request to an application, return a 404, require authentication, or loop between hosts. Exclude /.well-known/acme-challenge/ from application routing and authentication. Check .htaccess, RewriteRule directives, and front-end proxy rules as well as the vhost file.
Directory permissions must allow Apache to traverse each parent directory and read the token file. The web server does not need write access to the entire site; grant only the controlled access required by the chosen Certbot method. If a security module or container policy blocks reads, the Apache error log will usually show the denial.
Read the logs while testing
Watch the Apache error log and access log during a single request. Confirm which vhost handled the request, the status code returned, and the filesystem path Apache attempted to read. This distinguishes a wrong webroot from a network failure before you run Certbot again.
Use DNS-01 when HTTP cannot work
DNS-01 proves control by publishing a TXT record at _acme-challenge.example.com. It avoids inbound HTTP and is the documented route for wildcard certificates such as *.example.com.
What must be true
- You must control the authoritative DNS zone for the name.
- The TXT value generated for the active authorization must be published exactly, without quotation marks added to the value itself.
- Authoritative nameservers must have the new record before validation starts; recursive resolvers can retain old answers during propagation.
- If several authorizations are active, multiple TXT values may temporarily be valid. Do not delete an older value until you have confirmed which authorization is being checked.
Automate carefully
A Certbot DNS plugin can create and remove TXT records through a provider’s API. Give the API credential the narrowest zone permissions possible and keep it outside web-accessible directories. Manual DNS authentication does not become automatic merely because the first certificate was issued; a renewal job needs a repeatable authentication hook or an equivalent automated plugin.
Query the authoritative DNS servers, not just one local resolver, when diagnosing propagation:
dig TXT _acme-challenge.example.comA missing, mistyped, stale, or not-yet-published TXT record produces a DNS-01 failure even when Apache and HTTPS are completely healthy.
Choose the right challenge method
| Consideration | HTTP-01 | DNS-01 |
|---|---|---|
| Required control | Public HTTP reachability on port 80, correct vhost routing, and a readable challenge path | Authoritative DNS control and TXT publication under _acme-challenge |
| Wildcard certificates | Not the documented route for wildcard issuance | Supports wildcard certificates |
| Good fit | Ordinary hostnames on a server that can expose port 80 | Wildcards, firewalled or private origins, and architectures where HTTP cannot reach Apache |
| Typical failures | Wrong DNS, firewall or NAT, missing listener, wrong vhost, rewrite, 404, timeout, or refusal | Missing, incorrect, stale, or unpropagated TXT records |
Switching methods is a design decision, not a way to hide an unresolved configuration error. If port 80 is intentionally unavailable, DNS-01 is usually the practical choice; if DNS automation is not reliable, fixing HTTP-01 may be safer for ordinary hostnames.
Configure Apache to use the correct certificate files
Certbot maintains the current certificate set as symlinks under /etc/letsencrypt/live/<domain>/. Point Apache at those live paths rather than copying a dated file from an archive directory.
Apache 2.4.8 and newer
Use the full certificate chain and the matching private key:
SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pemfullchain.pem contains the leaf certificate followed by the necessary intermediate chain. privkey.pem is secret; restrict ownership and mode so the Apache process can read it while ordinary users cannot. Never publish it through the document root, source repository, backup download, or support ticket.
Older Apache releases
Older Apache versions may require the leaf certificate and chain separately, using cert.pem with chain.pem. Check the installed Apache version and its SSL module documentation before changing directives. Do not substitute cert.pem for fullchain.pem on a modern installation when clients need the intermediate chain.
Match names and permissions
Ensure the certificate covers every requested hostname and that the SSL virtual host has the intended ServerName and ServerAlias. A correct file path still fails if Apache cannot traverse the /etc/letsencrypt/live symlink chain or read the target files. Fix group ownership or ACLs deliberately rather than making the private key world-readable.
Free tools Windows power users keep installed
One-click scans. No signup required.
Validate configuration and reload safely
- Run Apache’s configuration test before touching the running service:
sudo apachectl configtestProceed only when it reports Syntax OK. If it names a file or line, fix that exact issue first. Common causes include a typo in a certificate path, a missing SSL module, duplicate directives, and permissions on the private key.
- Inspect the Apache error log for certificate parsing, permission, protocol, or virtual-host messages.
- Reload gracefully so existing connections can finish:
sudo systemctl reload apache2Some distributions use the service name httpd instead:
sudo systemctl reload httpd- Confirm the service remains active and request the site over HTTPS. Check the served certificate’s names and expiry from an external client, not only from the local certificate file.
Certbot’s Apache installer needs administrator privileges to edit configuration and reload the daemon. If you run Certbot without sufficient privileges, separate issuance from installation: obtain the certificate with an authenticator, then make controlled Apache changes as an administrator.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Fix renewal failures before the certificate expires
Run a simulated renewal regularly:
sudo certbot renew --dry-runThe dry run exercises the configured authenticator and, where applicable, deployment and reload hooks without replacing the production certificate. A successful HTTPS page is not a renewal test.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteInspect the renewal configuration
Review the relevant files in /etc/letsencrypt/renewal/. Confirm the recorded authenticator, webroot, domains, DNS plugin, and any hooks still match the current server. Logs in /var/log/letsencrypt/ show the exact authorization and hook failure.
Check scheduled execution and hooks
Verify that the system’s timer or cron job runs as the expected user and has network, DNS-API, and filesystem access. A deploy or post-renewal hook should reload Apache only after a successful renewal. Test the hook command separately and make sure it exits with a success status; a broken hook can leave a newly issued certificate unused.
Manual authentication needs automation
Certificates created with Certbot’s manual plugin do not renew automatically unless authentication hooks are supplied. If renewal requires a person to create a TXT record or token each time, replace that process with a supported automated DNS plugin or a reliable hook before relying on unattended renewal.
Error-to-cause troubleshooting table
| Observed error | Most likely checks |
|---|---|
| Connection refused | Port 80 listener, host or provider firewall, NAT forwarding, proxy target, and whether DNS points to the active server |
| Timeout | Public routing, firewall drops, security groups, IPv6 path, and load-balancer health |
| HTTP-01 404 | Selected vhost, ServerName/ServerAlias, webroot, rewrite or application routing, token-file permissions, and proxy path handling |
| HTTP-01 wrong content | Another server or vhost is answering, a cache is serving old content, or a proxy is changing the request |
| DNS-01 unauthorized | TXT name or value, authoritative zone, propagation, stale conflicting records, and DNS-plugin credentials |
| Apache will not reload | apachectl configtest, certificate paths, SSL module, private-key readability, duplicate directives, and log messages |
| Renewal works in theory but not unattended | Timer or cron execution, expired API credentials, changed webroot, manual authentication, and deploy/reload hook status |
A repeatable recovery sequence
- List every hostname and classify the failing stage.
- Verify public
AandAAAAanswers and the endpoint each address reaches. - Choose HTTP-01 only when port 80 and the challenge path can be publicly served; otherwise configure DNS-01.
- Test a file at the exact HTTP-01 path, or query the authoritative DNS TXT record for DNS-01.
- Correct vhost routing, rewrites, firewall rules, NAT, permissions, or DNS automation indicated by that test.
- Run one Certbot attempt and save its output.
- Point Apache at the current live files, normally
fullchain.pemandprivkey.pem, then runapachectl configtest. - Reload gracefully and verify the externally served certificate.
- Run
certbot renew --dry-runand confirm the scheduled job and hooks before the next expiry window.
Let’s Encrypt considers validation successful only when its checks receive the expected responses from the web server. That is why a visible HTTPS page, a locally readable token, or a certificate file on disk is not enough by itself: the public challenge request must reach the correct service and return the exact response.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →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.
