A Let’s Encrypt certificate can fail even when your site opens normally over HTTPS because the certificate authority must independently prove control of every name in the order. Most VPS failures come from an unreachable HTTP-01 token on port 80, an incorrect A or AAAA record, a proxy or virtual-host mismatch, or a DNS-01 TXT record published in the wrong place. Verify the requested names and DNS first, test the exact challenge path from outside your network, then choose a Certbot mode that matches how your service and DNS are operated.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
What a Let’s Encrypt failure actually means
During issuance, Let’s Encrypt sends an ACME challenge for each identifier in the certificate request. A normal page load is not proof that the CA can complete that challenge: the CA must retrieve a specific token over HTTP or find a specific value in DNS. If an order includes both example.com and www.example.com, both names must pass.
As an Amazon Associate I earn from qualifying purchases.
That distinction explains the common symptom “the site works, but the certificate will not issue.” Your browser may be reaching a cached HTTPS page, a different server, or a proxy, while Let’s Encrypt is reaching another address or cannot access the temporary proof at all.
Choose the challenge that fits your VPS
| Axis | HTTP-01 | DNS-01 |
|---|---|---|
| Proof path | Let’s Encrypt fetches a token file at /.well-known/acme-challenge/<TOKEN> over TCP port 80. |
Let’s Encrypt looks for a TXT record at _acme-challenge.<domain>. |
| Port 80 blocked | Does not work. | Works, provided DNS can be updated and observed authoritatively. |
| Wildcard certificate | Not supported. | Required for names such as *.example.com. |
| Main operational risk | Firewall, routing, NAT, proxy, virtual-host, or multi-node reachability. | Wrong authoritative zone, propagation delay, stale TXT data, oversized responses, or incorrect API credentials. |
| Automation | Usually straightforward with webroot or web-server integration. | Most reliable with a DNS provider API plugin; manual TXT entry does not renew unattended. |
Let’s Encrypt states that “The HTTP-01 challenge can only be done on port 80” (Challenge Types documentation, updated February 12, 2026). Redirecting ordinary visitors from port 80 to HTTPS is compatible with validation; moving the challenge to an arbitrary port is not.
Do not choose a challenge merely because the public website appears healthy. Choose the proof path that your network can expose consistently for every identifier. A public, single-node site with an existing web server is usually simplest with webroot or server integration. A private service, blocked port 80, or wildcard request points to DNS-01 instead.
Fix the problem in this order
1. Confirm every identifier and its DNS destination
- Write down every name in the certificate request, including the apex name,
www, and any additional subdomains. - Check each name’s A record and AAAA record. Both must point to infrastructure that can serve the challenge. An old IPv6 (AAAA) address can send Let’s Encrypt to a different machine even when the IPv4 (A) address is correct.
- If a proxy or CDN sits in front of the VPS, verify that it forwards
/.well-known/acme-challenge/to the intended origin. A proxy cache, access rule, or alternate origin can return the wrong content. - Make sure you are editing the authoritative DNS zone. Updating a secondary or an unused hosted zone has no effect on the nameservers delegated for the domain.
For a multi-node service, DNS may direct validation to any node. The token must therefore be available on every node that can receive the request, or traffic must be routed consistently to the node holding the token. This is a frequent reason a test succeeds once and fails on the next attempt: different requests reach different machines with different challenge files.
Check the apex and each subdomain separately. One correctly pointed record does not compensate for another identifier that still resolves to an old VPS, staging host, or unrelated IPv6 endpoint. If a CDN is enabled, inspect both the public routing decision and the configured origin; changing only the origin does not help if the DNS record still points elsewhere.
2. Test HTTP-01 from outside the VPS network
HTTP-01 creates a temporary file at /.well-known/acme-challenge/<TOKEN>. Test that exact path from an external network rather than from localhost or the VPS itself. A simple check is:
curl -i http://example.com/.well-known/acme-challenge/test-tokenUse the actual token path shown by your ACME client when possible. The response must come from the server intended for that name, without an authentication page, redirect loop, or default-site content. Testing from another network matters because local DNS, a private route, or an internal load balancer can conceal the public failure.
- Permit inbound TCP 80 in the VPS provider’s security group or network firewall.
- Permit TCP 80 in the operating-system firewall.
- If the VPS is behind a router or NAT, forward TCP 80 to the correct private host.
- Check any CDN, reverse proxy, WAF, or load balancer for a rule that blocks the challenge directory.
- Confirm that the web server’s virtual host for each name serves the challenge directory rather than a catch-all site.
Let’s Encrypt can follow up to ten redirects, but they must remain on HTTP or HTTPS using ports 80 or 443. A redirect to a custom port, a loop between HTTP and HTTPS, or middleware that requires login will fail validation. A forced redirect to HTTPS is acceptable when the final destination is reachable on port 443 and the redirect chain stays within those allowed ports.
Recommended Free Tools
Inspect the entire response, not just the status line. A successful HTTP status can still contain the wrong page, a proxy-generated error, or a login form. The body must be the challenge content associated with that identifier. If the external request lands on a default virtual host, add the requested name to the correct server block and make the challenge directory available there.
3. Match Certbot’s mode to the service already running
certbot --standalone starts a temporary listener and therefore needs to bind port 80. If Nginx, Apache, a container, or another process already owns that socket, standalone mode cannot start until the competing listener is stopped or reconfigured. Stopping a production web server also creates avoidable downtime, so use webroot or web-server integration when an existing listener can serve the token.
- Webroot or web-server integration: keep the current listener active and configure Certbot to place the token in the directory that the matching virtual host exposes.
- Standalone: use when Certbot can temporarily bind port 80 and no other process must answer during validation.
- Manual mode: copy the challenge material yourself. It is useful for unusual deployments, but it does not provide automatic renewal unless you supply reliable renewal hooks.
- DNS plugin: let Certbot update the provider’s TXT record through an API when DNS-01 is the appropriate proof.
Check the actual listener before choosing standalone. A service bound only to IPv6, a container published on a different interface, or a host firewall that permits local traffic but blocks the internet can all make a seemingly available port unusable to Let’s Encrypt. Conversely, a free local port is not enough if the provider firewall or NAT path drops public traffic.
When using webroot, verify that the directory configured for Certbot is the same directory served by the name’s virtual host. Writing a token under one site’s document root while the request is routed to another produces a clean-looking but incorrect response. For manual mode, remember that every renewal requires another proof exchange; without hooks or an operator present, the initial success will not continue automatically.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
4. Use DNS-01 when HTTP-01 is the wrong fit
DNS-01 proves control by publishing the exact value supplied by the ACME client as a TXT record at _acme-challenge.example.com. It is the correct route when port 80 cannot be opened, the service is private, or a wildcard such as *.example.com is required. Wildcard issuance is available only through DNS-01.
- Identify the authoritative nameservers for the domain and open that provider’s DNS zone.
- Create the TXT record at the precise
_acme-challengename requested by the client. Do not put the value in an A, CNAME, or unrelated TXT record. - Wait until authoritative DNS servers return the new value. Recursive resolvers and provider interfaces can show different data while propagation is in progress.
- Remove obsolete challenge values that create an oversized or confusing response, while retaining any still-needed value if several validations are active.
- Prefer a Certbot DNS plugin or another ACME client with provider API access. Manual TXT entry must be repeated for renewal and therefore is not unattended by itself.
DNS-01 failures commonly mean the record was added to the wrong zone, the name was entered twice (for example, the provider appends the domain automatically), propagation has not completed, or API credentials cannot edit the authoritative zone. Confirm the exact record name and value at the authoritative servers rather than relying only on the control-panel view.
If more than one validation is active, several TXT values may legitimately coexist temporarily. Remove only stale values after the pending validations finish. Leaving a large collection of old values can produce oversized DNS responses and make lookups unreliable.
5. Debug on staging before spending production attempts
Repeated failed authorizations can trigger Let’s Encrypt’s documented limit of five authorization failures per identifier per account per hour, refilling at one authorization every 12 minutes (Let’s Encrypt, current documentation). Use the staging environment while correcting DNS, firewall, routing, or web-server configuration. Switch to production only after an external test proves that the selected challenge can succeed.
Free tools Windows power users keep installed
One-click scans. No signup required.
Do not respond to a rate-limit error by retrying unchanged settings. Wait for the allowance to refill and fix the underlying cause first; otherwise every new attempt consumes the same limited budget. The limit applies per identifier, so a single bad subdomain can exhaust its allowance even when the other names in the order work.
Why a working HTTPS site can still fail validation
HTTPS is served by a different endpoint
Your browser may resolve a cached address, follow a proxy, or use an already-issued certificate. Let’s Encrypt resolves the requested identifier independently and then requests the challenge. A stale A or AAAA record, split-horizon DNS, or a proxy pointing at an old origin can make those paths diverge.
The challenge reaches the wrong virtual host
Web servers select a site using the requested hostname. If the name is missing from the virtual-host configuration, the default site may return a generic page or a 404 instead of the token. Add every requested identifier to the correct server block and ensure the challenge directory is not denied by location rules.
Security middleware changes the response
Basic authentication, IP allowlists, bot protection, application rewrites, and a rule that sends every unknown path to a login page can intercept the token. Exempt /.well-known/acme-challenge/ from those controls while validation runs, then keep the rest of the application protected.
IPv6 bypasses the working IPv4 setup
If an AAAA record exists, Let’s Encrypt may use IPv6. An IPv6 firewall rule, route, NAT configuration, or web-server binding that differs from IPv4 can therefore cause failure even though an IPv4 curl test succeeds. Either make the IPv6 endpoint serve the same challenge or remove the stale AAAA record.
A redirect is valid for visitors but invalid for validation
HTTP-to-HTTPS redirection itself is not the problem. The failure occurs when the chain exceeds ten hops, loops, ends on a custom port, or reaches a protected endpoint. Trace every hop for the challenge URL and verify that the final response remains reachable on port 80 or 443.
Common symptoms and the corresponding fix
| Symptom | Likely cause | What to verify |
|---|---|---|
| Connection refused or timed out on HTTP | Port 80 blocked, no listener, incorrect NAT, or wrong address. | Provider firewall, host firewall, router forwarding, A/AAAA records, and an external request. |
| HTTP request returns the wrong site | Default virtual host, proxy origin mismatch, or missing server-name entry. | Host-based routing for every identifier and the origin serving the token directory. |
| Too many redirects | HTTP-to-HTTPS loop or redirect to a nonstandard port. | Complete chain; every hop must end on port 80 or 443. |
| 403, 401, or application login page | Authentication, WAF, or application middleware intercepts the challenge. | Allow unauthenticated access to the challenge path. |
| DNS-01 says TXT not found | Wrong zone, incomplete propagation, typo, or API update failure. | Authoritative nameserver data for the exact _acme-challenge name. |
| Standalone Certbot cannot bind | Another process owns port 80. | Stop or reconfigure the owner, or choose webroot/server integration. |
| Only one name fails in a multi-name order | That identifier resolves differently or lacks a matching virtual host. | Test each name separately, including its A and AAAA records. |
| Works on IPv4 but not for the CA | AAAA points to a different host or IPv6 is filtered. | Make IPv6 serve the challenge or remove the stale AAAA record. |
| DNS record appears in the panel but validation fails | Non-authoritative zone, duplicated domain suffix, or propagation delay. | Query the authoritative nameservers for the exact TXT name and value. |
After issuance: make renewal reliable
Issuance is only the first successful validation. Run the client’s renewal test in the same network, DNS, and service environment used in production. Confirm that renewal can update the certificate files and that the web server reloads the new certificate rather than continuing to serve the old one.
Crashes, 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 minutePC 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 & 11- Keep outbound TCP 443 available from the ACME client for API and validation-related communication.
- Keep inbound TCP 443 available to users who need the finished HTTPS service.
- If using HTTP-01, retain inbound TCP 80; Let’s Encrypt separately calls for it in its integration guidance.
- Protect Certbot’s configuration, work, and log directories because they can contain account and certificate-management data.
- Do not run concurrent Certbot processes. Overlapping jobs can collide on lock files and leave one renewal incomplete.
- For DNS-01, keep API credentials valid, least-privileged, and available to the renewal job; a one-time manual TXT success does not prove unattended renewal will work.
Let’s Encrypt recommends that general-purpose web servers offer both HTTP on port 80 and HTTPS on port 443 (Best Practice: Keep Port 80 Open, January 24, 2019). Redirecting ordinary HTTP requests to HTTPS provides a consistent user experience. Closing port 80 does not protect against an active man-in-the-middle; it only removes the HTTP-01 validation path.
Schedule renewal checks before the certificate’s expiration window, and monitor both the ACME client result and the web server’s active certificate. A successful file update is not enough if the daemon was never reloaded. Keep the same DNS API permissions, firewall rules, and challenge routing that worked during issuance.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.A compact recovery checklist
- List every identifier in the certificate order.
- Check each A and AAAA record and confirm the destination is the intended VPS or origin.
- Test the exact HTTP challenge path externally, including through any proxy or load balancer.
- Open TCP 80 through the provider firewall, host firewall, NAT, and proxy layers, or deliberately choose DNS-01 instead.
- Ensure the selected Certbot mode matches the listener: webroot/integration for an existing server, standalone only when port 80 is free, DNS plugin for API-managed DNS.
- For DNS-01, publish the exact TXT value at
_acme-challengein the authoritative zone and wait for visibility. - Use staging while correcting failures; avoid repeated production attempts that consume the authorization-failure allowance.
- After issuance, test renewal and verify the web server reloads the replacement certificate.
Frequently Asked Questions
Can I obtain a Let’s Encrypt certificate without opening port 80?
Yes. Use DNS-01 and publish the required TXT record at _acme-challenge.<domain>. HTTP-01 itself requires TCP port 80.
Why does Certbot standalone fail when my website is already online?
Standalone must bind port 80. If another web server or container owns that socket, stop or reconfigure it temporarily, or use webroot/server integration so the existing listener serves the challenge.
Do I need a wildcard certificate to cover normal subdomains?
No. Request each ordinary name explicitly. A wildcard such as *.example.com is optional and requires DNS-01 validation.
Is leaving port 80 open unsafe?
Let’s Encrypt recommends that general web servers offer both port 80 and 443, normally redirecting HTTP to HTTPS. Closing port 80 removes HTTP-01 but does not protect against an active man-in-the-middle.
Why does validation fail only for the IPv6 address?
An AAAA record may point to another host, or IPv6 firewall and routing rules may differ from IPv4. Make the IPv6 endpoint serve the same challenge or remove the stale AAAA record.
Can a CDN or reverse proxy break HTTP-01?
Yes. Verify that it forwards the challenge path to the intended origin, does not serve cached or alternate content, and allows the validation request through its access rules.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →How long should I keep retrying after an authorization error?
Stop retrying unchanged settings. Let’s Encrypt documents five authorization failures per identifier per account per hour, refilling at one authorization every 12 minutes. Use staging while fixing the cause.
Why does a DNS-01 TXT record look correct but still fail?
It may be in the wrong authoritative zone, have the domain suffix duplicated, still be propagating, or be blocked by invalid API credentials. Query the authoritative nameservers for the exact name and value.
Will manual DNS-01 validation renew automatically?
Not by itself. Manual TXT updates must be repeated at renewal; use a DNS provider API plugin or another automated ACME client for unattended renewals.
What should I verify after the certificate is issued?
Run the client’s renewal test in the production environment, confirm certificate files update, and verify that the web server reloads and serves the replacement certificate. Avoid concurrent Certbot jobs that can collide on lock files.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsThe Bottom Line
Let’s Encrypt validation is a reachability and control check, not a test of whether your homepage already loads. Verify every A and AAAA destination, expose the HTTP-01 token on port 80 through every firewall and proxy, or publish the exact DNS-01 TXT value from the authoritative zone. Match Certbot to the listener or DNS API, use staging until the path works, and test renewal before declaring the VPS fixed.
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.
