HelloAfter one week of vacation and your help, I finally understand the 
problem. The certificate of my LDAP is define with my domain name 
"www.domain.com" and in sogo.conf, I was using : hostname = 
"ldap://127.0.0.1/????!StartTLS";, when I change it to hostname = \"ldap://www. 
domain.com/????!StartTLS" It's now working.
Laurent


    On Friday, February 21, 2025 at 10:39:47 PM GMT+1, Gordon Messmer" 
([email protected]) <[email protected]> wrote:  
 
 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