4 ms·

A reminder that if you an internal-only server where the typical http-01 verification connection method will not work, one can use dns-01 by using DNS aliasing/

A reminder that if you an internal-only server where the typical http-01 verification connection method will not work, one can use dns-01 by using DNS aliasing/CNAME, especially if you cannot easily/dynamically update DNS records: * https://dan.langille.org/2019/02/01/acme-domain-alias-mode/ https://dan.langille.org/2019/02/01/acme-domain-alias-mode/ * https://www.eff.org/deeplinks/2018/02/technical-deep-dive-securing-automation-acme-dns-challenge-validation https://www.eff.org/deeplinks/2018/02/technical-deep-dive-se... So if you want a cert for www.internal.example.com, you will first have do a one-time change to have a _acme-challenge.www.internal… CNAME created to point to any other (sub-)domain where you can easily update things dynamically, e.g., www-internal.example-dnsapi.com. When request the cert for "www.internal…", LE/ACME will look up the corresponding _acme-challenge record, and go to "_acme-challenge.www-internal.example-dnsapi.com. The nonce token will be there in the 'final' destination following the CNAME in a TXT record, which shows LE/ACME that you control the DNS chain. To do the DNS updating, you can use a CLI/Python library like Lexicon, which supports dozens of APIs: * https://github.com/AnalogJ/lexicon https://github.com/AnalogJ/lexicon

ryandv 3y ago
One advantage of the DNS01 approach is that you can also order certificates for standby instances behind a load balancer, all fronted by the same domain name. Since the standbys are not serving traffic, you can't get an HTTP01 challenge/response through, but you can still do so with DNS01 and get a certificate delivered to that machine, so that it's always ready to serve TLS in the event of a failover.
JoshTriplett 3y ago
tls-alpn-01 woks really well as well. You don't have to mess with DNS at all, or have an HTTP port open; you just listen on HTTPS.
- throw0101d 3y ago
  Yeah, except for the the internal-only server part where the hostname may not even be accessible to the public Internet (certainly not as an A(AAA) record). And given the number of internal applications many large/r organizations have, giving all those internal dev teams update access to the main corporate domain is not something I'd really feel comfortable doing. But being able to give API access to (e.g.) foo.dnsauth.example.com is something I have done: main domain needs to be touched once for the CNAME, and the sub-domain isn't critical for day-to-day operations of a company.
  - JoshTriplett 3y ago
    The post I was replying to used www.internal.example.com , which looked like a public name. Internal-only names should not look like subdomains of public DNS names. But yes, if you want a certificate for a name that isn't accessible externally and can't be made accessible externally, dns-01 works.
    - throw0101d 3y ago
      > Internal-only names should not look like subdomains of public DNS names. Since when? I, and many other people I know, have been doing that for decades. If I (the company) own example.com, I can choose to have some sub-domains internal-only, some external-only, some DNS records resolve to the same IP value regardless of in/outside, and other DNS records resolve to different IP values depending on in/outside. * https://en.wikipedia.org/wiki/Split-horizon_DNS https://en.wikipedia.org/wiki/Split-horizon_DNS
    - p_l 3y ago
      However, internal domains should have their top domain externally registered and controlled... so ultimately there's no difference because you're going to need at least a dummy zone file to satisfy registrar.
      - JoshTriplett 3y ago
        > However, internal domains should have their top domain externally registered and controlled Not necessarily. `.internal` exists for that purpose, and people have historically used `.lan` for similar purposes. There's no particular reason internal names need to have resolvable DNS names of any kind, if they're not going to be externally accessible, unless you're trying to do something like dns-01.
        p_l 3y ago
        In my experience, you can and will encounter a situation with conflicting resolvings of .internal unless the use is all properly scoped to broadcast and administrative zones (ha ha ha fat chance, though respect to anyone who really tries). .lan, .home, and similar have the issue that they aren't actually reserved so they can conflict (see the land-grab of .dev that Google did after ICANN opened up TLDs). The one way that has most stability (and is best recommendation I have seen) is to have a publicly reserved zone, which doesn't need to have anything other than NS records pointing to hostnames visible from your internal networks (I am always tempted to have essentially NS -> AAAA + PTR pointing at anycast internal v6 address). Turns out it does not need to be separate domain from some other domain of yours, it can be let's say i.your-company-name.com. - I am partial to your-company-name.net. but that can be confusing for less computer crazy people.
