3 ms·

I have my certs issued to a VM this is not accessible via HTTP(S) anyway, just DNS. It runs a small DNS server which answers to _acme-challenge.* requests "forw

I have my certs issued to a VM this is not accessible via HTTP(S) anyway, just DNS. It runs a small DNS server which answers to _acme-challenge.* requests "forwarded" via CNAME. As that is the only part of is visible to the rest it has a very small security surface to worry about. It then pushes out the keys & certs to the places that need them (directly in the case of local machines, less directly for some others). I set that up originally for a wildcard, as http validation is not supported for them and I didn't fancy mucking about automating updating the main bind instances, but it is convenient for the others too and will be unaffected by these changes. Not a perfect solution for everyone of course, copies of all the keys are in one place for one thing, and it all in one place could be bad or good for maintenance (single point of failure, but single service to monitor & maintain), but worth considering if you expect problems with http validation. > some countries and their IP ranges just need not access my server I'm guessing that they won't be using locations that are commonly blocked in this way anyway. And if they do happen to use one, you may be fine as only two of the three external checks need to be responded to.

nomercy400 7y ago
I've read about this a few times now, but have been unable to find a good resource on how to set such a VM up. Do you have a link or resource somewhere so that I can at least get started? Still unexperienced with letsencrypt, but I know enough that I cannot use the standard way.
- movedx 7y ago
  I think what they're doing here is running a DNS server on a VM that only answers to requests for specific ACME address prefixes. Then at the actual domain, say example.com, they may ask for cool.example.com but it's a CNAME record that directs to something the DNS server is authority over, say xyz.io or something along those lines. Therefore ACME's DNS request for checking via DNS validation is validated directly by the tiny DNS server due to the CNAME record directing traffic to it. I've never done this my self neither, but I think it would be along those lines.
- throw0101a 7y ago
  > I've read about this a few times now, but have been unable to find a good resource on how to set such a VM up. You first set up a VM and set up your favourite authoritative DNS software on it: popular choices are ISC's BIND and NLnet's NSD. Either will do. Call it (e.g.) ns-dnsauth.mydomain.com, which is Internet accessible only on udp/53 and tcp/53. You have to then configure that DNS server to serve the domain (e.g.) dnsauth.mydomain.com. Next you configure the DNS server software to allow dynamic updates. For ISC BIND, you can set up (crypto) keys and use the nsupdate(1) utility: * https://www.zytrax.com/books/dns/ch7/xfer.html#allow-update https://www.zytrax.com/books/dns/ch7/xfer.html#allow-update * https://dan.langille.org/2017/05/31/creating-a-txt-only-nsupdate-connection-for-lets-encrypt/ https://dan.langille.org/2017/05/31/creating-a-txt-only-nsup... Point your public/external DNS records to your delegated-auth server by having (say) _acme-challenge.www.mydomain.com be a CNAME to (say) _acme-challenge.www.dnsauth.... LE will follow the CNAME and try to do the verification against the record in dnsauth sub-domain that lives on the ns-dnsauth VM. Then you have your LE/ACME client(s) run a hook script to publish (and cleanup) the dns-01 TXT challenge records: * https://dan.langille.org/2017/07/04/acme-sh-getting-free-ssl-certificates-installation-configuration-on-freebsd/ https://dan.langille.org/2017/07/04/acme-sh-getting-free-ssl... * https://github.com/dehydrated-io/dehydrated/wiki/example-dns-01-nsupdate-script https://github.com/dehydrated-io/dehydrated/wiki/example-dns... The LE client goes to the LE API, gets a verification token/nonce, executes the the hook script to push the TXT record to ns-dnsauth, the LE folks verify the record, the LE client (ideally) cleans up the TXT record, receives the cert for the LE API, puts it in the correct path and restarts your (web) service(s). Someone actually wrote a limited-functionality DNS server that allows for pushing of records via a REST API for this purpose: * https://github.com/joohoi/acme-dns https://github.com/joohoi/acme-dns This way the 'heavier' BIND/NSD software doesn't have to be used, as those have more features than are needed.
  - anonsivalley652 7y ago
    For publicly-accessible infrastructure: 4-6 instances of pdns authoritative for a domain, and pdns recursor running locally for each box. And Cloudflare free tier while revenue can't justify rolling-out Varnish and other locally-deployed capacity/DDoS mitigations. It may also be a better idea to push DNS updates via configuration management or driven from something like Envoy so there's a history and a single-source-of-truth (SSOT) to point-to rather than multiple people doing manual tinkering, which is a labor-intensive, antiquated approach.
- dspillett 7y ago
  There are a fair few examples out there for hooking acme-dns in as the DNS server with the standard certbot tool. SO search for acme-dns for more info. Though that isn't actually how I do it (I'm using dehydrated with my own hook script to update a bind9 instance) but probably would be if I started again from scratch.
