On Mon, Sep 25, 2023 at 12:53 PM Jérôme BECOT <[email protected]>
wrote:

> Hello,
>
> We have a couple of old ldap servers (Debian 7/openldap 2.4.31) on which
> we try to replace the certificates. On these servers we have a bundled
> configuration:
>
> # config
> dn: cn=config
> olcTLSCACertificateFile: /etc/ldap/tls/multi.deverywa.re.pem
> olcTLSCertificateFile: /etc/ldap/tls/multi.deverywa.re.pem
> olcTLSCertificateKeyFile: /etc/ldap/tls/multi.deverywa.re.pem
>
> The file is a bundle containing both the certificates (wildcard and it's
> issuer) and the key. Until this year we just had to upload the new bundle
> and restart slapd. This year Gandi changed their signing certificate but it
> is still issued by UserTrust. But OpenLDAP refuses to use it now.
>
> We tried to set LogLevel to any, but nothing really showed in the log. On
> the server side:
>
> slapd[9217]: connection_read(16): TLS accept failure error=-1 id=1041,
> closing
>
> On the client side (localhost):
>
> openssl s_client -connect localhost:636 -servername ldap.deverywa.re
>
openssl s_client -connect ldap.deverywa.re:636 -servername ldap.deverywa.re

Otherwise, the certificate needs to include the name 'localhost' in Subject
Alt Names.

> CONNECTED(00000003)
> 140365161965224:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
> failure:s23_lib.c:177:
> ---
> no peer certificate available
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 0 bytes and written 315 bytes
>
0 bytes read means s_client did not get a response from the server.

Try the usual suspects. Ensure there's something listening on the port,
ensure a firewall is not blocking the port, ensure TLS is enabled, etc.

> ---
> New, (NONE), Cipher is (NONE)
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> SSL-Session:
>     Protocol  : TLSv1.2
>     Cipher    : 0000
>     Session-ID:
>     Session-ID-ctx:
>     Master-Key:
>     Key-Arg   : None
>     PSK identity: None
>     PSK identity hint: None
>     SRP username: None
>     Start Time: 1695652388
>     Timeout   : 300 (sec)
>     Verify return code: 0 (ok)
>
> We still use 2048 RSA key to generate the certificates. We have checked
> permissions and it is fine. How could I debug what's wrong on the server
> side ?
>
Jeff

Reply via email to