I have been pointed to Jeroen’s SAMBA LE import script and have manually imported an LE cert to my AD container using the absolute path (rather than importing a localhost files after setting the LE cets as the Nethserver default certificate) with @mrmarkuz helping me understand the logic behind it all. Security and ease of deployment was the primary feature for me to move over to Nethserver in 2019/2020 and I’d love to see the ability for items like this become more widely adopted.
IIRC we already discussed this feature internally.
While is easy to setup the cert inside the AD, it could cause some unexpected problems on clients.
Also if we use Let’s Encrypt certificate on the AD, we must restart it on each certificate update: this is also dangerous.
In the end, while I think this is a good idea, it’s a nightmare to implement and it can cause regressions.
I am a novice here and not fully aware of the risks associated with this process. Does restarting the AD/SAMBA4 have a large potential to cause damage? Any more harmful than a reboot of the NS machine?
Usually restarting the container is not a problem, but changing the certificate could be impact clients.
I’m not sure about all the consequences, but @davidep told me it was too hard to nto break things on the AD
I’m afraid it could lead to DNS configuration troubles… MS best practice encourages a private zone for the AD domain, usually a third level domain, like ad.example.com. If you want to use LE as certification authority for AD that best practice is not… practicable
As alternative it is possible to manually install a custom certificate and restart the Samba DC. The custom certificate can be added to the client app trusted sources (e.g. third party Java applications): if you have a few of them it can be done just once for all. Windows clients do not rely on TLS. NethServer clients do not check the cert validity at all.
To create a certificate check out sscg
yum search sscg
In the end I’m still not convinced of implementing a LE certificate integration with the Samba AD service.
Nsdc initial releases suffered of restart issues during upgrades, due to a race conditions between the kernel and systemd-nspawn networking. As we introduced a “nsdc reload” variant that issue was solved. This command should be safe (though not enough known and used).
