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.
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.
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:
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.
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.
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?
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.
Yes, I second it. You are totally right. I really don’t understand the hesitation to fix this really broken design. I could have been ok in the past, when certbot was not mature enough, but now everything could trivally be fine.
And one cert does not work @mark_nl:
I have a reverse proxy with several domains pointing to backend servers. Each of these backend servers should get only the cert for it domain not for domain, the do not serve.
The fact, that NS supports the management of multple certs and EVERYTHING works, APART from one single thing, the automatic renewal, of all instead of one certificate, shows that this is a bug or at least a totally broken design which should be fixed.
before going in over our heads I’d like to reflect a bit of the history that resulted in this design:
The start of development of NS7 and the availability of Let’s Encrypt came round the same time.
The wider acceptance of Let’s Encrypt grew from than on…
Just guessing here: Most probably NS was designed with the now somewhat obsolete assumption there will be one certificate.
(Again guessing here) Why not fix it?
Even though the acquisition of multiple certificates seems easy enough to fix it does not stop there;
All webbased modules with a “virtual host property” would get in need of “certificate properties” (cert, and chain) too. Because the module can not guess which certificate to use…
So the “fix” would intrude all these modules:
Poking around in the (default) db properties, the apache configs and UI to use these separate certificates.
The later also implies a user needs to set this, contradicting the simple install philosophy of NS.
It is probably possible to concatenate the separate Let’s Encrypt certificate to one “default” server-certificate. And circumnavigate the above, but then what did we fix ?:
Pulling in separate certificates only to join them together to stay compliant with the setup as-is.
First of all, the main cert application the apache server already HAS the option to select the correct certificate for every web site it serves, and as almost everything it going through apache, it already solved. Sure there is always room for improvement, but the current solution just works, apart from a single little bug, or broken or “historic” design: The rewal of all certificates.
I’m not sure this explains anything. The old client they used, dehydrated, had the ability to specify a command to run after successful cert renewal, so the entire reason for the existence of the letsencrypt-certs script goes away. Of course, certbot also has this ability, and it’s considerably better at dealing with multiple certs.
…which may have been reasonable enough in 2016 when they were first starting to work on NS7. And that assumption accounts for the fact that none of the vhost modules (as you mention, and I discuss, below) allow you to specify a vhost.
But that assumption doesn’t account for deliberately bypassing the client’s own ability to check its own certs for age, decide if they need to be renewed, renew them, and then run a specified command. I’ve shown above that dehydrated had that ability at the time I was working with it for SME; certainly certbot does as well. Rather than use the client’s native ability, the devs wrote a script to re-implement (some of) that functionality. And this is the part that makes no sense to me–they did extra work to lobotomize the client.
Yes, they should. This should be the case now. So long as Neth has the ability to deal with more than one cert (which it has, however imperfectly), any module which allows for use of its own vhost should allow the user to set the cert/chain/key files–which is what I’ve done with mine.
But it isn’t necessary, and doesn’t become any more necessary with my proposed fix. The system still has a “Default” certificate (which may or may not match the LetsEncryptDomains property), and this can be applied to any vhosts which don’t specify a different cert.
I thought I’d submitted a PR on this, but I can’t find it now. But as I say above, there’s still a default cert. The user should have the ability to specify a cert for Nextcloud, Mattermost, etc., but that’s an orthogonal issue to what Carsten and I are suggesting.
Currently I just run “cerbot renew”, which is TRIVIAL and even much simpler than the currently implemented design. This design WAS may be necessary in former times before certbot was mature, but now it is just broken and user hostile, which contradicts the “it is simple and works” philosopy. With this design you send many users into this dead end, they wasting hours of researching, just to learn the the design is broken.
