Acme.sh, Let's Encrypt, and ZeroSSL.com

michelandre · June 19, 2021, 5:32pm

Hi all,

I wanted to update my documentation on Discourse. I upgraded NethServer, PostgreSQL, and Discourse. Everything worked fine.

Since I had not opened my virtual machine for over a year, the Let’s Encrypt certificate was expired.

Since I just changed the name of the server, domain name and IP addresses, I took no chances and deleted the full directory from /root/.acme.sh and reinstalled the script. It is a new version i.e. 3.0.

I requested a test certificate, it didn’t work.
I was asked to register - I remembered that in the old days you had to accept the license of Let’s encrypt. So, as suggested I ran:

acme.sh --register-account -m toto@toto.org

and everything went well.

The test certificate was recognized by Firefox for the ServerManager and by Discourse.
Very happy that it works, I then asked for an official certificate and there the problems started.

The official certificate was recognized by Firefox for the ServerManager, but when I went to Discourse, the new certificate was not there and it was the test one that was used. I cleaned caches… reboot… always the same old test certificate for Discourse.

Solution # 1:

acme.sh version-3.0

...
DEFAULT_CA=$CA_ZEROSSL
DEFAULT_STAGING_CA=$CA_LETSENCRYPT_V2_TEST
...

old acme.sh

...
DEFAULT_CA=$CA_LETSENCRYPT_V2
DEFAULT_STAGING_CA=$CA_LETSENCRYPT_V2_TEST
...

After several hours of debugging, I found that the acme.sh script was using DEFAULT_CA=$CA_ZEROSSL and not Let’s Encrypt anymore.

I deleted the entire /root/.acme.sh directory and copied an old one from an old virtual machine.

I requested a test certificate and everything went well for ServerManager and Discourse.

I asked for an official certificate again; it was recognized by ServerManager, but not by Discourse which persisted in using the newest test one.

Solution # 2:

Again, after several hours of debugging, I found that the certificate keys: /etc/pki/tls/private/privkey.pem, /etc/pki/tls/certs/cert.pem and /etc/pki/tls/certs/chain.pem had the date of the test certificate.

So I copy them with those in the /root/.acme.sh/forum.toto.org/ directory while renaming them, reboot and then Discourse offered the official certificate.

Yes, I had modified the pki db as the wiki explains

ChainFile=/etc/pki/tls/certs/cert-chain.crt
CrtFile=/etc/pki/tls/certs/cert.crt
EmailAddress=toto@toto.org
KeyFile=/etc/pki/tls/private/cert.key

Now even if I force request a new official certificate, still the one from Discourse is not updated.

Questions:

Am I the only one who got misled by ZeroSSL.com
Using version 3.0 of the acme.sh script changed something that I don’t see that interferes with /sbin/e-smith/signal-event certificate-update ?
Else, can I modify the certificate renewal cronjob to copy the new certificate to the pki folder ?
Else, as the new keys are correctly copy to the pki folder, can I modify the certificate renewal cronjob just to rename the keys in the pki folder to the correct names ?
Else, just name the keys in the pki db: chain.pem, cert.pem and privkey.pem ?

All suggestions are welcome.

Michel-André

dnutan · June 19, 2021, 6:15pm

About ZeroSSL change in acme.sh:

michelandre · June 19, 2021, 7:07pm

Hi @dnutan,

Thank you so much for your fast resply that explains everything.

For the CA:

# acme.sh --version
https://github.com/acmesh-official/acme.sh
v2.8.6

# acme.sh --set-default-ca  --server  letsencrypt
[sam. juin 19 14:31:37 EDT 2021] Unknown parameter : --set-default-ca

So the --set-default-ca is only to be used with the acme.sh version-3.*

The acme.sh will change default CA to ZeroSSL on August-1st 2021
Well, I didn’t know I was in a worm-hole or in in a time-warp.
Anyway, now I’m “Back from the future”.

I restarted my original old VM (March 2020) and it uses “*.pem” with acme.sh version-v2.8.6
Also, I had to restart nginx for Discourse to see the new certificate, which is normal.
But with acme.sh version-3.0, even if I restarted nginx, Discourse was still using the test certificate.

QUESTION:
What will be the “name.extension” to use in the pki db: “.crt” or “.pem” ?

SUGGESTION:
Since the certificate question is primordial, maybe NethServer should put a sticky post about it for a while on this forum ?

A new day, a new lesson learned!

Again, thank you so much for the explaination,

