HTTP-01 vs DNS-01 for Client Websites: Which ACME Challenge Should Agencies Use?

The short version of http-01 vs dns-01 is this: HTTP-01 is usually simpler for normal client websites where the public HTTP path is reachable, while DNS-01 is better for wildcard certificates, locked-down hosts, and setups where DNS access is reliable. Neither challenge type is universally safer. The right choice depends on who controls the web server, who controls DNS, whether the certificate includes wildcards, and how much operational discipline the client has.

For agencies managing many client sites, the challenge type matters because it defines the failure path. HTTP-01 can fail because port 80, redirects, CDN rules, or webroot paths are wrong. DNS-01 can fail because DNS API access, zone ownership, TXT propagation, or CAA policy is wrong. Use 47-Day Renewal Pre-Flight to review public readiness signals, and use the free 10-domain agency audit when you need a broader portfolio snapshot.

CertPilot's methodology explains how public certificate and DNS checks are performed. These checks help surface risk, but they do not choose or configure your ACME client for you.

Quick answer: HTTP-01 vs DNS-01

HTTP-01 proves control by placing a token at a public HTTP URL on the domain. DNS-01 proves control by publishing a DNS TXT record. Let's Encrypt documents these and other validation methods in its challenge types guide.

Use HTTP-01 when:

• The site has a normal reachable web server.
• Port 80 can serve or redirect the validation path correctly.
• The host or ACME client can write to the webroot.
• The certificate is not a wildcard.
• The agency or host controls the web application path.

Use DNS-01 when:

• The certificate needs a wildcard name.
• The web server is not publicly reachable during validation.
• The site is behind strict access controls.
• DNS automation is reliable.
• The DNS owner can support the renewal workflow.

The real agency question is not "which challenge is best?" It is "which validation path has a known owner and fewer hidden dependencies for this client?"

How ACME challenge validation works in plain English

The certificate authority needs proof that the requester controls the domain. It does not take your dashboard label or client contract as proof. It checks something public and domain-specific.

With HTTP-01, the ACME client creates a token and makes it available at a URL under the domain. The certificate authority requests that URL and verifies the token.

With DNS-01, the ACME client creates a token and publishes it as a DNS TXT record. The certificate authority queries DNS and verifies the token.

Both methods can be automated. Both can fail. Shorter certificate lifetimes make those failures more visible because renewals happen more often.

When HTTP-01 is the right choice

HTTP-01 is a practical default for many ordinary websites. It works well when the web server is reachable, the hosting platform supports automatic certificate renewal, and the validation path is not blocked.

Good HTTP-01 candidates include:

• Standard WordPress sites on managed hosting.
• cPanel sites with built-in AutoSSL or ACME support.
• Static sites where the host manages certificates.
• Client sites where the agency controls the deployment and webroot.
• Non-wildcard certificates for apex and www.

HTTP-01 is attractive because it does not require DNS write access during every renewal. For agencies that do not control client DNS, that can be a major advantage.

When HTTP-01 causes renewal problems

HTTP-01 becomes fragile when the public HTTP path is unpredictable. Common failure causes include:

• Port 80 is closed.
• The challenge path returns 404.
• Every unknown URL redirects to the homepage.
• A CMS plugin blocks /.well-known/.
• A WAF blocks validation requests.
• A CDN handles HTTP and HTTPS differently.
• The ACME client writes the token to an old webroot.
• Staging protection or basic auth is left enabled.

The dedicated port 80 ACME renewal guide explains why HTTP still matters even when the production site uses HTTPS.

When DNS-01 is the right choice

DNS-01 is often the right choice when the certificate cannot rely on public HTTP reachability. It is commonly used for wildcard certificates because wildcard validation generally requires DNS-based proof.

Good DNS-01 candidates include:

• Wildcard certificates such as *.example.com.
• Locked-down applications that do not expose HTTP validation paths.
• Infrastructure where the web server may move but DNS automation remains stable.
• Multi-host certificates managed centrally.
• Environments where DNS provider API access is well controlled.

DNS-01 can be excellent for agencies with mature DNS operations. It can be risky when nobody owns DNS clearly.

When DNS-01 causes renewal problems

DNS-01 trades webserver risk for DNS ownership risk. Failures often come from:

• Expired DNS API tokens.
• Wrong DNS zone being updated.
• Client-owned DNS with no agency access.
• Slow or inconsistent TXT propagation.
• Split-horizon DNS confusion.
• CAA records blocking the intended certificate authority.
• Manual TXT updates that someone forgets to remove or rotate.

If your team cannot answer "who can update the authoritative DNS zone?" DNS-01 may become an escalation problem.

Where TLS-ALPN-01 fits

TLS-ALPN-01 validates over TLS on port 443 using a special temporary certificate response. It can be useful in certain automated environments, but most agency troubleshooting conversations are about HTTP-01 and DNS-01 because those are the common operational paths in hosting, DNS, and wildcard workflows.

The agency rule is simple: document the actual method in use. Do not assume a site uses HTTP-01 just because it is a normal website, and do not assume DNS-01 just because Cloudflare is present.

Challenge choice for common client stacks

