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.
Please show me this option in nethserver-nextcloud, nethsever-mattermost, nethserver-collabora to name a few.
Do not disagree (back in the day implemented this in SOGo too) however historically NS was designed to use one default certifcate. Which makes it unattractive to poke around in the modules relying on this.
Thats why I think this will not materialize and if one is in need of it : make a custom setup…
It is rediculous. The GUI is inconsistent in itsself. NO ONE would expect that it is possible to create multiple certificates but deliberatly only ONE gets renewed. It is totally broken and the exactly this type of design which make people throw away a software, because it fells totally buggy.
Please think again: There is no harm using certbot, it is even simpler than the current script. See it as a maintance to simlity code and in addition you get more consistency in beahaviour or more usability.
I don’t think it is valid argument to NOT fix a bug (or totally broken behaviour) just because there are other missing features, like selection of the cert for all applications. Just fix that, which fixes apache completly which a already a big step forward.
Also I think it would be a good thing, when NS would show ALL virtual hosts in the apache GUI, including the generated ones for applications. If this would be realized you would get the possibility to select the cert per application for free.
See screenshot from @danb35. I also created several ones, delegating different domains to different backend servers via apache (partially also beeing Nethservers) and was wonderung why the first renewal worked but all other severs were not reachable any more at time of renewal.
No, it is a VERY important feature and please DON’T start deleting it. It would be more effort anyway to just fix the reweal script which can be fixed by deleting lot’s of code. Nothing has to be programmed.
Even if you think it is a bug: I herewith officially make a change request, to declare this very valuable “Bug” a feature and fix the other problem of renewal.
I do disagree, of course. But preventing obtaining a separate cert, or warning the user that only the most-recently-obtained cert will be renewed, would be preferable to the current behavior–at least the user would have some warning of what would happen, rather than the certs just silently failing to renew. Of course, this would take considerably more work than a simple daily certbot renew, so one wonders why one would bother…
More important to ask WHY he think it is a bug, is to convince him, not to delete this valuable feature and accepting the feature request to declare this “bug” as a feature, no matter what happened in history.
This form the perspective on how the mentioned nethserver-modules (like it or not) are being configured right now: they assume the default certificate takes care of their (optional) virtual hosts too.
As an example (AS-IS-NOW) nethserver-nexcloud relies on the ssl settings of the default virtual-host (ssl.conf),which uses a copy of default certificate. Even if it is configured to use an optional virtualhost.
IIUC it designed this way to redirect all incoming http requests to https and use the configuration ssl.conf without the need to do implement this for every single module.
Also preventing the need to expand all apache configurations with a certificate update event, though this is of quite minor concern.
From this observation the possibility to request multiple cert’s does not match this design.
EDIT:
My bad:
The default virtual-host uses ssl.conf with a copy (/etc/pki/tls/certs/localhost.crt) of the default server- certificate.
No, it is still not a bug. It would be totally valid design to have one default cerficates for all the preconfigured applications but have the possibility to create different certficates for virtual hosts and especially reverse proxies in apache. Even if apache would be only application which can use the many certificates it would be a very valuable feature. The only thing is that the renewal is broken currently.
I also do not need any more: I do (currently) not need to have different certificates for different applications apart from apache. But as a firewall and frontend reverse proxy SSL termination point, is it extremely important to have the possibility for different certificates for different domains.
No worries,
I’m just a community member and have no intention at all to touch the (default) apache configuration nor am i capable to change something in the UI.
I still have the situation that the certificates do not renew. (…and additionally that I have to generate the TLSA records manually at my NS provider after each renewal).
I have been following the discussion for months now. And it’s hard enough, as the thread dependencies are now so complex that I don’t know which documentations, recommendations, approaches, etc are even up to date and which actually complement each other. So far, I have not dared to implement any of the suggestions, because new approaches are discussed again and again. This is certainly very welcome for finding solutions. However, it confuses me so much that I have not dared to do anything. For me it would be a great relief if Nethserver would finally offer a final solution that just works.
Generated certificate is named after the first domain contained inside LetsEncryptDomains: this is the default behavior of certbot -d option. See --cert-name option for more info (this option was not present on acme.sh)
Adding the domain le2.gs.nethserver.net doesn’t change the name of the certificate:
The most recent is the one named le3.gs.nethserver.net, certbot will keep renew it accordingly to LetsEncryptDomains prop.
The old file named le1.gs.nethserver.net is abandoned and never renewed by certbot.
The certificate name change is really ugly and can mislead the user (for sure it does). Still, the idea to keep renewing only the newest certificate, seems good to me (and it’s what the actual implementation does).
The current implementation, as @mark_nl correctly pointed out, assumes that the NethServer can have:
1 built-in auto-singed certificate, the one named NSRV.crt, automatically renewed by NethServer itself
1 Let’s Encrypt certificate with all SANs, automatically renewed by certbot
0 or x uploaded certificates, manually updated by the user
Using different Let’s Encrypt certificates is now possible due to the above bug.
I still believe that renewing “old” Let’s Encrypt certificates is definitively a bad idea. In the example above, when the user removes the le2.gs.nethserver.net domain, for sure he/she doesn’t want to renew the certificate which contains such domain (le1.gs.nethserver.net file).
In the end, I think there is a bug in the current implement: the system allows the creation of multiple LE certificates and this should not be possible.
We have 3 different strategies here:
fix the bug and force one certificate: hard to implement and it will break installations where multiple LE certs are used
fully support multiple LE certs: even harder than first option, it really needs breaking changes
do nothing and keep the bug: users with a single LE cert will still have a functioning systems, users using multiple LE certs can just drop a cron job (or systemd timer) with a certbot renew
that’s the bug seen the underling structure of NS-modules