NS 7.9.2009.
I was getting several mails from Let’s encrypt that a certificate was not updated. I checked in the Cockpit section and indeed there was a certificate not updated. Now the certificate is just one day from expiration.
I then ran ‘certbot renew’ from the terminal and the cerficate got updated.
Why did it not update automatically?
Perhaps also have a button “renew” in the cockpit?
Don’t know but logs might provide some clues.
It should have updated already weeks ago, so to many logs.
How does NS trigger update the of certificates?
I think it is trough a daily cron job that runs letsencrypt-certs.
Because Nethserver only renews one cert automatically, and inexplicably doesn’t include a certbot renew cron job. Recommend adding that as a daily task.
…and letsencrypt-certs only updates the system default cert.
No, it does not update the system default cert, because in my configuration this is a fixed cert bought from a CA.
I look in the script /usr/libexec/nethserver/letsencrypt-certs and the documentation at
https://docs.nethserver.org/projects/nethserver-devel/en/latest/nethserver-letsencrypt.html and look into the script. It seems the script renews all certificates listed in
config getprop pki LetsEncryptDomains
I have two certificates which each include three domains, but only the domains of one of the certificates (the last added) are listed in this property. Why are not all domains listed? And why does NS has this extra script and logic instead of just using certbot-renew?
BTW: The documentation still mentions LetsEncryptRenewDays which is not used any more. It should be deleted.
Because Neth is stuck on the assumption that you’re going to use only one cert. It’s poor design IMO, and complicates things considerably more than necessary.
That’s addressed in the other thread you found, but IIRC, they’d previously used dehydrated rather than certbot, and dehydrated is a somewhat more spartan ACME client. In particular, it has no logic to run anything before or after obtaining a cert–or at least, that was apparently the case at the time; it doesn’t seem to be the case today. Thus, in order to run the signal-event certificate-update command after a cert was renewed, there was the perceived need to write this script to handle such things.
Now, that may have been needed at the time (though even then I doubt it; I was working with dehydrated on SME back when it was called letsencrypt.sh, and I’m pretty sure we were able to call the signal-event directly without writing a wrapper script like this–yep, we were), but what really baffles me is why this mechanism was maintained when Neth made the move to using certbot. Because with certbot, it’s so easy–just add --post-hook /sbin/e-smith/signal-event certificate-update to the certbot command, and run certbot renew daily.
“config getprop pki LetsEncryptDomains” contains three domains in my installation belonging to the same certificate, but none of them is the default domain or default certificate. So why do I have one of the several NON-DEFAULT certficates in the config. I think let’s encrypt domains should be included in the config. Or maybe even better, the code should be changed that simply all let’s encrypt certificates will be extended. I see no reason why some should not be prolonged (they could be deleted then anyway).
The config will have the last cert you got through the GUI. In my earlier post, I conflated that with the default cert, but those aren’t necessarily the same, as is the case for you (though I can’t imagine why).
Because, once again, Neth has a baked-in design assumption that you’re only going to have one cert. It’s gotten past this assumption in some places (when setting up a virtual host, for example, you can choose a cert to use for that virtual host), but not in others. One place where it hasn’t is in its frankly silly handling of certs from Let’s Encrypt.
I don’t understand why there is the possibility in the db to config some domains (i.e. more than one) which should be extended.
Anyway, do you agree that it should be simplified and changed, that simply all certificates should be prolonged? The simply implementation would be
certbot renew --post-hook /sbin/e-smith/signal-event certificate-update
Because that isn’t what that property is actually for; it’s for the domains for which you want to obtain a cert, and once again goes back to the old days with dehydrated.
You already found the topic from April (since you posted there); surely you saw my PR linked there? Lets Encrypt renewal the 105th
Yes, that’s what ought to be done. Get rid of the script, obtain certs with the --post-hook, and run a daily certbot renew.
The script is the same, but that doc is outdated. The correct one is this: https://docs.nethserver.org/projects/nethserver-devel/en/latest/certificate_management.html
Thank you for pointing it out, I’m going to remove it.
If you configure certificates using NethServer UI, you should not need any hack ro renewal.
NS creates one single certificate with all SANs. IIRC the name of the certificate is the first domain saved inside LetsEncryptDomains. It doesn’t renew all certificates, it just renews one certificate that contains all domains.
So, having multiple LE certs it’s just an unsupported scenario.
Still you can customize your installation as you and Dan already suggested. Also remember to add the new cron job to the configuration backup:
echo "certbot renew --post-hook /sbin/e-smith/signal-event certificate-update" > /etc/cron.daily/mycertbot
echo /etc/cron.daily/mycertbot >> /etc/backup-config.d/custom.include
No, several certificates must be supported and are suppported already.The only missing thing is this overcomplicated renewal code, which chooses not to renew all but only one certificate. WHY? There should be no customization neccessary to have a the renewal done correctly.
I created several Let’s encrypt certificates from the Cockpit UI, because different reverse proxy and virtual host web sites use different certificates. NS supports the creation of multiple certificates and multiple web virtual host web sites with different certificates, so all certificates in use must be renewed automatically.
I still see no reason for this complicated and non-functional implementation vs. the simple one-liner “certbot renew …”. It looks old implementation which was not corrected when support for use of multiple certificates we added.
Please also explain why you don’t want the “customization” to be become standard behaviour.
Please reopen the ticket.
Why did you remove the documentation to the let’s encrypt certifcates completly? There are uploaded certificates, self-signed AND let’s encrypt certificates. The latter should be renews automatically, not matter how many are created from the Cockpit UI.
Sorry, I forgot to merge the old doc with the new one.
Now it should be fixed: https://docs.nethserver.org/projects/nethserver-devel/en/latest/certificate_management.html#let-s-encrypt
This is the fix for the documentation but not for the bug itsself documented in https://github.com/NethServer/dev/issues/6548
NS supports multiple Let’s encrypt certificates and all of them must be prolonged not only the last one created. See above.
The problem is still there. I would like to open a new issue on github (or reopen the old one), as NS supports several let’s encrypt certificates and all should be renewed. The solution is simple (see github issue), so why it should not be implemented?
No: NS supports one Let’s encrypt certificate suitable for multiple domains.
One may not like this but that’s how the implementation is right now.
…which is why you have things like this:
and this:
So it supports all the certs you want, but only one LE cert? It’s hard for me to express how nonsensical of a design decision this is, particularly if I want (as I do) to avoid insulting people.
And worse than the nonsensical design decision is that it’s insidious. The GUI will happily allow you to issue as many Let’s Encrypt certs as you want. It won’t indicate in any way that the last one issued supersedes all the others. And a user who has any familiarity at all with Let’s Encrypt will expect that it will work like any other non-brain-damaged client implementation, and renew any certs as they approach expiration.
And even worse than that is that it’s deliberate. This isn’t a matter of overlooking or forgetting something; they went out of their way, writing a script of some 160+ lines, to circumvent the way certbot would naturally work if they’d just let it.
It’s a deliberately broken, user-hostile design, and it would be trivial to fix.