| Client setup | Typical fit | Watch-outs | |---|---|---| | WordPress on managed hosting | HTTP-01 or platform-managed | Plugins, redirects, host-level SSL settings | | Shopify | Platform-managed | Domain DNS and platform verification | | Webflow | Platform-managed | DNS records and platform certificate state | | cPanel hosting | HTTP-01 through AutoSSL or ACME | Port 80, webroot, domain aliases | | Cloudflare in front of origin | Depends | Proxy mode, CAA, origin vs edge certificate | | Custom app behind WAF | DNS-01 or carefully configured HTTP-01 | WAF rules, validation path, ownership | | Wildcard certificate | DNS-01 | DNS API access, CAA issuewild, zone ownership |

This is not a vendor recommendation. It is a reminder that the visible platform often hides the validation method.

Agency decision table

| Challenge type | Best for | Requires | Common failure | Agency note | |---|---|---|---|---| | HTTP-01 | Normal public websites | Reachable HTTP challenge path | Port 80, redirects, webroot, WAF | Simple when host controls the path | | DNS-01 | Wildcards and locked-down hosts | DNS TXT write access | API token, wrong zone, propagation | Strong if DNS ownership is clear | | TLS-ALPN-01 | Certain automated TLS stacks | Correct 443 challenge handling | Proxy/load balancer interference | Less common in agency support | | Platform-managed | SaaS hosts and site builders | Correct domain verification | DNS mismatch or platform state | Ask platform what renewal depends on |

What changes under shorter certificate lifetimes

Under longer lifetimes, a weak renewal path might fail once a year. Under shorter lifetimes, the same weakness is exercised more often. That changes the operational bar for agencies.

For each client, document:

• Hostname.
• Certificate issuer.
• Renewal owner.
• Challenge type.
• DNS owner.
• CAA state.
• Whether wildcard certificates are involved.
• Who receives failure alerts.
• How the status appears in client reports.

This is also why SSL certificate renewal workload calculations matter. The issue is not one certificate. It is the repeated process across the portfolio.

How to document challenge type per client

Add these fields to your SSL inventory:

| Field | Example | Why it matters | |---|---|---| | Primary hostname | example.com | Avoids apex/www confusion | | Covered names | example.com, www.example.com | Shows certificate scope | | Challenge type | HTTP-01 | Defines the validation path | | DNS owner | Client registrar | Shows escalation path | | Hosting owner | Agency | Shows who can fix webroot issues | | CAA policy | Allows Let's Encrypt | Prevents CA mismatch | | Wildcard used | No | Flags DNS-01 requirements | | Renewal proof owner | Account manager | Connects technical status to client reporting |

This documentation is useful even if the host manages renewal automatically. "Managed" does not mean "unbreakable."

How 47-Day Pre-Flight helps agencies check readiness

47-Day Renewal Pre-Flight helps agencies review public readiness signals before renewal day: SSL expiry, DNS basics, CAA records, port 80 reachability, and HTTP-to-HTTPS behavior.

It does not decide which challenge type you should use. It helps you see which public conditions may make the current setup more fragile. If a site depends on HTTP-01 and port 80 is blocked, that is a readiness discussion. If a wildcard depends on DNS-01 and nobody owns DNS, that is an operations discussion.

Related 47-Day SSL Resources

• How to test if a host is truly ACME-ready
• Why ACME renewal fails on client websites
• Port 80 and ACME renewal
• CAA record check for client SSL renewals
• Monitor DNS changes across client websites

Frequently Asked Questions

What is the main difference between HTTP-01 and DNS-01?

HTTP-01 validates domain control through a public HTTP URL, while DNS-01 validates through a DNS TXT record. HTTP-01 depends on the web server, challenge path, redirects, and port 80 behavior. DNS-01 depends on DNS ownership, TXT record updates, propagation, and often DNS API access. For agencies, the difference is mostly operational: one method depends on web hosting control, the other depends on DNS control.

Is HTTP-01 vs DNS-01 mostly a Let's Encrypt question?

No. Let's Encrypt is a common ACME certificate authority, but HTTP-01 vs DNS-01 is an ACME validation choice, not only a Let's Encrypt choice. Many platforms hide the details behind managed SSL. Agencies should still document the validation dependency because the renewal failure path usually appears in hosting, DNS, CAA, CDN, or access control.

Can HTTP-01 work if HTTP redirects to HTTPS?

Yes, HTTP-01 can often work with HTTP-to-HTTPS redirects if the challenge request remains reachable and the redirect behavior is supported by the certificate authority. The problem is not redirecting by itself. The problem is blocking, intercepting, looping, or rewriting the challenge path so the expected token cannot be verified.

Do wildcard certificates require DNS-01?

Wildcard certificates generally require DNS-based validation. That means agencies need clear DNS ownership, reliable TXT record automation, and CAA alignment before renewal day. Wildcards can be useful, but they are not simpler just because one certificate covers many names. They move the renewal dependency toward DNS operations.

Which ACME challenge type is best for WordPress sites?

Many WordPress sites renew successfully with HTTP-01 through the host or control panel. That works when port 80 and the challenge path are reachable. DNS-01 may be better for wildcard certificates or locked-down environments, but it requires reliable DNS access. Agencies should check the actual host setup instead of applying one universal rule.

Does Pre-Flight tell me which challenge type a client uses?

Pre-Flight focuses on public readiness signals, not private ACME client configuration. It can help identify conditions that affect common renewal paths, such as CAA records, DNS basics, port 80 reachability, and HTTP behavior. To confirm the exact challenge type, check the hosting platform, ACME client configuration, or certificate automation logs.