My work is mostly running internal services that aren’t reachable from the external internet. DNS is the only option.

You can get wildcards with DNS. If you want *.foo.com, you just need to be able to set _acme-challenge.foo.com and you can get the wildcard.

Spivak is saying that the DNS method is superior (i.e you are agreeing - and I do too).

One reason I can think of for HTTP-01 / TLS-ALPN-01 is on-demand issuance, issuing the certificate when you get the request. Which might seem insane (and kinda is), but can be useful for e.g crazy web-migration projects. If you have an enormous, deeply levelled, domain sprawl that are almost never used but you need it up for some reason it can be quite handy.

(Another reason, soon, is that HTTP-01 will be able to issue certs for IP addresses: https://letsencrypt.org/2025/07/01/issuing-our-first-ip-addr...)

Oh I totally misread the comment.

Nevermind, I agree!

The comment is strangely worded, I too had to read it over a couple of times to understand what they meant.

> DNS is the only option

DNS and wildcards aren't the only options. I've done annoying hacks to give internal services an HTTPS cert without using either.

But they're the only sane options.

One problem with wildcards is that any service with *.foo.com can pretend to be any other service. This is an issue if you're using mutual TLS authentication and want to trust the server's certificate.

It'd be nice if LE could issue intermediary certificates constrained to a specific domain ( https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.... ).

The advantage to HTTP validation is that it's simple. No messing with DNS or API keys. Just fire up your server software and tell it what your hostname is and everything else happens in the background automagically.

And you have two or more servers serving this domain you’re out of luck

And this is different from DNS how exactly? The key and resulting cert still needs to be distributed among your servers no matter which method is used.

With dns-01, multiple servers could, independently of each other, fetch a certificate for the same set of hostnames. Not sure if it’s a good idea though.

Multiple keys and certs for the same hostname? Will the CA even issue that?

I guess it depends on the CA, but some do. Let’s Encrypt does, for example. I guess it’s useful for HA deployments, where load balancers might be spread out across multiple datacenters and stuff like that.

NB that rate limits apply https://letsencrypt.org/docs/rate-limits/

Not really, just forward .well-known/acme-challenge/* requests to a single server or otherwise make sure that the challenge responses are served from all instances.

If you buy your domain with a bottom-of-the-barrel domain reseller and then not pay for decent DNS, you don't have the option.

Plus, it takes setting up an API key and most of the time you don't need a wildcard anyway.

You don't need API access to your DNS, the ability to delegate the ACME challenge records to your own server is also enough.

I don't know how to make my server log into my DNS, and I don't particularly want to learn how. Mapping .well-known is one line of config.

Wildcards are the only temptation.

Just like you can point .well-known/acme-challenge/ to a writable directory you can also delegate the relevant DNS keys to a name server that you can more easily update.

Now you want me to rent or install at least two name servers, and then configure them, and then teach my web server how to send them rules?

That's so much more work than either of the options in my first comment. Aliasing a directory takes about one minute.

> I've found it to be annoying and brittle

How so? It's just serving static files.