3 ms·

If they insist on keeping the three month limit I wish they'd come up with some better ways to allow you to secure your server. If you want to use the www auth

by cube00 5y ago

If they insist on keeping the three month limit I wish they'd come up with some better ways to allow you to secure your server. If you want to use the www auth you need to allow outbound connections to any IP (they specifically won't release the range they use), otherwise you have the DNS option which means giving the server access to modify the DNS records which is also unsafe should the box get compromised.

magicalhippo 5y ago
With the DNS option the machine doing the request doesn't have to be the machine using the certificate though. I have a separate machine doing the DNS challenge and the cert is then distributed to the machine needing it. Technically true for the regular web challenge, but easier with DNS I think.
- mimimi31 5y ago
  This is what I do as well. I have set up acme.sh[1] on a Raspberry Pi on my home network, which isn't accessible from the outside. It is triggered every night by a systemd timer and renews (using the DNS challenge) and deploys all expiring certificates. [1] https://github.com/acmesh-official/acme.sh https://github.com/acmesh-official/acme.sh
- larntz 5y ago
  I'm doing the same for my personal/home lab stuff. I've been using https://github.com/joohoi/acme-dns https://github.com/joohoi/acme-dns for the dns server running on a small vps for all my internal certificates and I haven't had any issues with it.
throw0101a 5y ago
> If you want to use the www auth you need to allow outbound connections to any IP Only for the time period when you're requesting the cert though: it does not have to be open to the entire Internet 24/7. While this may not satisfy your personal / particular level of security concern, but it is something worth keeping in mind. Using the dehydrated client as an example, the web server could be started and stopped (or the host's firewall rules altered) in the startup_hook() / exit_hook() functions, or the deploy_challenge() / clean_challenge() functions: * https://github.com/dehydrated-io/dehydrated/blob/master/docs/examples/hook.sh https://github.com/dehydrated-io/dehydrated/blob/master/docs... > otherwise you have the DNS option which means giving the server access to modify the DNS records which is also unsafe should the box get compromised. Are you aware of LE/ACME's "DNS alias" mode? * https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mode https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mo... * 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... Let us say you want to get a cert for foo.example.com. Letting an ACME client change the value of that could be a risk, as you state. So what you can do is (manually) create a CNAME _acme-challenge.foo.example.com, and point that elsewhere, like _acme-challenge.foo.dnsauth.example.com. You then allow the ACME client to alter (just) the TXT records of _acme-challenge.foo.dnsauth. People have even written simple DNS server that allow for updating of records via a RESTful API, so you can server just the (e.g.) dnsauth sub-domain from it, leaving your main domain untouched (besides the initial CNAME addition): * https://github.com/joohoi/acme-dns https://github.com/joohoi/acme-dns There's also a CLI utility that can handle access the APIs of several dozen DNS companies so you don't have to roll your own if you want to server the sub-domain from your current provider: * https://github.com/AnalogJ/lexicon https://github.com/AnalogJ/lexicon And you don't have to use a sub-domain, but something else entirely too: instead of dnsauth.example.com you can point the CNAME to example-dnsauth.com or example.org. So if your primary DNS provider doesn't have an API, you can use another one that does. The destination CNAME does not matter as long as you control and can update it.
codetrotter 5y ago
> otherwise you have the DNS option which means giving the server access to modify the DNS records which is also unsafe should the box get compromised This is true, but the machine doing DNS modifications doesn't need to be accessible to any outside initiated connections at all. So if someone has the capacity to compromise such a computer, what would stop them from compromising your desktop computer or your laptop instead? But either way it would indeed be nice to have further limits on what the box could do. But I think LetsEncrypt does not need to change anything to make this possible. https://letsencrypt.org/docs/challenge-types/ https://letsencrypt.org/docs/challenge-types/ The DNS verification works by creating a DNS TXT record named "_acme-challenge" with a TXT value on the domain you are verifying. So really what you want is for your DNS provider to implement into their API access keys that can be restricted so that the absolutely only thing the key is allowed to do is to create, change and delete the DNS TXT record named "_acme-challenge". Perhaps some DNS providers already make this possible? But the one I am using is only able to limit it to a ZONE, but not to a specific record type and not to a specific label. In fact I wish CloudFlare would allow such specific fine-grained permissions. But even if they did they'd probably make it part of the Enterprise plan and I am still not an Enterprise customer so. Edit: Meanwhile that I was writing this someone else posted a sibling comment about ACME DNS alias mode, which I had not heard of. https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mode https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mo... That's very close to good enough. Though it would still be nice if DNS providers made it possible to issue API access tokens that are limited to specific record type and specific label.
- adambatkin 5y ago
  I do the challenge verification using DNS and Route 53, and the process has permission to update the challenge record and nothing else. So what you are describing is definitely possible.
  - akerl_ 5y ago
    I looked into this previously and was unhappy to learn that Route53 doesn’t allow permissions based on specific records. The most granular permissions were for a full zone at the time.

