HTTP-01 vs DNS-01: Risk framing for orchestrated ACME

When orchestrating Let's Encrypt or any other ACME-based Certificate Authority (CA) across a large fleet, engineers eventually face a fundamental choice: HTTP-01 or DNS-01 validation. While both methods prove control over a domain, they require different access patterns, create different security perimeters, and carry vastly different risk profiles.

In this post, we break down how to frame these risks—especially when automating certificates in enterprise or multi-tenant environments.

The Allure (and Danger) of DNS-01

DNS-01 validation involves creating a temporary TXT record to prove domain control. Its primary advantage is that it doesn't require a web server to be reachable from the public internet on port 80. It is also the only ACME challenge type that supports issuing wildcard certificates (e.g., *.example.com).

However, this convenience comes at a steep security cost.

The "Keys to the Kingdom" Problem

To automate DNS-01, your ACME client needs API credentials capable of modifying your DNS zones. In many cloud providers (like Route53 or Cloudflare), restricting an API token to only write _acme-challenge TXT records is complex or impossible.

If an edge server running an ACME client is compromised, the attacker may extract those DNS API keys. Suddenly, a compromised web server escalates into total DNS hijacking, allowing attackers to route traffic to malicious endpoints or intercept emails.

The Case for Orchestrated HTTP-01

HTTP-01 validation proves control by placing a specific token in a well-known path (/.well-known/acme-challenge/) on the web server answering for the domain.

Security Through Narrow Scope

HTTP-01 validation is inherently scoped to the exact hostname being validated. If an attacker compromises the server hosting api.example.com, they can only impact api.example.com. They do not gain the ability to issue certificates for billing.example.com or alter DNS records.

Enterprise Egress and Port 80

A common objection to HTTP-01 is the requirement that port 80 be open to the public internet. However, modern certificate lifecycle management platforms (like Certinite) handle this elegantly:

1. Outbound-Only Agents: The agent running on the server only needs outbound access to the control plane.
2. Minimal Inbound Risk: While the public CA must reach port 80 to read the validation file, you are not opening a management port. You are simply allowing HTTP traffic to your web server—which is usually its primary function anyway. All validation requests can be strictly routed to the /.well-known/acme-challenge/ path.

Making the Right Choice

At Certinite, we advocate for orchestrated HTTP-01 as the default for most enterprise deployments. By separating the control plane from the edge node, you avoid spraying powerful DNS API keys across your infrastructure.

When to use DNS-01:

• You absolutely require wildcard certificates.
• The endpoints are purely internal and cannot be reached by a public CA, even on a specific path.
• Crucially: You have the capability to strictly limit the scope of the DNS API tokens used by the automation process.

When to use HTTP-01:

• You are automating standard, fully qualified domain names (FQDNs).
• You want to strictly limit the blast radius of any potential server compromise.
• You prefer not to manage, rotate, and secure DNS API credentials across multiple environments.

By understanding the distinct risk profiles of each validation method, platform teams can design certificate automation that is both reliable and structurally secure.