What are the ACME Challenges for Domain Validation? Which One Should You Use?

Your SSL pipeline breaks at 2 am… does this sound like you? Nothing was going wrong at all. Certificates were issued. Renewals were automated. You felt confident.

And your page gives a certificate warning.

Now you’re scrambling and checking logs. Restarting services and asking yourself why some automatic thing just went wrong.

ACME isn’t the problem. Domain validation is.

The protocol actually does what it is expected to do. What is really wrong is that, using HTTP, DNS, or TLS challenges, your system demonstrates domain ownership.

It is there that things fall apart:

• Maybe your server isn’t reachable on port 80.
• Maybe your DNS record didn’t propagate in time.
• Maybe your reverse proxy or load balancer is interfering with validation requests.

These are not large and glaring errors. They are minor maladjustments that result in colossal breakdowns.

And here’s the bigger problem:

The majority of developers do not select an ACME challenge; they are given one.

They follow a quick guide. Get it working once. Hopefully, it will continue working.

What is ACME?

ACME is just a protocol that automates SSL certificate issuance and renewal. That’s it.

Instead of manually generating CSRs, uploading files, verifying domains, downloading certificates, and installing them again and again…

ACME does all of that for you. Automatically. No human intervention. No repetitive steps. No expiry surprises if it’s set up correctly.

Why is Manual SSL basically dead?

There was a time when managing SSL certificates was a manual process. You’d:

• Generate a key
• Submit a request
• Prove domain ownership
• Install the certificate
• Set a reminder to renew it

And repeat this every few months. It was slow. Error-prone. And honestly, not scalable.

Now imagine doing that across:

• 10 domains
• 50 microservices
• Multiple environments (dev, staging, prod)

It breaks instantly. That’s why automation isn’t optional anymore.

Where ACME Fits?

You are already relying on automation everywhere by working in modern infrastructure.

• CI/CD pipelines are automatic code.
• Resources in cloud platforms are automatically scaled.
• Containers automatically spin down and up.

Why then should SSL still be manual? It doesn’t make sense.

The ecosystem that ACME fits best into is:

• It is deployed in your pipelines.
• Work compatible with cloud environments.
• Promotes dynamic infrastructure such as containers and Kubernetes.

The catch and why this blog exists

ACME makes things easy, but only up to a point.

Because underneath that automation is one critical step:

Domain validation. And that’s where most setups fail. So if you understand ACME but don’t understand validation…

You’re building on shaky ground.

The Real Problem: Domain Validation is the Bottleneck

ACME itself? Easy. You install a client, run a command, and it should just work.

But in reality, that’s not where things fail. The real bottleneck is domain validation.

What is the Point of Validation?

There must be a single, simple question that the system must answer before any certificate is issued; the question is: Do you actually control this domain?

Since anybody may ask to have a certificate for any domain…

That would be a security fiasco. Hackers would be able to imitate sites, intercept traffic, and utterly betray trust on the internet. There is a verification step, therefore. You have to prove ownership.

The validation appears to be simple; however, in reality, it is where the majority of the setups fail. Why?

Modern infrastructure is no longer that straightforward. You might be dealing with:

• Reverse proxies
• Load balancers
• Firewalls blocking ports
• Distributed systems
• DNS delays

All of a sudden, that routine confirmation procedure turns out to be uncontrollable. And in the case of validation failure, there is no certificate, there is no HTTPS, there is no trust.

The 2 methods that ACME can use to Verify your Domain

ACME provides you with three ways of proving ownership to solve this.

Each one works differently:

• HTTP-01 – Demonstrate ownership by serving a file on HTTP.
• DNS-01 – Demonstrate ownership by means of a DNS record.

What is HTTP-01 Challenge?

This is likely to be the most common method you will use the first time you are working with ACME. And for good reason. It is the easiest of them to comprehend.

How does it Work?

It is a simple process.

Your ACME client flips up a small verification file and drops it on your server, often in some path such as:

http://yourdomain.com/.well-known/acme-challenge/…

The validation server will then request that URL.

Is it able to open the file, and is the information the same? You’re verified. No complexity. Just serving a file over HTTP.

This approach is most effective in situations where your system is bare-bones and can be anticipated:

• Single-server applications
• Minimal sites with Nginx or Apache.
• Shearwaters with port 80 are open and accessible.

When you are in direct control of the web server, then HTTP-01 is almost painless.

Why people love it (Pros)

• Simple Installation – The majority of clients of ACME do everything automatically.
• None of the DNS Access is necessary – No API keys or DNS automation.
• Quick Validation – No time loss on DNS propagation.

Where it starts Breaking (Cons)

• No Wildcard Support –  You are not able to issue certificates to the name of .yourdomain.com.
• Port Required –  In case port 80 is closed, port 80 is redirected or blocked, or port 80 is filtered, you are stuck.
• Breaks in Complicated Configurations – Load balancers, CDNs, and reverse proxies may cause breaks to the validation path.

Nginx Example