blattimwind 7y ago
You don't even need the DNS to be local and expose anything at all to the internet. You can just as well push the TXT records to your usual DNS through your registrar's API. This generally just works.
- cm2187 7y ago
  Agree. Though I would rather state it "just" works. You need to watch for DNS propagation, particularly if your DNS provider has some sort of CDN-like features (which is the case for instance of OVH) which makes the timing of the propagation non deterministic and non observable (you will likely be served by a different DNS server than the let's encrypt bot, how can you check it has propagated?). Let's encrypt will only check the DNS entry once, if it doesn't find it, it fails the authentication process and doesn't retry (contrary to the specs).
- dspillett 7y ago
  I still run my own DNS servers, so for me "your registrar's API" is directly poking bind and I only have myself to blame if anything goes wrong! Keeping the little DNS service for the certs means if I break that the rest stays sane. I also don't have to worry about delays transferring changes to zones if there are any intermittent network issues.

nomercy400 7y ago

I've read about this a few times now, but have been unable to find a good resource on how to set such a VM up. Do you have a link or resource somewhere so that I can at least get started? Still unexperienced with letsencrypt, but I know enough that I cannot use the standard way.

movedx 7y ago
I think what they're doing here is running a DNS server on a VM that only answers to requests for specific ACME address prefixes. Then at the actual domain, say example.com, they may ask for cool.example.com but it's a CNAME record that directs to something the DNS server is authority over, say xyz.io or something along those lines. Therefore ACME's DNS request for checking via DNS validation is validated directly by the tiny DNS server due to the CNAME record directing traffic to it. I've never done this my self neither, but I think it would be along those lines.
throw0101a 7y ago
> I've read about this a few times now, but have been unable to find a good resource on how to set such a VM up. You first set up a VM and set up your favourite authoritative DNS software on it: popular choices are ISC's BIND and NLnet's NSD. Either will do. Call it (e.g.) ns-dnsauth.mydomain.com, which is Internet accessible only on udp/53 and tcp/53. You have to then configure that DNS server to serve the domain (e.g.) dnsauth.mydomain.com. Next you configure the DNS server software to allow dynamic updates. For ISC BIND, you can set up (crypto) keys and use the nsupdate(1) utility: * https://www.zytrax.com/books/dns/ch7/xfer.html#allow-update https://www.zytrax.com/books/dns/ch7/xfer.html#allow-update * https://dan.langille.org/2017/05/31/creating-a-txt-only-nsupdate-connection-for-lets-encrypt/ https://dan.langille.org/2017/05/31/creating-a-txt-only-nsup... Point your public/external DNS records to your delegated-auth server by having (say) _acme-challenge.www.mydomain.com be a CNAME to (say) _acme-challenge.www.dnsauth.... LE will follow the CNAME and try to do the verification against the record in dnsauth sub-domain that lives on the ns-dnsauth VM. Then you have your LE/ACME client(s) run a hook script to publish (and cleanup) the dns-01 TXT challenge records: * https://dan.langille.org/2017/07/04/acme-sh-getting-free-ssl-certificates-installation-configuration-on-freebsd/ https://dan.langille.org/2017/07/04/acme-sh-getting-free-ssl... * https://github.com/dehydrated-io/dehydrated/wiki/example-dns-01-nsupdate-script https://github.com/dehydrated-io/dehydrated/wiki/example-dns... The LE client goes to the LE API, gets a verification token/nonce, executes the the hook script to push the TXT record to ns-dnsauth, the LE folks verify the record, the LE client (ideally) cleans up the TXT record, receives the cert for the LE API, puts it in the correct path and restarts your (web) service(s). Someone actually wrote a limited-functionality DNS server that allows for pushing of records via a REST API for this purpose: * https://github.com/joohoi/acme-dns https://github.com/joohoi/acme-dns This way the 'heavier' BIND/NSD software doesn't have to be used, as those have more features than are needed.
- anonsivalley652 7y ago
  For publicly-accessible infrastructure: 4-6 instances of pdns authoritative for a domain, and pdns recursor running locally for each box. And Cloudflare free tier while revenue can't justify rolling-out Varnish and other locally-deployed capacity/DDoS mitigations. It may also be a better idea to push DNS updates via configuration management or driven from something like Envoy so there's a history and a single-source-of-truth (SSOT) to point-to rather than multiple people doing manual tinkering, which is a labor-intensive, antiquated approach.
dspillett 7y ago
There are a fair few examples out there for hooking acme-dns in as the DNS server with the standard certbot tool. SO search for acme-dns for more info. Though that isn't actually how I do it (I'm using dehydrated with my own hook script to update a bind9 instance) but probably would be if I started again from scratch.

blattimwind 7y ago

You don't even need the DNS to be local and expose anything at all to the internet. You can just as well push the TXT records to your usual DNS through your registrar's API. This generally just works.

cm2187 7y ago
Agree. Though I would rather state it "just" works. You need to watch for DNS propagation, particularly if your DNS provider has some sort of CDN-like features (which is the case for instance of OVH) which makes the timing of the propagation non deterministic and non observable (you will likely be served by a different DNS server than the let's encrypt bot, how can you check it has propagated?). Let's encrypt will only check the DNS entry once, if it doesn't find it, it fails the authentication process and doesn't retry (contrary to the specs).
dspillett 7y ago
I still run my own DNS servers, so for me "your registrar's API" is directly poking bind and I only have myself to blame if anything goes wrong! Keeping the little DNS service for the certs means if I break that the rest stays sane. I also don't have to worry about delays transferring changes to zones if there are any intermittent network issues.