Hi @dnutan
Is it possible for letsencrypt-certs from the command line to have a paremeter like “--dns dns_cf” (the cf is for Cloudflare but there are a lot of other) and also if it can use ENV parameters like CF_Key and CF_Email.
Also, can it have the parameter --test and --force.
If it is possible then it can replace acme.sh. It will be a miracle choice for a NethServer on a LOCAL LAN.
As far as I understand on NS7, cloudflare and other supported dns providers can be used if a suitable plugin is available but instead of --dns dns_cf acme.sh parameters it uses the ones for certbot and its plugins.
About ENV parameters I think they are not supported by the nethserver script.
letsencrypt-certs script accepted parameters:
-f : force certificate renew (it uses --force-renewal)
-d : comma-separated list of domains
if not set read from config db pki[LetsEncryptDomains]
-v : verbose
-t : testing, enable staging CA (it uses --test-cert)
-e : use given mail for registration
Probably acme-dns and acme.sh methods described by @danb35 in the wiki are more feature complete (honestly i haven’t compared them). Although the wiki shows an example on how to use acme.sh with cloudflare, you can adapt the example to use other providers.
Hi @dnutan
Very interesting link:
I used acme.sh a lot of times on all my LOCAL Nethserver.
Now I am testing NS8 on a LOCAL machine under Debian-11. The acme.sh script works well to get the certificates but it doesn’t copy them at the proper place. Also, the different certs are not in the .pem format.
I guess the conversion to .pem format and placement of the resulting certs are done with the last command:
--reloadcmd "/sbin/e-smith/signal-event certificate-update"
This last command is the one to adjust for NS8, but certificate-update is made of quite a few small files.
First problem:
The conversion should be done the same way without adjustments (nothing to change) but the certificate-update files are not available for Debian-11 and mainly it doesn’t have a pki-db.
Possible solution:
There are some scripts on the Internet to do this conversion to .pem format.
Second problem and the main one:
The placements of the certs.
In NS8, the certs are at many more places then in NS7.
Solution:
Find out which certs go where in NS8.
Testing NS8 without a proper cert from Let’s Encrypt is just a waste of time…
@danb35 @mrmarkuz @stephdl All suggestions welcome,
Michel-André
P.S. You can split this topic.
Yes, they are–they just don’t have that filename extension, but they’re still PEM-encoded data. If you really wanted filenames ending in .pem, you could specify that using the various -file directives to acme.sh (--cert-file, --key-file, etc.). But the data’s still going to be the same, byte for byte.
Not really to “adjust,” but to completely replace–the config database, events, actions, etc., are all part of the e-smith architecture, which is completely gone in NS8 (which is also why NS8 is, at least somewhat, distro-agnostic). AFAIK, there isn’t any direct replacement for it. That means you’d likely use a different --reloadcmd for something with a web interface (and thus behind Traefik) than you would for something like the mail server.
The bigger question, as you say, is getting NS8 to use that cert, and I really don’t know how that would be accomplished. From what I understand of its architecture, each service that would use a cert would need to be updated individually–which isn’t quite as bad as it sounds; any of the web stuff should be behind Traefik, so it’d just be a matter of telling Traefik to use the new cert, rather than updating it in Nextcloud, and WebTop, and Nginx, and… The only other thing I can think of that would use a cert, and not have a web interface, would be the mail servers.