Would I be requesting something silly when I would request (the proper way) the renewed certificate from LetsEncrypt on the Nethserver host to add the CN for the AD container to the requested certificate, and copy it over the AD container’s Samba certificate?
Yes, I think it would be useful. I’d extend the support to the whole Server certificates page (upload, LE, autogenerated cases).
Let’s listen to other opinions!
1 Like
Letsencrypt does come with a ‘catch all’ option: you can use wildcards for subdomains. Can this be an option to automagicaly renew the cert for NSDC containter too?
I know I have voiced my concerns about this option, but it might come in handy in this situation.
It’s not a subdomain, and shouldn’t be. It’s a different host on the same domain. So the Nethserver’s record should only need an extra host (nsdc-[servername].domain.tld) added to it’s certificate, and copy it over the certs in the container for this to be no longer an issue.
So, basically, all I need for this to work like I already expect it to work, would be for the letsencrypt routine to
a) add the nsdc-hostname.domainname.tld to the list of requested CN’s, or ‘Domains’ as they are called in the Gui
b) Next step is to simply copy the created certificate and key to the expected locations. Defaults are:
cp /etc/pki/tls/certs/localhost.crt /var/lib/machines/nsdc/var/lib/samba/private/tls/cert.pem
cp /etc/pki/tls/private/localhost.key /var/lib/machines/nsdc/var/lib/samba/private/tls/key.pem
chmod 600 /var/lib/machines/nsdc/var/lib/samba/private/tls/key.pem (could probably be skipped)
chmod 644 /var/lib/machines/nsdc/var/lib/samba/private/tls/cert.pem (could probably be skipped)
Is there a way for me to “extend” that routine, or is this something that is within the range of possibilities to be added to the letsencrypt routine of AD account provider type installs ?
(Reason being: java and other services depend on a valid certificate, self-signed is a no-go. My hack is easy to forget (as @davidep remarked when I voiced my solution 
) and quite nescessary for proper AD functioning.)
1 Like
You may integrate it in /usr/libexec/nethserver/letsencrypt-certs (maybe just add a line to execute your custom script) or you could setup a cronjob (no need for changing internal scripts)
1 Like
Just out of curiosity, what kind of LE challenge did you set up? DNS? HTTP?
When a certificate is renewed (including LE one) the event certificate-update is called.
You can add a script inside it /etc/e-smith/events/certificate-update
3 Likes
Just HTTP, it still requires me to open a port in the firewall, but that is very workable.
@giacomo , thanks, that’s what I was looking for 
2 Likes
@giacomo If I drop the following content in a file in /etc/e-smith/events/certificate-update/ and chmod+x it, would that be enough ?
#!/bin/bash
cp -f /etc/pki/tls/certs/localhost.crt /var/lib/machines/nsdc/var/lib/samba/private/tls/cert.pem
cp -f /etc/pki/tls/private/localhost.key /var/lib/machines/nsdc/var/lib/samba/private/tls/key.pem
chmod 600 /var/lib/machines/nsdc/var/lib/samba/private/tls/key.pem
chmod 644 /var/lib/machines/nsdc/var/lib/samba/private/tls/cert.pem
…or is there something else I need to be aware of with these events/actions ? (it seems to work, just not sure if this will survive updates and stuff)
2 Likes
Yes, it’s enough and it will survive updates 
You should also add the file path to the custom backup config configuration!
2 Likes
Perhaps this is a totally different matter but in my eyes it is related to this feature. I am trying to add Nextcloud as an external server to keep traffic more seperated from Nethserver but for that I need working SSL on Samba. I tried this method but I am still getting the Samba autogenerated host and ca certificates if I check on port 636.
I’m thinking about how to put this feature in the next nethserver-dc release in a backward-compatible manner.
I came to the following conclusion: the update must not alter existing systems configuration.
- Already existing DCs must keep on using the old Samba self-signed certificate.
- Newly provisioned DCs will use the default NethServer system certificate.
I guess we must also push the NSDC host name in the certificate generation routines, both self-signed and LE ones.
4 Likes
Could be very handy yes. Glad you described a possible solution. ^^
Not sure about the first bullet. I dont see any harm in replacing the old Samba self-signed certificate with default Nethserver system certificate. It would keep people on the depricated system and cause confusion in about half a year or so 
In cases of self-signed, it is irrelevant which self-signed one is used, and when the LE one gets pushed, that means an improvement. Am I mistaken ?
Does the file in
/etc/e-smith/events/certificate-update/
need to have any specific name or?
Only for your own easy of reference. Make sure to chmod + x it tho. The first line will tell linux that it is a bash script 
What ist influenced by this tweak?
I applied it yesterday but from that day an external reques to Nethservers LDAP is not processed anymore (which worked perfektly) until yesterday.
I tried to reverse that step (I backupd up the old certificates and put the back in their old places)
THX
Thoirsten
The certificate used for the AD, nothing else. You probably need a reboot. (or manually restart the relevant deamons)
Just two questions:
which hostname did you use
ad.mydomain.tld
or
nsdc-xxx.ad.mydomain.tld
Is Nethserver AD than capable of using port 636 for ldaps ?
Thank you and best regards
Thorsten