SSL certificates for Samba AD (NSDC host)

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 :smiley: ) 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 :slight_smile:

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 :wink:
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 :stuck_out_tongue:

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 :wink:

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

My domain name is domain.com
Nethserver name is server.domain.com
AD server hostname is nsdc-server.domain.com
The certificate is valid for server.domain.com and nsdc-server.domain.com

Nethserver AD can use TLS, yes. This will use port 636.

Hi,

OK, is that correct?
I thougth, best practise is to use
My domain name is domain.com
Nethserver name is server.domain.com
AD server hostname is nsdc-server.**ad.**domain.com

THX
Thorsten

I have seen the NethServer installation procedure propose the exact same, but I really have no use for the AD on a subdomain. It overcomplicates the setup for no known-to-me reason. If it is best practice, I have missed a few things.

(It could probably be useful in a huge domain where you are not the single AD server in the domain (forest), like a departmental server)

Hello, @giacomo @mrmarkuz
hoping consider of the default certificate in the nethserver,I think give a user to choose his cert from web GUI be perfect :grin:
Best Regards