Aha , now I’v managed to do this.
You both going to disagree with me 
that’s the bug seen the underling structure of NS-modules
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…
Why do you consider the current behavior a bug?
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.
1 Like
Thank you to everyone for the analysis of the problem: I’ve managed to reproduce the issue with provided info.
How to reproduce the creation of a certificate with a different name:
- Request a certificate for domain
le1.gs.nethserver.net:[root@le1 ~]# config getprop pki LetsEncryptDomains le1.gs.nethserver.net - Generated certificate is named after the first domain contained inside
LetsEncryptDomains: this is the default behavior of certbot-doption. See--cert-nameoption for more info (this option was not present on acme.sh) - Adding the domain
le2.gs.nethserver.netdoesn’t change the name of the certificate:[root@le1 ~]# config getprop pki LetsEncryptDomains le1.gs.nethserver.net,le2.gs.nethserver.net [root@le1 ~]# openssl x509 -text -noout -in /etc/letsencrypt/live/le1.gs.nethserver.net/cert.pem | grep -e DNS -e 'Subject:' Subject: CN=le1.gs.nethserver.net DNS:le1.gs.nethserver.net, DNS:le2.gs.nethserver.net - Adding
le3.gs.nethserver.netas first domain, still doesn’t change the name of the certificate (despite what certbot man is saying):[root@le1 ~]# config getprop pki LetsEncryptDomains le3.gs.nethserver.net,le2.gs.nethserver.net,le1.gs.nethserver.net [root@le1 ~]# openssl x509 -text -noout -in /etc/letsencrypt/live/le1.gs.nethserver.net/cert.pem | grep -e DNS -e 'Subject:' Subject: CN=le3.gs.nethserver.net DNS:le1.gs.nethserver.net, DNS:le2.gs.nethserver.net, DNS:le3.gs.nethserver.net - Finally, removing
le2.gs.nethserver.net, certbot creates a certificate with a new name:[root@le1 ~]# config getprop pki LetsEncryptDomains le3.gs.nethserver.net,le1.gs.nethserver.net [root@le1 ~]# openssl x509 -text -noout -in /etc/letsencrypt/live/le3.gs.nethserver.net/cert.pem | grep -e DNS -e 'Subject:' Subject: CN=le3.gs.nethserver.net DNS:le1.gs.nethserver.net, DNS:le3.gs.nethserver.net
From now on, the user can see 2 different Let’s Encrypt certificates from the UI:
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:
-
1built-in auto-singed certificate, the one namedNSRV.crt, automatically renewed by NethServer itself -
1Let’s Encrypt certificate with all SANs, automatically renewed by certbot -
0orxuploaded 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
1 Like
The bug here looks like an “incomplete feature”: is it possible to implement this part by some means?
1 Like
Is useful to implement certbot automations?
Currently the package delivered comes from distro mantainer, not the package mantainer/developer…
I do not know: if we add a simple certbot renew inside a cronjob for everyone, it will renew also unused certs. I’m open to better ides.
I do not think so, for the same reason I’ve written above.
is it an issue?
If so, it could act on new items only, preserving the current behavior on existing items.
Yes it is, because you can reach LE rate limiting if old certificates contains unused domains.
I didn’t find how to instruct certbot doing so. 
Not if you’re running a daily cronjob. There is a rate limit for failed authorizations, but it’s five failures/hour/account/hostname. But, of course, an admin should be deleting certs that are no longer in use.
2 Likes
NO. It it is NOT a bug to have the possitbility to have different LE certificates for different web server web sites. It is totally rediculous to define this important feature and standard behaviour in web servers a bug.
The only bug is, that not all active certificates are renewed.
There shoud be one standard certificate but unlimited other certificates for apache sites or reverse proxies. This is already working perfectly apart from the only small bug, that not all certificates are renewed. The solutions is also trivial: just call “certbot --renew”. Old invalid certificates could be deleted after some time or let the user delete them manually (which is missing also currently).
2 Likes
I agree with you. However, what I could not believe is that when removing domain specific certificates via the cockpit GUI, the certificates in /etc/letsencrypt are not completely deleted. At the next certbot renew the cronjob generates an error and you have to delete them manually.
1 Like
Ok. Then there are two (minor) bugs.
- Not all certficiates are renewed. Solution: “certbot renew” instead of complicated old script
- Deletion of certificates in cockpit has to delete certificaes in /etc/letsencrypt also.
just thinking i could be wrong but couldn’t we add something like an if statement pointing to host file or something to determine if the domain would be in use and give a warning and maybe have a tick box next to lets encrypt cert in cockpit asking if you want to issue a cron job auto renew
It is much simpler: The user can and should decide which certificates he needs and delete those, he doesn’t want to use any more.
The single automatic cronjob should prolong all certificates (certbot --renew).