On 2025-02-21 3:10 AM, Voilier Voilier" ([email protected]) wrote:
It's possible 389ds is not configured to run StartTLS or baybe there is a certificate trust problem.
    It's woorking with ldappasswd -Z so StartTLS is working also


Quoting the man page:

"-Z[Z]   Issue StartTLS (Transport Layer Security) extended operation. If you use -ZZ, the command will require the operation to be successful"

Using "-ZZ" would probably be better evidence that TLS is actually working.

But even once you demonstrate that it's working, you have to determine what certificate is in use, how it was signed, and whether the signing certificate is part of the system's trusted cert DB.  It's likely that ldappasswd is using a trust DB that's separate from the system's global configuration.

For example, I would use openssl's s_client to check the certificate chain of my LDAP server:

$ openssl s_client -starttls ldap -connect ipa.private.example.net:389

Certificate chain
 0 s:O=PRIVATE.EXAMPLE.NET, CN=ipa.private.example.net
   i:O=PRIVATE.EXAMPLE.NET, CN=Certificate Authority
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Oct 28 00:35:17 2023 GMT; NotAfter: Oct 28 00:35:17 2025 GMT
 1 s:O=PRIVATE.EXAMPLE.NET, CN=Certificate Authority
   i:O=PRIVATE.EXAMPLE.NET, CN=Certificate Authority
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Oct  2 14:19:07 2017 GMT; NotAfter: Oct  2 14:19:07 2037 GMT

If your LDAP server doesn't have a TLS certificate, s_client will tell you so.

The certificate that I see was signed by a private CA managed by FreeIPA.  You might have something else, including a self-signed certificate.  Whatever certificate is at the end of that certificate chain needs to be trusted by your system.

On a Fedora system (or something in that family), you'd probably look for the signing certificate in /etc/pki/ca-trust/extracted/pem/directory-hash/ , and it should also appear in /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

If the signing certificate isn't in both of those places, then TLS clients (like SOGo) won't trust the TLS session.

Reply via email to