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.
If Let’s Encrypt will not issue a certificate for your VPS, start by checking the validation path rather than the HTTPS page you can see in a browser. The certificate authority must prove control of every name in the order. For HTTP-01, that means fetching a token from your server on TCP port 80; for DNS-01, it means finding the exact TXT record at _acme-challenge.<domain>. A working site on HTTPS does not prove either challenge can complete.
Work through DNS, external reachability, firewall and listener checks, then use the challenge method that matches your deployment. Test repeated attempts on Let’s Encrypt’s staging service until the underlying fault is fixed.
Recommended Free Tools
What Let’s Encrypt is actually checking
An ACME order can contain several identifiers, such as an apex name and its www name. Let’s Encrypt validates each identifier separately. If one name points to another machine, has an incorrect IPv6 address, or cannot expose the required proof, the order fails even when another name loads correctly.
The browser view of your site is only an application test. During issuance, the CA contacts your DNS target and looks for a specific, short-lived proof. The proof must be reachable through the challenge rules, not merely through your normal home page.
HTTP-01
HTTP-01 puts a token file below /.well-known/acme-challenge/. Let’s Encrypt retrieves that file over HTTP on TCP port 80. The CA may follow up to ten redirects, but the redirect chain must stay on HTTP or HTTPS ports 80 or 443. A redirect to a custom port, an authentication wall, a loop, or the wrong virtual host can therefore fail validation.
DNS-01
DNS-01 asks you to prove control of the DNS zone by publishing a specific TXT value at _acme-challenge.<domain>. It does not need the web service to be public on port 80 and is the only challenge method that can issue wildcard certificates.
Fast diagnostic sequence
Use this order. It separates an incorrect target from a network problem, a web-server problem, and an ACME-client problem.
- List every identifier in the order. Include the apex,
www, API names, and any wildcard or SAN names. Check each one individually. - Inspect both A and AAAA records. The A record may point to your VPS while an unexpected AAAA record sends Let’s Encrypt to a different host. Remove or correct an obsolete IPv6 record, or make the IPv6 listener serve the same challenge.
- Confirm the authoritative DNS zone. If a proxy or CDN is in front of the VPS, verify that it forwards the challenge path. Make sure the TXT record is being added to the authoritative zone, not to a similarly named zone at another DNS provider.
- Choose the challenge test. For HTTP-01, request the token path from a network outside the VPS. For DNS-01, query the authoritative nameservers for the exact TXT value.
- Check all network layers. Permit the needed traffic in the VPS provider’s security group, the host firewall, any router or NAT rule, and the proxy or CDN.
- Match Certbot to the service layout. Use webroot or web-server integration when a listener already serves the site, standalone when Certbot can temporarily bind port 80, and a DNS plugin when DNS is the proof mechanism.
- Retry on staging. Do not spend production attempts while the same DNS or routing fault remains.
Fixing an HTTP-01 failure
1. Test the exact token path externally
During a run, Certbot creates a file whose name is supplied by the ACME server. From a separate network, request that exact URL over plain HTTP:
curl -i http://example.com/.well-known/acme-challenge/<TOKEN>Replace the domain and token with the values from the current validation attempt. The response should come from the intended VPS and contain the token text, normally with a successful HTTP status. Testing from the VPS itself can miss an upstream firewall, NAT, split-DNS behavior, or an IPv6 routing problem, so use a mobile connection or another external host as well.
2. Open and route TCP port 80
HTTP-01 cannot use an arbitrary alternate port. Allow inbound TCP 80 at every layer between Let’s Encrypt and the web server:
Free tools Windows power users keep installed
One-click scans. No signup required.
- the VPS provider’s cloud firewall or security group;
- the operating-system firewall;
- the home or office router’s port-forwarding rule, if the VPS is behind NAT;
- the CDN, reverse proxy, or load balancer in front of the server; and
- the server’s own listener and virtual-host configuration.
For a host using UFW, an example rule is sudo ufw allow 80/tcp. On another firewall implementation, create the equivalent inbound rule; do not assume an open outbound policy also permits inbound validation.
3. Correct DNS targets and IPv6
Resolve the name from more than one network and compare the results with the VPS addresses. Every requested name must reach a machine that can serve the token. If an AAAA record exists, Let’s Encrypt can reach that IPv6 address; it will not automatically fall back to your A record when IPv6 is advertised but broken. Either configure IPv6 correctly, serve the same challenge there, or remove the stale AAAA record before retrying.
When a proxy or CDN is enabled, verify that it passes /.well-known/acme-challenge/ to the origin without authentication, caching of stale challenge content, or a rewrite to a different backend. If the proxy terminates TLS but does not accept HTTP on port 80, use its documented HTTP forwarding behavior or select DNS-01.
4. Inspect redirects and virtual hosts
Redirecting HTTP to HTTPS is compatible with HTTP-01 when the chain ends on port 80 or 443. Let’s Encrypt follows up to ten redirects. Problems include:
- a loop between the proxy and origin;
- a redirect to a nonstandard port such as 8080;
- redirecting the challenge to a login page or an application route;
- a default virtual host answering instead of the requested name; or
- rewriting the token path to a missing file.
Temporarily request the URL with headers shown (curl -I) and then with the full response (curl -i). Follow each Location value and confirm that the final response still contains the token. Keep the exception narrow: expose only the ACME directory, not an administrative interface.
5. Select the correct Certbot mode
certbot --standalone starts a temporary server and must bind TCP port 80. If Nginx, Apache, a container, or another process already owns that socket, standalone mode fails before validation. Stop the conflicting service briefly, or use webroot/server integration instead. A typical webroot request is:
sudo certbot certonly --webroot -w /var/www/html -d example.com -d www.example.comThe -w directory must be the actual document root used by the virtual host. In a container or multi-node setup, the directory must be shared or synchronized so that whichever node receives the request has the token file.
Certbot’s manual mode requires you to copy challenge material yourself. It does not renew unattended unless you add suitable hooks, so it is best reserved for exceptional environments rather than routine production certificates.
When DNS-01 is the better fix
Choose DNS-01 when port 80 is intentionally blocked, the service is private, the web listener cannot be exposed, or you need a wildcard such as *.example.com. The VPS does not need to answer an HTTP request for this proof.
Publish the exact TXT value
- Start the ACME client’s DNS-01 authorization and copy the exact TXT value it provides.
- Create the record at
_acme-challenge.example.com(or the corresponding name for the identifier being validated). - Wait until the authoritative DNS servers return that value.
- Query the authoritative nameservers and confirm the complete value, including punctuation and capitalization where the provider preserves it.
- Allow validation to complete, then remove obsolete TXT values when your provider or client instructs you to do so.
Multiple TXT records can be legitimate when several authorizations overlap, but stale or duplicated records can create an oversized DNS response or make troubleshooting ambiguous. Do not replace a current value while another authorization is still running.
Automate renewal safely
A Certbot DNS plugin or another ACME client that updates your DNS provider through its API is preferable for unattended renewal. Give the API credential the narrowest zone-editing scope available and store it with permissions that prevent ordinary users from reading it. Manual TXT entry proves control once but will not renew automatically unless you build and maintain hooks that perform the same update.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
HTTP-01 versus DNS-01
| Axis | HTTP-01 | DNS-01 |
|---|---|---|
| Required proof path | Token file fetched over TCP 80 | TXT record at _acme-challenge |
| Works with port 80 blocked | No | Yes |
| Wildcard certificates | No | Yes |
| Main operational risk | Firewall, routing, virtual-host, or multi-node reachability | Wrong DNS zone, propagation, stale TXT, or API credentials |
| Automation | Usually simple with webroot or server plugins | Best with a DNS provider API or plugin |
Use HTTP-01 when a public web listener is stable and you want the simplest web-server integration. Use DNS-01 when network exposure is unacceptable, the service is not public, or wildcard coverage is required.
Staging first: protect the authorization budget
Let’s Encrypt documents a limit of five authorization failures per identifier per account per hour. The allowance refills at one authorization every 12 minutes. Repeated production retries can therefore pause progress even after you discover the real cause.
- Switch Certbot or your ACME client to Let’s Encrypt’s staging environment while diagnosing.
- Run the same challenge there and inspect the complete error, DNS response, redirect chain, and server log.
- Change one underlying condition at a time so you know which fix worked.
- Only after a staging authorization succeeds, switch back to production and request the certificate once.
Staging certificates are not trusted by normal browsers. Their purpose is to verify the challenge and deployment process without consuming the production authorization budget.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Common failure symptoms and targeted fixes
| Symptom | Likely cause | Action |
|---|---|---|
| “Connection refused” or timeout on HTTP-01 | Port 80 blocked, no listener, incorrect NAT, or unreachable address | Check provider and host firewalls, port forwarding, A/AAAA records, and the process listening on port 80. |
| Token URL returns your normal home page | Rewrite rule or application fallback intercepts the ACME directory | Serve the token file directly from the configured webroot and exclude that path from authentication and application rewrites. |
| Token URL returns the wrong server | Default virtual host, proxy backend, stale DNS, or unexpected IPv6 target | Inspect the Host routing, proxy origin, A and AAAA records, and each node in the deployment. |
| Too many redirects | Proxy/origin HTTPS disagreement or a redirect loop | Trace every Location header and end on HTTP or HTTPS port 80/443. |
| Standalone Certbot cannot bind | Another process owns port 80 | Stop or reconfigure that process temporarily, or change to webroot/server integration. |
| DNS-01 reports TXT not found | Wrong authoritative zone, propagation delay, typo, or provider API failure | Query authoritative nameservers, compare the exact value, and verify the API credential edits the active zone. |
| DNS response is unusually large or inconsistent | Stale or excessive TXT records | Remove obsolete challenge values after active authorizations finish and keep only records required by current validations. |
| One hostname validates and another fails | Only one identifier reaches the correct machine or zone | Test every name separately, including its IPv6 result and proxy path. |
Port 80 and the security question
Let’s Encrypt recommends that general-purpose web servers offer both HTTP on port 80 and HTTPS on port 443. Ordinary HTTP requests can be redirected immediately to HTTPS. Closing port 80 does not protect users from an active man-in-the-middle attacker; it mainly removes the HTTP-01 validation path and can make first-contact behavior less reliable. If policy requires port 80 to remain closed, use DNS-01 rather than repeatedly forcing HTTP-01 to work.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →After issuance: renewal and deployment checks
Verify the installed certificate
Confirm that the certificate contains every requested name and that the web server is presenting the newly issued certificate, not an older file. Check the server’s configured certificate path and reload mechanism. A successful ACME order is not proof that the live listener has reloaded it.
Run a renewal rehearsal
Use the client’s renewal test in the same network, account, DNS, and service environment used in production. For Certbot, the usual command is:
sudo certbot renew --dry-runReview the result and the client logs. Verify that a successful renewal triggers the web-server reload or deploy hook you rely on.
Keep the renewal environment stable
- Keep outbound TCP 443 available from the ACME client.
- Keep inbound TCP 443 available to users after deployment.
- For HTTP-01, retain inbound TCP 80 and the working challenge route.
- Protect Certbot’s configuration, work, and log directories from unauthorized access.
- Do not run concurrent Certbot processes; lock-file collisions can interrupt issuance or renewal.
- For DNS-01, monitor API credentials, token scope, and the authoritative zone after DNS-provider changes.
A repeatable checklist
- Every identifier in the order resolves to the intended infrastructure.
- A and AAAA records are both correct, or the unused family is removed.
- The authoritative DNS zone is the one being edited.
- HTTP-01 token requests succeed from an external network, or DNS-01 TXT queries return the exact value.
- Firewalls, security groups, NAT, proxies, and load balancers permit the selected challenge.
- The Certbot mode matches the listener, webroot, or DNS API.
- All nodes can serve the token in a multi-node deployment.
- Staging succeeds before production retries.
- Renewal testing and certificate reloads have been verified.
Official guidance in brief
Let’s Encrypt’s Challenge Types documentation, updated February 12, 2026, states: “The HTTP-01 challenge can only be done on port 80.” The same documentation describes DNS-01 as proving DNS control by putting a specific value in a TXT record under the domain. Certbot’s FAQ notes that, except for DNS authentication, the web server must listen on port 80 or be capable of doing so temporarily during validation. Let’s Encrypt’s January 24, 2019 best-practice guidance recommends that servers intended for general web use offer both HTTP on port 80 and HTTPS on port 443.
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 minuteQuick 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.
