▲ | cortesoft 2 days ago | ||||||||||||||||
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. | |||||||||||||||||
▲ | filleokus 2 days ago | parent | next [-] | ||||||||||||||||
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...) | |||||||||||||||||
| |||||||||||||||||
▲ | bryanlarsen 2 days ago | parent | prev | next [-] | ||||||||||||||||
> 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. | |||||||||||||||||
▲ | cyberax 2 days ago | parent | prev | next [-] | ||||||||||||||||
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.... ). | |||||||||||||||||
▲ | 2 days ago | parent | prev [-] | ||||||||||||||||
[deleted] |