Michel-André

P.S. I will not mark this post as “Solved” as I have things to verify.

michelandre · June 19, 2021, 9:38pm

Hi @dnutan,

I tried different scenarios.

My conclusions with acme.sh-3.0:

".pem"

The first new certificate is set as default.
Server-Manager does not see the certificate, but the browser uses it.
After a systemctl restart nginx, Discourse uses the Let’s Encrypt certificate.

".crt"

After defining the new certificate as default, Server-Manager sees the certificate and the browser uses it.
After a systemctl restart nginx, Discourse does not see the new Let’s Encrypt certificate and still uses the first LE certificate, because it only sees keys with the “.pem” extension.

Discourse:

For me, the best solution would be to find out where Discourse maps the /root/.acme.sh directory and from where it points the different keys in the subdirectory.
It has to do like Jitsi Meet which mounts /root/.acme.sh in the Prosody/YAML container, then there is a parameter that point to each of the different keys in the subdirectory mounted in the container.
Maybe those parameters are in some nginx configuration file or even somewhere else…

Michel-André

danb35 · June 19, 2021, 9:39pm

Whichever extension matches the files in question–they’re effectively interchangeable. As long as the contents of the file are a PEM-encoded certificate/key, it’s fine.

michelandre · June 19, 2021, 9:45pm

I don’t think so for Server-Manager or Cockpit.

mark_nl · June 20, 2021, 6:30am

Indeed, Nethserver uses name somewhat common conventions for the pem encoded cerificates and pem encoded private key’s:

certificate: /etc/pki/tls/certs/certificate.crt
chain: /etc/pki/tls/certs/certificate-chain.crt
key: /etc/pki/tls/private/certificate.key

All extensions will work, however with these extension-name / location conventions the certificate shows up in the NS web-based server-manager(s).

also see:

https://wiki.nethserver.org/doku.php?id=userguide:let_s_encrypt_for_internal_servers

michelandre · June 21, 2021, 9:19pm

Hi all,

Référence: The acme.sh will change default CA to ZeroSSL on August-1st 2021 - #11 by Osiris - Client dev - Let's Encrypt Community Support

From the Community leader of (community.letsencrypt.org)

Osiris / Community leader / Jan 30

ZeroSSL is almost the same as Letsencrypt: support unlimited 90days certs, including wildcard certs. Full ACME compatible.

Aaaaalmost the same, except wildcard certificates aren’t free, certificates with more than a single hostname in the SAN aren’t free, more than 3 certificates aren’t free.

In short: ZeroSSL isn’t really a proper free alternative for Let’s Encrypt for many people.

This would break anyone who doesn’t get the notification and is using CAA to restrict issuance.

But only for users getting a new certificate.

As I wrote before, there should be a sticky note on NethServer forum about this change about acme.sh…

Michel-André

dnutan · June 21, 2021, 10:08pm

Isn’t NethServer using certbot by default? Maybe acme.sh comes from a custom install or alternative LetsEncrypt certificate management method described in our wiki.

Identifying the source might help in discerning if a note is convenient and where to place it.

michelandre · June 21, 2021, 10:36pm

Hi @dnutan

Thank you for your reply.

I think that if your are on a LOCAL NethServer, the best way (maybe the only way) to get a Let’s Encrypt certificate is to use the acme.sh script as explained in the wiki page: https://wiki.nethserver.org/doku.php?id=userguide:let_s_encrypt_for_internal_servers.

This wiki page comes up very often in posts on this forum. So there are a lot of people using this wiki page and therfore the acme.sh script.

So, maybe the best place to put a note will be that wiki page.

Michel-André

danb35 · June 21, 2021, 10:55pm

…and as noted later in that topic, Osiris (who is “a”, not “the” “community leader” at the Let’s Encrypt forum) was incorrect as those statements apply to the ACME API of ZeroSSL.

Certainly not the only way; certbot is perfectly capable of doing this as well, perhaps with not as many options for DNS hosts. If you feel a warning is appropriate, that wiki page would be the place to put it–and since it’s a wiki, you can do that as well as anyone else. Personally, even given my reservations about ZeroSSL (which you’ll note I address at some length in the topic you linked to), I don’t much care about the CA, as long as it’s trusted by my (and my users’) browsers.

I recommend acme.sh because I generally like it, and it works without the tangled mess of dependencies certbot needs. But any client capable of doing DNS validation (which certainly includes certbot) could be used in the same basic way.