DietPi-Software/LetsEncrypt | acme.sh

[Kreeblah]

Creating a software request:

Vote for it on FeatHub: https://feathub.com/MichaIng/DietPi/+28

Give us some formal software information:

• Software title | acme.sh
• Short description | Let's Encrypt client written in shell scripts
• GitHub URL (if available) | https://github.com/Neilpang/acme.sh
• External URL (if available) | https://acme.sh
• (Official) install documentation | https://github.com/Neilpang/acme.sh/wiki/How-to-install

Are there similar/alternative software titles available with DietPi-Software?

• Certbot

What makes your requested software better than the above solutions, if available?

• acme.sh supports a much, much wider list of DNS services (which is frequently expanding) for automated domain control validation, in addition to all of the validation methods and DNS services that Certbot supports, domain-specific certificates, wildcard certificates, etc.

How can DietPi make the installation easier or compatible, than following the install instructions or do APT installation, if available?

• The same reasons for supporting Certbot apply.
• It would also be useful for generating certificates for things other than Apache or Nginx installs, if they're needed.
• It looks like dietpi-letsencrypt doesn't currently support DNS validation, so that could be useful for generating certificates for internal-only hosts.
• What I'd really love is a way to configure a domain with a control validation method, and then be able to specify that for each cert when I generate one for it or a subdomain under it. For example, configure DNS validation for mydomain.com in a central location, and then when I configure certificates to be created for mydomain.com, www.mydomain.com, testing.mydomain.com, etc., then I wouldn't have to configure the DNS validation for each of those since the tools would already have the configuration info for it.
• It would also be nice to be able to specify where each certificate is stored on a per-certificate basis (Apache for one, nginx for another, some other directory for another one).

Can you provide the installation steps that you would suggest DietPi-Software to do?

1. Download the acme.sh script as an appropriate user
2. Prompt for details about the certificate, what it will be used for, which domain to issue it under, what key length to use, and where to keep it (if it won't be used for Apache or Nginx)
3. Reload the web server daemon if applicable, or other service if specified as a separate --reloadcmd value.

Are you willing to help maintaining the software installation, e.g. in case of needed setup changes due to updates etc.? This is not needed, but could speed up our decision to implement it, as man power is always a topic :wink:.

• It depends on what help would be needed. I've had pull requests accepted to better integrate acme.sh into pfSense and a third-party script for UniFi CloudKeys, but I'm not familiar with how DietPi's tools work. I also can't test the full range of DNS options, though once one is working, the rest should as well as long as there aren't any typos in how they're called.

[MichaIng]

@Kreeblah Thanks for your request.

Jep we had this suggestion in the past. Actually my plan is to create a new DietPi-TLS script. This should allow to:

• Create self-singed certificate
• Get LetsEncrypt cert via certbot
• Get LetsEncrypt cert via acme.sh
• Enable/Disable HTTPS/TLS encryption for all webservers and other software titles individually

It makes sense then to allow DNS validation method, e.g. if no webserver is installed, the cert is required for something else.

Other issues/feature requests related to this:

• https://github.com/Fourdee/DietPi/issues/1622
• https://github.com/Fourdee/DietPi/issues/1840
• https://github.com/Fourdee/DietPi/issues/1910

[MichaIng]

Added to FeatHub, feel free to vote for it: https://feathub.com/MichaIng/DietPi/+28

[Kreeblah]

Um, did that comment get left on the wrong issue? That link points to an entry for Etherpad.

[MichaIng]

@Kreeblah Whoopsie, fixed!

[keithellis74]

Hi guys, I'm in the process of setting up HAproxy to handle a single SSL cert for multiple sub domains directing to multiple backends. Is there a timeline for wildcard lets encrypt certificates?

[MichaIng]

@keithellis74 Larger tasks, will take at least 2 DietPi subversions longer. However easy to apply manually, which webserver do you use?

Ah it's HAproxy only that requires the certificate, if I get it right? Then dietpi-letsencrypt would currently anyway not work, since it applies/installs the cert for Apache2/Nginx/Lighttpd/Minio S3 only currently. Another task to add HAproxy support, respectively standalone cert creation option without any install.

In this case please do the following:

• Assure HAproxy and webserver(s) (behind) are up and accessible via port 80/http and your main domain of course.
• certbot certonly --webroot -w /var/www --rsa-key-size 4096 -d *.domain.org -d domain.org
  • Follow on screen instructions about email and agreements.
  • RSA key size could be 2048 as well which is considered to be stable enough currently, however to be future-prove I will always recommend 4096.

EDIT: See below, DNS authentication required, which somehow makes sense to verify that you really own all subdomains.

---

Hmm official instructions state to use DNS authentication for wildcards, not sure currently if the above works as well: https://certbot.eff.org/lets-encrypt/debianstretch-haproxy And it looks like the webserver needs to be setup with SSL + cert as well, not just the load balancer. Sorry I have not really any experience with HAproxy 😉. If indeed required, then the steps are as well not too hard to apply manually.

[ovz93br43v7]

Probably useful, I read here from DietPi. In the comment section was a discussion about Certbot which ended in two proposals: https://github.com/diafygi/acme-tiny and the already mentioned https://github.com/acmesh-official/acme.sh

So probably acme-tiny is worth a look.

[MichaIng]

Here is how I use acme.sh currently: https://github.com/MichaIng/hacks/blob/main/install_acme.sh

acme-tiny is a Python script (hence not so "tiny" when taking into account the dependency) and not developed for more than a year. acme.sh is very actively developed and has a large set DNS authentication plugins, full support for as well ECC certs and all such, so I think between those two the match is more than clear 😉.

[sannidhyaroy]

Adding acme.sh to dietpi-software would be really useful.

[cujomalainey]

Came across this after going through the guide on digitalocean and then tricking the dietpi script into setting up renewal services. Definitely would be great to get better support for use cases like HTTPS over VPN.

[master-kw]

I'm making the jump from a Synology NAS to a Docker solution with DietPi (the NAS remains data storage).

Currently I retrieve and create the LE (wildcard) certificate with acme.sh and “push” it to the Diskstation with a defined deployhook.

I have now installed Docker and acme.sh as a container under DietPi. Using the appropriate commands, I was also able to successfully retrieve a certificate here. All data is stored on the client in the Docker container.

Where does the certificate have to go, or which deployhook do I have to execute in order to be able to integrate it later using reverse proxy? On my diskstation, the renewal took place automatically without having to release any ports.

Sorry for that extremely short explanation but I would explain this further if my approach here is the right way.

Regards, Oliver

[Joulinar]

You would need to configure your acme.sh container in away to store certificates on local storage outside the container. This way you are able to access them and can do whatever you want.

[MichaIng]

Note that acme.sh is a well documented single standalone shell script. I see zero reason why one would want to wrap it into a Docker container, where you just replace one CLI with another + complexity + overhead + points of failure etc. Nothing against containers, but a shell script is not a use case for them.

[master-kw]

Okay, I will test it on a separate client. There‘re a view things more to plan. :-)