Let's Encrypt DNS challange

Feature
1

Hi Giacomo,

I am looking at OPNsense and I noticed that there is an option (Using Registrar API) when asking a Let’s Encrypt certificate.

image
image894×621 19.1 KB
image

This is great for a Let’s Encrypt certificate for a LOCAL domain. Works like a charm !

It should be possible to implement that in NethServer 7.8.2003.

Michel-André

2 Likes
2

It is. See
https://wiki.nethserver.org/doku.php?id=userguide:let_s_encrypt_for_internal_servers
https://wiki.nethserver.org/doku.php?id=userguide:let_s_encrypt_acme-dns

1 Like
3

Hi Dan,

For LOCAL NethServer, I always used the way the links are showing.

But, OPNsense is a step ahead - it doesn’t require to install anything and all is done from the GUI.

It’s like KISSing throught a Covid mask compared to a French KISS. :blush:

IMHO, not exactly the same.

Michel-André

1 Like
4

I think that DNS challenge for LE it’s very useful and quite simple to use.
We use it extensively inside our infra.

Still not so many NethServerians uses it or even know that out there are services which let you configure a DNS using API :smiley:

So I’m open to review an implementation for this, but I’m not sure we are going to develop it anytime soon. I hope I’m wrong! :smiley:

4 Likes
5

I’m (obviously) a fan of the DNS challenge, but there are a few drawbacks to trying to do a pfSense/OPNSense-style implementation in Neth:

  • It would require using a third-part ACME client (acme.sh) instead of certbot. I’m personally more than fine with this–I don’t really like certbot very much, as it’s a tangled mess of dependencies that tries to do way too much–but there’s been some resistance on the part of the devs to using third-party clients.
  • I’m not sure that there’s a RPM available of acme.sh–it wouldn’t be much of a packaging challenge, I wouldn’t think, but it’d be another thing to do.
  • Every DNS provider is a special case, so you’d need to have unique GUI code, database property code, and “obtain the cert” code for every one of 100+ DNS providers. Renewal would be trivial; once the cert is issued, everything would be saved to the acme.sh configuration, so it would just require a periodic job of acme.sh --cron. But for the initial issuance, you’d need to set the appropriate environment variables (which are different for each DNS provider) to the appropriate values (which are also different for each DNS provider), and then call acme.sh with those variables to issue the cert. Certainly it’s doable–both pfSense and OPNSense have done it, and we might even be able to steal borrow some of their code–but it does seem like there would be some challenges there.

I think a better way to go would be for Nethesis to host a acme-dns instance, and provide a way to validate using that through the GUI. The obvious drawback to this is that it requires Nethesis to provide this infrastructure, and commit to continuing to do so*. But there are several advantages:

  • It works with any DNS host, as long as the user can set up CNAME records there.
  • It doesn’t require highly-dangerous DNS credentials (in many cases, if compromised, these could be used to steal your domain) to be stored in clear text on the Neth server.
  • All credentials would be handled internally; the user doesn’t need to manage obtaining and copy/pasting API credentials in various places
  • Coding work on the Neth end would be a matter of either interfacing with, or reimplementing, GitHub - joohoi/acme-dns-certbot-joohoi: Certbot client hook for acme-dns
  • There’s just one DNS provider to support through the GUI

*Well, kind of. The author of acme-dns operates a public instance of that software, and the rest of the functionality I’m talking about could just as well be directed to hit his (or any other) instance rather than one operated by Nethesis–but he doesn’t really intend his instance for production use.

**@staff - please implement the discourse_footnotes plugin in this board.

1 Like