Jerome, I’m not certain it’s required however as a matter of practice, I’ve always separated the server certificate from the key.

openssl pkcs12 -in bundle.pfx -nocerts -out slapdserver.key -nodes -> this will give you the key without the cert (olcTLSCertificateKeyFile) openssl pkcs12 -in bundle.pfx -nokeys -out slapdserver.pem -nodes -> this will give you the certificate without the key (olcTLSCertificateFile)

And include the path to the certificate issuing CA chain (olcTLSCACertificateFile) in pem format in your configuration.

We still have a few 2.4.59 replica’s that work just fine with the above approach although admittedly they aren’t running a version as old as what you are running. Hopefully that helps….

Best, Aaron

From: Jérôme BECOT jerome.becot@deveryware.com Sent: Monday, September 25, 2023 11:10 AM To: openldap-technical@openldap.org Subject: Help troubleshooting SSL certificates issue

Warning: This email is from outside the company. Be careful clicking links or attachments.

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

Thank you -- Jérôme BECOT Ingénieur DevOps Infrastructure

Téléphone fixe: 01 82 28 37 06 Mobile : +33 757 173 193 Deveryware - 43 rue Taitbout - 75009 PARIS https://www.deveryware.comhttps://urldefense.com/v3/__https:/www.deveryware.com__;!!PIfy-9xbww!BDpoZpMSRD8FwKe3tzRyRSZqBI7j-HhYu5k2anY8TpzoZ3M9l6TIRxLIOQhxzK93qIqoiBSLDgnqAPGoKSfO6cmx0KI$

[Deveryware_Logo]

---------------------------------------------------------------------- The information contained in this message may be privileged, confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify your representative immediately and delete this message from your computer. Thank you.

It looks like the algorythm used by the provider to generate the certificates is not supported by this old version of gnutls.

Running gnutls-serv (gnutls 3.0) with the bundle: Server is starting but fails upon requests: |<1>| Could not find an appropriate certificate: Insufficient credentials for that request.

Running gnutls-serv (gnutls 3.0) with seperate files: Server does not start Error reading 'multi.deverywa.re.pem.crt' or 'multi.deverywa.re.pem.key' Error: ASN1 parser: Error in DER parsing.

Running both bundled or separate files (same files transfered on another host) on a newer or (gnutls 3.6) works as expected.

I guess there is no way to make it run, unless upgrading the OS.

Thank you !

Le 25/09/2023 à 19:03, Howard Chu a écrit :

Jérôme BECOT 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:

Presumably since that's a Debian build it was built using GnuTLS. I suggest you try using gnutls-cli with your PEM file and see what works or doesn't work.

...

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

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 ?

Thank you

-- *Jérôme BECOT* Ingénieur DevOps Infrastructure

Téléphone fixe: 01 82 28 37 06 Mobile : +33 757 173 193 Deveryware - 43 rue Taitbout - 75009 PARIS https://www.deveryware.com https://www.deveryware.com

Deveryware_Logo https://www.deveryware.com