by cube00 5y ago

magicalhippo 5y ago

With the DNS option the machine doing the request doesn't have to be the machine using the certificate though. I have a separate machine doing the DNS challenge and the cert is then distributed to the machine needing it. Technically true for the regular web challenge, but easier with DNS I think.

mimimi31 5y ago
This is what I do as well. I have set up acme.sh[1] on a Raspberry Pi on my home network, which isn't accessible from the outside. It is triggered every night by a systemd timer and renews (using the DNS challenge) and deploys all expiring certificates. [1] https://github.com/acmesh-official/acme.sh https://github.com/acmesh-official/acme.sh
larntz 5y ago
I'm doing the same for my personal/home lab stuff. I've been using https://github.com/joohoi/acme-dns https://github.com/joohoi/acme-dns for the dns server running on a small vps for all my internal certificates and I haven't had any issues with it.

throw0101a 5y ago

> If you want to use the www auth you need to allow outbound connections to any IP Only for the time period when you're requesting the cert though: it does not have to be open to the entire Internet 24/7. While this may not satisfy your personal / particular level of security concern, but it is something worth keeping in mind. Using the dehydrated client as an example, the web server could be started and stopped (or the host's firewall rules altered) in the startup_hook() / exit_hook() functions, or the deploy_challenge() / clean_challenge() functions: * https://github.com/dehydrated-io/dehydrated/blob/master/docs/examples/hook.sh https://github.com/dehydrated-io/dehydrated/blob/master/docs... > otherwise you have the DNS option which means giving the server access to modify the DNS records which is also unsafe should the box get compromised. Are you aware of LE/ACME's "DNS alias" mode? * https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mode https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mo... * 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... Let us say you want to get a cert for foo.example.com. Letting an ACME client change the value of that could be a risk, as you state. So what you can do is (manually) create a CNAME _acme-challenge.foo.example.com, and point that elsewhere, like _acme-challenge.foo.dnsauth.example.com. You then allow the ACME client to alter (just) the TXT records of _acme-challenge.foo.dnsauth. People have even written simple DNS server that allow for updating of records via a RESTful API, so you can server just the (e.g.) dnsauth sub-domain from it, leaving your main domain untouched (besides the initial CNAME addition): * https://github.com/joohoi/acme-dns https://github.com/joohoi/acme-dns There's also a CLI utility that can handle access the APIs of several dozen DNS companies so you don't have to roll your own if you want to server the sub-domain from your current provider: * https://github.com/AnalogJ/lexicon https://github.com/AnalogJ/lexicon And you don't have to use a sub-domain, but something else entirely too: instead of dnsauth.example.com you can point the CNAME to example-dnsauth.com or example.org. So if your primary DNS provider doesn't have an API, you can use another one that does. The destination CNAME does not matter as long as you control and can update it.

codetrotter 5y ago

> otherwise you have the DNS option which means giving the server access to modify the DNS records which is also unsafe should the box get compromised This is true, but the machine doing DNS modifications doesn't need to be accessible to any outside initiated connections at all. So if someone has the capacity to compromise such a computer, what would stop them from compromising your desktop computer or your laptop instead? But either way it would indeed be nice to have further limits on what the box could do. But I think LetsEncrypt does not need to change anything to make this possible. https://letsencrypt.org/docs/challenge-types/ https://letsencrypt.org/docs/challenge-types/ The DNS verification works by creating a DNS TXT record named "_acme-challenge" with a TXT value on the domain you are verifying. So really what you want is for your DNS provider to implement into their API access keys that can be restricted so that the absolutely only thing the key is allowed to do is to create, change and delete the DNS TXT record named "_acme-challenge". Perhaps some DNS providers already make this possible? But the one I am using is only able to limit it to a ZONE, but not to a specific record type and not to a specific label. In fact I wish CloudFlare would allow such specific fine-grained permissions. But even if they did they'd probably make it part of the Enterprise plan and I am still not an Enterprise customer so. Edit: Meanwhile that I was writing this someone else posted a sibling comment about ACME DNS alias mode, which I had not heard of. https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mode https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mo... That's very close to good enough. Though it would still be nice if DNS providers made it possible to issue API access tokens that are limited to specific record type and specific label.

adambatkin 5y ago
I do the challenge verification using DNS and Route 53, and the process has permission to update the challenge record and nothing else. So what you are describing is definitely possible.
- akerl_ 5y ago
  I looked into this previously and was unhappy to learn that Route53 doesn’t allow permissions based on specific records. The most granular permissions were for a full zone at the time.