diarrhea 3y ago
I own example.com and actually created NS records for internal.example.com, to manage that entire zone at an entirely different provider. I did that because the original provider had terrible API access for Caddy to use. The new one has better support, and a breach there does not pwn the root domain. I was happy with that setup, but wasn’t aware one could delegate to an entirely different domain using ACME primitives. Makes sense though, it’s like the NS approach but simpler, and allows using some throwaway domain. Thanks!

ryandv 3y ago

One advantage of the DNS01 approach is that you can also order certificates for standby instances behind a load balancer, all fronted by the same domain name. Since the standbys are not serving traffic, you can't get an HTTP01 challenge/response through, but you can still do so with DNS01 and get a certificate delivered to that machine, so that it's always ready to serve TLS in the event of a failover.

JoshTriplett 3y ago

tls-alpn-01 woks really well as well. You don't have to mess with DNS at all, or have an HTTP port open; you just listen on HTTPS.

throw0101d 3y ago
Yeah, except for the the internal-only server part where the hostname may not even be accessible to the public Internet (certainly not as an A(AAA) record). And given the number of internal applications many large/r organizations have, giving all those internal dev teams update access to the main corporate domain is not something I'd really feel comfortable doing. But being able to give API access to (e.g.) foo.dnsauth.example.com is something I have done: main domain needs to be touched once for the CNAME, and the sub-domain isn't critical for day-to-day operations of a company.
- JoshTriplett 3y ago
  The post I was replying to used www.internal.example.com , which looked like a public name. Internal-only names should not look like subdomains of public DNS names. But yes, if you want a certificate for a name that isn't accessible externally and can't be made accessible externally, dns-01 works.
  - throw0101d 3y ago
    > Internal-only names should not look like subdomains of public DNS names. Since when? I, and many other people I know, have been doing that for decades. If I (the company) own example.com, I can choose to have some sub-domains internal-only, some external-only, some DNS records resolve to the same IP value regardless of in/outside, and other DNS records resolve to different IP values depending on in/outside. * https://en.wikipedia.org/wiki/Split-horizon_DNS https://en.wikipedia.org/wiki/Split-horizon_DNS
  - p_l 3y ago
    However, internal domains should have their top domain externally registered and controlled... so ultimately there's no difference because you're going to need at least a dummy zone file to satisfy registrar.
    - JoshTriplett 3y ago
      > However, internal domains should have their top domain externally registered and controlled Not necessarily. `.internal` exists for that purpose, and people have historically used `.lan` for similar purposes. There's no particular reason internal names need to have resolvable DNS names of any kind, if they're not going to be externally accessible, unless you're trying to do something like dns-01.
      - p_l 3y ago
        In my experience, you can and will encounter a situation with conflicting resolvings of .internal unless the use is all properly scoped to broadcast and administrative zones (ha ha ha fat chance, though respect to anyone who really tries). .lan, .home, and similar have the issue that they aren't actually reserved so they can conflict (see the land-grab of .dev that Google did after ICANN opened up TLDs). The one way that has most stability (and is best recommendation I have seen) is to have a publicly reserved zone, which doesn't need to have anything other than NS records pointing to hostnames visible from your internal networks (I am always tempted to have essentially NS -> AAAA + PTR pointing at anycast internal v6 address). Turns out it does not need to be separate domain from some other domain of yours, it can be let's say i.your-company-name.com. - I am partial to your-company-name.net. but that can be confusing for less computer crazy people.

diarrhea 3y ago

I own example.com and actually created NS records for internal.example.com, to manage that entire zone at an entirely different provider. I did that because the original provider had terrible API access for Caddy to use. The new one has better support, and a breach there does not pwn the root domain. I was happy with that setup, but wasn’t aware one could delegate to an entirely different domain using ACME primitives. Makes sense though, it’s like the NS approach but simpler, and allows using some throwaway domain. Thanks!