This would means, a self-signed cert on the samba AD wouldn’t be renewed if a Letsencrypt cert in Nethserver is used?
And “renewed” means here copied to the nsdc container?
A letsencrypt cert will be automatically renewed (means a renewal of the cert because it gets expired). After this renewal it gets copied to the samba container by the script that is fired when a cert is updated (after renewal).
I have tried to “change” (and so renewed) the self-signed cert from Nethserver - after that there was no cert changing/renewing in the ndsc container (from some past renewing process).
But i use a Letsencrypt cert in Nethserver which is enabled as the default certificate.
The self-signed AD certificate will expire in 60 days from now. It seems to be the first certificate from installing/enabling the Nethserver AD.
Can i research and use the “samba AD like renewing way”? Or is there a Nethserver implemented way for renewing this?
Samba in the nsdc container takes care of it’s own certificate an updates it due time.
to copy this ca in the root home dir:
cp /var/lib/machines/nsdc/var/lib/samba/private/tls/ca.pem /root/CA_ad.`hostname`.pem
1 Like
Thank you very much for our answers.
I dont think the Letsencrypt method for the AD certificate would be a solution for me.
The “standard” method with ACME-HTTP would provide to publisch an ad.mydomain.ord entry in public dns. This could cause problems on some sides (resolving to an external ip).
The ACME-DNS method don’t works in my environment(s). My Nethserver installations dont have a RED interface (i have an Firewall instance between Nethserver and Internet for this).
Without RED Interface the acme-dns service would conflict with the Nethserver dnsmasq, unless the acme-dns could work with an alternate port as tcp/udp 53, in this case i could foward the external tcp/udp 53 ports to the alternate acme-dns ports. Is there any experience on this?
There are additional questions in terms of Nethserver connections via TLS/STARTLS to the nethserver AD (/var_/lib/machines). I have read many posts so far but have not yet found a clear answer.
I have wrote, that my Nethserver Cockpit shows me “STARTTLS disabled” in User/Groups section.
To enable this i should could/should
config setprop sssd StartTls enabled
and then run
signal-event nethserver-sssd-update
After that, the Cockpit shows “STARTLS enabled”.
But after that SOGo make Problems. So i should run
signal-event nethserver-sogo-update
But the Problem persist.
What is “real” acting behind the scenes if the settings in db sssd was changed and ssd and sogo was updatet?
I have tried this some times and after reading some post i found, that for my may case.
If i “enable” STARTls and update sssd, the output from:
account-provider-test dump
shows me that
“StartTls” : “1”,
but
“LdapURI” : “ldaps://nsdc-mydomain.ad.mydomain.org”,
and
“port” : 636,
So Cockpit shows “STARTTLS” enabled for the Nethserver AD connection but “real” it works with SSL instead STARTTLS. Security-related this makes no diffrent bur maybe in interaction with Nethserver related (from this part derived) services?
Then when i change the LdapURI in db sssd=service from “ldaps” to “ldap” and the port from “636” to “389”, /and re run the updater scripts) the SOGo connections are fine.
So what is happend here? What depends on what?
Are the sssd settings for the Nethserver “own” AD connections (join) or also for “hinting” installed services where to find connection to the AD?
Which are the “normal” outputs from “account-provider-test dump” if STARTTLS enabled/disabled?
Is my “join” secure now? Works my SOGo also on a secure way? How can i ensure that?
I use the samba “ldap server require strong auth = no” option, so would it be better to go via ldaps on port 636 for all related services? (to secure the connection isnt unencrypted via 389)
(by the way, STARTLS is shown as “disabled” on all my machines installed before late 2019)
Regards
yummiweb
Here is a solution to connect an (external) FreePBX via TLS with a Nethserver AD when using a self-signed cert on the AD (or the nsdc container).
I think this is a simple standard solution in CentOS, but it was not easy to find (for me) - so maybe some others will find this useful:
– On FreePBX (external)
Make the folder /etc/openldap/cacerts
mkdir /etc/openldap/cacerts
Edit the /etc/openldap/ldap.conf…
nano /etc/openldap/ldap.conf
…and add the Line:
TLS_REQCERT allow
If not already, decomment the Line:
TLS_CACERTDIR /etc/openldap/cacerts
– On Nethserver:
Copy the AD cert from NSDC in Nethserver /var/lib/machines/nsdc/var/lib/samba/private/tls/cert.pem
to the FreePBX /etc/openldap/cacerts/ folder (e.g via scp if the FreePBX IP would 192.168.88.99):
sudo scp /var/lib/machines/nsdc/var/lib/samba/private/tls/cert.pem root@192.168.88.99:/etc/openldap/cacerts/nethserver-nsdc.pem
– On FreePBX GUI
Add/Edit directory(s) in FreePBX GUI admin / user management / directories
The STARTSSL and/or SSL connection from FreePBX to the Nethserver AD should working after a new “Submit”.
EDIT:
Of course, after renewing the AD cert the new cert must copied again to the FreePBX cacert folder.
Regards yummiweb
2 Likes