Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
acme-dns
Limited DNS server with RESTful HTTP API to handle ACME DNS challenges easily and securely.
-
dehydrated-bigip-ansible
Ansible based hooks for dehydrated to enable ACME certificate automation for F5 BIG-IP systems
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
letsencrypt
Certbot is EFF's tool to obtain certs from Let's Encrypt and (optionally) auto-enable HTTPS on your server. It can also act as a client for any other CA that uses the ACME protocol.
-
> 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 not satisfy your personal / particular level of security concern, it is something. 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...
> 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-mo...
* https://www.eff.org/deeplinks/2018/02/technical-deep-dive-se...
Let us say you with 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 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 ever 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:
* 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:
* https://github.com/AnalogJ/lexicon
> 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 not satisfy your personal / particular level of security concern, it is something. 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...
> 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-mo...
* https://www.eff.org/deeplinks/2018/02/technical-deep-dive-se...
Let us say you with 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 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 ever 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:
* 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:
* https://github.com/AnalogJ/lexicon
> 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 not satisfy your personal / particular level of security concern, it is something. 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...
> 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-mo...
* https://www.eff.org/deeplinks/2018/02/technical-deep-dive-se...
Let us say you with 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 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 ever 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:
* 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:
* https://github.com/AnalogJ/lexicon
> I'm using the acme.sh client but the process will be similar no matter which client you choose to use.
Always nice to see some variety in clients along side the official Let's Encrypt one.
While we do use the official Python-based client at works at times, whenever I install it via apt, and it pulls in a whole bunch of dependencies, it's a bit disconcerting to me.
I'm a bit partial to dehydrated, which is a shell script (works under Bash and Zsh): I find it a lot easier to understand. It's handy to put on Linux/POSIX-based appliances like F5s, where the only prerequisites are Bash, cURL, and OpenSSL (and standard Unix tools like sed, grep, etc):
* https://devcentral.f5.com/s/articles/lets-encrypt-on-a-big-i...
* https://github.com/EquateTechnologies/dehydrated-bigip-ansib...
> I'm using the acme.sh client but the process will be similar no matter which client you choose to use.
Always nice to see some variety in clients along side the official Let's Encrypt one.
While we do use the official Python-based client at works at times, whenever I install it via apt, and it pulls in a whole bunch of dependencies, it's a bit disconcerting to me.
I'm a bit partial to dehydrated, which is a shell script (works under Bash and Zsh): I find it a lot easier to understand. It's handy to put on Linux/POSIX-based appliances like F5s, where the only prerequisites are Bash, cURL, and OpenSSL (and standard Unix tools like sed, grep, etc):
* https://devcentral.f5.com/s/articles/lets-encrypt-on-a-big-i...
* https://github.com/EquateTechnologies/dehydrated-bigip-ansib...
> 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 not satisfy your personal / particular level of security concern, it is something. 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...
> 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-mo...
* https://www.eff.org/deeplinks/2018/02/technical-deep-dive-se...
Let us say you with 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 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 ever 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:
* 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:
* https://github.com/AnalogJ/lexicon
We use Caddy for serving our free dashboards and status pages on your own domain at https://checklyhq.com
It was not super easy to set up. I think the whole config is 20 lines or so, but the docs, naming and functionality of how Caddy actually interfaces with LE was tricky to find out. Basically had to scrape together answers from various GitHub issues etc.
I should write a blog post…
Do you realize that "HN" isn't one single monolithic entity that needs to achieve 100% consistency in its views? Like if one person here says "use existing libraries" but then a different person says "don't use this existing library", that doesn't actually mean that someone was being hypocritical.
You might also consider that not all advice (especially when presented in an extremely limited form like a comment box on a website) should be interpreted as black or white, full compliance or complete rejection, but might better be treated as a general guideline or recommendation and that standard disclaimers or tradeoffs ought to be implied.
Certbot is a bad example of "use existing libraries and never reinvent the wheel" because it pulls in soooo many unrelated things. These are certbot's python dependencies: https://github.com/certbot/certbot/blob/master/tools/require...
Almost 200 different dependencies. Most of them to handle some niche use-case that are likely not what a given user needs. For some people certbot, with its downsides still might be the best solution. For others, there might be a more appropriate solution that still avoids reinventing the wheel. Eg, I prefer to use a single Go library to do ACME stuff or to just use Traefik or Caddy or some other reverse proxy/load balancer that supports ACME transparently without pulling in a ton of extra packages that aren't relevant to me. But sometimes, cerbot is still the simplest solution, so I use that. I still reserve the right to wish that it had fewer dependencies.
> You have the option to create a virtualenv and install it with pip, or snap, or use a docker image.
You could jump through all those silly hoops (most of which will be completely alien to people who are not Python devs) in order to use the "official" dependency-heavy Python client.
Or you could just use a single pre-compiled Go binary, LEGO [1].
I have been increasingly favouring Go recently because the functions delivered to the end-user are dependency free, you can just ship simple single binaries instead of having to say "oh you need Python X with this that and whatever other Python library under the kitchen sink installed on your system".
[1]https://github.com/go-acme/lego
I already had Bind on the machine so it was logical to add the zone there and utilize nsupdate : https://gist.github.com/kronthto/893715f12cc0b1cda9fcfdbd8dc...
But what you are suggesting should work just fine aswell - there should be no need for a persistent service. Of course the service would need to run on port 53, so you actually cannot have another nameserver on that machine already, and also require CAP_NET_BIND_SERVICE .
A quick search lead me to this python project that could be an inspiration: https://github.com/pawitp/acme-dns-server
Recommendation from me as well. Have been using this script for multiple years now without a single issue. The minimal code is awesome for avoiding unnecessary external dependencies and complexity.
Be sure to use the latest version from https://github.com/diafygi/acme-tiny though :-)