4 ms·

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 wa

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.

bryanlarsen 1y ago
> 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.
deleted 1y ago
[deleted]
filleokus 1y ago
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-address-certificate https://letsencrypt.org/2025/07/01/issuing-our-first-ip-addr...)
- cortesoft 1y ago
  Oh I totally misread the comment. Nevermind, I agree!
  - Sharparam 1y ago
    The comment is strangely worded, I too had to read it over a couple of times to understand what they meant.
cyberax 1y ago
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.10 https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.... ).

bryanlarsen 1y ago

> 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.

deleted 1y ago

[deleted]

filleokus 1y ago

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-address-certificate https://letsencrypt.org/2025/07/01/issuing-our-first-ip-addr...)

cortesoft 1y ago
Oh I totally misread the comment. Nevermind, I agree!
- Sharparam 1y ago
  The comment is strangely worded, I too had to read it over a couple of times to understand what they meant.

cyberax 1y ago

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.10 https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.... ).