Here’s what this typically looks like in a basic setup:

server {
    listen 80;
    server_name yourdomain.com;

    location /.well-known/acme-challenge/ {
        root /var/www/acme;
    }
}

Your ACME client drops the validation file into /var/www/acme, and your server makes it publicly accessible. That’s enough to pass the challenge.

What is the DNS-01 Challenge?

In case HTTP-01 is the one that can be used by beginners… It is serious at DNS-01. This is what the professionals use when they require flexibility, scalability, and control.

How does it Work?

You do not put a file on your server, but demonstrate its ownership at the DNS level. The TXT record of your ACME client is as follows:

_yourdomain.com/acme-challenge = some-random-token

The validation system tests your DNS. And does that record exist, and agreeableness? You’re verified. You do not even need your web server.

Who Uses This?

You do this when your arrangement is no longer easy:

• Bare name certificates (.yourdomain.com)
• Cloud-native environments
• Kubernetes clusters
• Distributed systems or multi-server.

DNNS-01 is a perfect fit if you have a dynamic infrastructure.

Why it’s Powerful (Pros)

• Works Anonymously: You do not need port 80 or open HTTP.
• Allows Wildcard Domains: A single certificate may cover an infinite number of subdomains.
• Made to Order: Cross-container, load balancers, and microservices work.

It is the reason why the majority of DevOps teams degenerate to DNS-01.

Where it gets tricky (Cons)

It is quite strong and not smooth.

• Needs DNS Automation: TXT records cannot be added manually.
• DNS Propagation Time: Sometimes it takes seconds… sometimes even minutes.
• API Access required: You will require your DNS provider credentials.

Yes, it makes it more complicated; however, it is worth it.

DNS-01 isn’t the easiest option. However, it is the most scalable, flexible and future-proof.

When you are dealing with cloud infrastructure, containers, and more than just a basic server. This is the way that you will find yourself using.

Head-to-Head Comparison

Because at the end of the day, this comes down to one decision: HTTP-01 or DNS-01? Here’s the side-by-side breakdown that actually matters.

Factor	HTTP-01	DNS-01
Ease of Setup	Very Easy	Moderate
Automation	Basic	Fully Automatable
Wildcard Support	No	Yes
Security	Medium (HTTP exposure)	High (DNS-based validation)
Port Requirement	Port 80 required	None
Best Use Case	Simple websites	Cloud / DevOps / Kubernetes

The insight most people miss

People don’t run into problems because ACME is complicated.

They run into problems because they choose convenience over compatibility.

HTTP-01 feels easy in the beginning… Until:

• Your app moves behind a load balancer
• Port 80 gets blocked
• You need wildcard certificates

And suddenly, that “easy” setup becomes fragile.

The Shortcut Decision:

If you don’t want to overthink it, use this:

Running a simple site on a single server? → HTTP-01

Running anything cloud-based, automated, or scalable? → DNS-01

Which ACME Challenge Should You Choose?

Use this quick decision tree, and you’ll know exactly what to pick:

Are you running a simple website on a single server?

→ Go with HTTP-01

→ It’s fast, easy, and requires minimal setup

Are you working with cloud, containers, or automation (DevOps setup)?

→ Go with DNS-01

→ It scales, supports wildcard certificates, and works across distributed systems

Do you need wildcard certificates (*.domain.com)?

→ You only have one real option: DNS-01

Do you want long-term stability with zero manual intervention?

→ Choose DNS-01 with automation (API-based DNS)

Common Mistakes That Break ACME Validation

Most ACME failures don’t happen because something is completely broken. They happen because of small, easy-to-miss mistakes.

And those small mistakes? They’re exactly what takes your HTTPS down at the worst possible time.

Port 80 is blocked

This is the #1 reason HTTP-01 fails. Your server might be running perfectly…

But if port 80 isn’t publicly accessible, validation will fail instantly.

What causes it:

• Cloud security groups blocking port 80
• Firewalls (UFW, iptables)
• ISP restrictions

How to fix it:

• Open port 80 in your firewall/security group
• Verify access:
  curl http://yourdomain.com
• Make sure traffic actually reaches your server. If you can’t open port 80, don’t fight it, switch to DNS-01.

DNS Propagation Delays

You added the TXT record. Everything looks correct. But validation still fails. Why?

DNS hasn’t propagated yet

What causes it:

• TTL values
• Slow DNS providers
• Cached records

How to fix it:

• Check propagation:
  dig TXT _acme-challenge.yourdomain.com
• Use global checkers (multiple regions)
• Lower TTL before automation (if possible)
• Add retry/wait logic in your automation

Summary

ACME is simple. Choosing the right validation method isn’t.

• HTTP-01 → easy, but limited
• DNS-01 → powerful, scalable, future-proof

If you’re working with modern infrastructure, DNS-01 is the safer long-term choice.

Need Help Setting This Up? We help teams implement reliable ACME automation solutions. Contact us to purchase and set up enterprise-grade SSL automation tailored to your infrastructure.