How to (re)enable TLS/STARTTLS in Nethserver AD

Right, I’m using a letsencrypt cert…

The password shown there is for the ldapservice user.

ldapsearch -D CN=ldapservice,CN=Users,DC=ad,DC=domain,DC=tld -w <pass> -b CN=Users,DC=ad,DC=domain,DC=tld -H ldaps://ad.domain.tld


If i try this on all machine without starttls like:

ldapsearch -D CN=admin,CN=Users,DC=ad,DC=domain,DC=tld -w -b CN=Users,DC=ad,DC=domain,DC=tld -H ldap://ad.domain.tld

the result is also an “invalid Credentials”, hä?
Something bad in my Syntax?

I have adopt your example with my “domain”," tld", “IPv4” and “” changed to my Bind password in line all without quotes, right?

Now i see the different: admin / ldapservice

1 Like

O.k. the wrong username was the initial* problem with “Invalis Credentials”.
I have used the “ldapservice” user now.

So i can now connect from the Nethserver itself via:

ldapsearch -D CN=ldapservice,CN=Users,DC=ad,DC=domain,DC=tld -w -b CN=Users,DC=ad,DC=domain,DC=tld -H ldaps://ad.domain.tld

*But it don’t works with the -ZZ option (Start TLS request (-ZZ to require successful response)):

ldapsearch -D -ZZ CN=ldapservice,CN=Users,DC=ad,DC=domain,DC=tld -w -b CN=Users,DC=ad,DC=domain,DC=tld -H ldaps://ad.domain.tld

In this case the result is also a kind of an “Invalid Credentials” Error:

ldap_bind: Invalid credentials (49)
additional info: 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1

So i am not sure the connection is really STARTTLS.
If try to connect from other machines the result is like before:

ldap_sasl_bind(SIMPLE): Can’t contact LDAP server (-1)

Very good, so SSL is working.

For starttls you need -H ldap://ad.domain.tld, not ldaps. It’s port 389.

You’re right, but the “forced” starttls via -ZZ option results in the same “Invalid Credentials” Error.
My -ZZ option was on the wrong place. (it is definitely to late today…)
On Nethserver it works with -ZZ option to “-H ldap://ad.domain.tld” and to “-h IPv4 -p 389”.
But it didn’t works on port 636.

Meanwhile i have “successful” enabled the Nethserver connection to its own AD. I have enabled TLS this in the db and then run signal-event nethserver-sssd-update (and a restart). After that, the AD connection seemst to be “ok”, the user and group section shows users and groups and the connection from services like sogo runs normal without password problems (like yesterday).

But i am still not sure, that the connection between Nethserver and the AD is secured by TLS.
Alls tests from other machines works only via IP (the -h option) and to port 389 (without -ZZ option).

The FreePBX “Directory” Connection also only works without SSL or STARTTLS.

My Mac shows:

ldap_start_tls: Connect error (-11)
additional info: SSLHandshake() failed: misc. bad certificate (-9825)

Hm, I can connect to my NethServer AD with StartTLS option -ZZ from another NethServer but I use a valid cert for the samba AD server.

ldapsearch -ZZ -D CN=ldapservice,CN=Users,DC=ad,DC=domain,DC=tld -w <pass> -b CN=Users,DC=ad,DC=domain,DC=tld -H ldap://ad.domain.tld

You use a Letsencrypt certificate on the AD Provider (the nsdc container)?

Yes, it’s explained here:

Thank you very much for lead me to this guide.
But i am not sure to have an fqdn for my AD provider which can be resolved via an external dns.

After read this guide i unterstand my certificate error as (please correct me),
that a “untrusted” cert on my AD provider ist the reason for my problems with connecting external clients or apps?

Maybe this is an “Newbee” question, but can i manual “trust” this “untrusted” AD certificate on the client machines (for Example an FreePBX)?

It could be for some NAS or Java apps, from my experience.

Another way would be to disable strong auth. Just for testing if your clients can connect without encryption to exclude other issues. From the wiki (go to AD section):

Edit /var/lib/machines/nsdc/etc/samba/smb.conf and add following line to [global] section:

ldap server require strong auth = no

Restart samba (AD):

systemctl -M nsdc restart samba

Some implementations provide an option to allow self signed certs, I don’t know how freepbx handles it but I don’t think it’s needed for freepbx, I’m going to check when I find time.

“Strong Auth” ist already disabled in the nsdc container, this is over from some radius, mattermost, whatever experiments.

Is there a “typical” way to “renew” the cert/password pair of the nsdc container? Is this manual needed in cases like expiration, changes in strengt or tls versions or something? As i can see, the AD cert expired in some months.

I think the samba AD uses the self-signed cert from Neth by default, so it should be renewed if you edit the self-signed cert.
There’s no official way yet, only the script for LE certs that get renewed automatically.

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”,


“LdapURI” : “ldaps://”,


“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)


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

sudo scp /var/lib/machines/nsdc/var/lib/samba/private/tls/cert.pem root@

– 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”.

Of course, after renewing the AD cert the new cert must copied again to the FreePBX cacert folder.

Regards yummiweb