On 14/12/2022 20:11, Andre Rodier wrote:
Thanks for your advice everyone.
For those who are interested, I found the solution on this thread:
https://serverfault.com/questions/459718/configure-openldap-with-tls-require...
dn: cn=config changetype: modify replace: olcTLSCipherSuite olcTLSCipherSuite: TLS_RSA_CAMELLIA_128_CBC_SHA1:TLS_RSA_CAMELLIA_256_CBC_SHA1:!NULL
Kind regards, André
Now, I can see this:
root@main:/etc/ldap/changes# sslscan ldap.homebox.world:636 Version: 2.0.7 OpenSSL 1.1.1n 15 Mar 2022
Connected to 2001:19f0:7402:86e:5400:4ff:fe38:b9b4
Testing SSL server ldap.homebox.world on port 636 using SNI name ldap.homebox.world
SSL/TLS Protocols: SSLv2 disabled SSLv3 disabled TLSv1.0 disabled TLSv1.1 disabled TLSv1.2 enabled TLSv1.3 disabled
TLS Fallback SCSV: Server supports TLS Fallback SCSV
TLS renegotiation: Session renegotiation not supported
TLS Compression: OpenSSL version does not support compression Rebuild with zlib1g-dev package for zlib support
Heartbleed: TLSv1.2 not vulnerable to heartbleed
Supported Server Cipher(s): Preferred TLSv1.2 256 bits ECDHE-RSA-AES256-GCM-SHA384 Curve 25519 DHE 253 Accepted TLSv1.2 256 bits ECDHE-RSA-CHACHA20-POLY1305 Curve 25519 DHE 253 Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-GCM-SHA256 Curve 25519 DHE 253 Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA Curve 25519 DHE 253 Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA Curve 25519 DHE 253
Server Key Exchange Group(s): TLSv1.2 128 bits secp256r1 (NIST P-256) TLSv1.2 192 bits secp384r1 (NIST P-384) TLSv1.2 260 bits secp521r1 (NIST P-521) TLSv1.2 128 bits x25519 TLSv1.2 224 bits x448
SSL Certificate: Signature Algorithm: sha256WithRSAEncryption RSA Key Strength: 2048
Subject: ldap.homebox.world Altnames: DNS:ldap.homebox.world Issuer: (STAGING) Artificial Apricot R3
Not valid before: Dec 13 05:34:29 2022 GMT Not valid after: Mar 13 05:34:28 2023 GMT
On 14/12/2022 16:41, Jeffrey Walton wrote:
On Wed, Dec 14, 2022 at 2:42 AM Andre Rodier andre@rodier.me wrote:
... Well, actually, this is the next issue.
For instance, here the LDIF file I use:
dn: cn=config add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ssl/certs/ldap.homebox.world.issuer.crt ...
I have the (in)famous "Other (e.g., implementation specific) error (80)"
I also tried the example given here: https://access.redhat.com/articles/1474813
EECDH:EDH:CAMELLIA:ECDH:RSA:!eNULL:!SSLv2:!RC4:!DES:!EXP:!SEED:!IDEA:!3DES
Mozilla offers a tool called Configuration Generator to help with cipher suite strings at https://ssl-config.mozilla.org/.
If you want a firm posture while using a string like shown above, try the following. I've been using it for years without trouble.
"HIGH:!aNULL:!kRSA:!PSK:!SRP:!MD5:!RC4"
Here's the breakdown:
* HIGH - higher strength ciphers and key sizes. I believe this includes only 128-bit block ciphers with 128- or 256-bit keys. * !aNULL - no anonymous protocols or cipher suites * !kRSA - no key transport (RSA encryption), but allow server authentication with RSA (RSA signatures) * !PSK, !SRP - remove unneeded algorithms * !MD5, !RC4 - remove weak/wounded algorithms that may show up
Ironically, SRP and PSK are some of the stronger cipher suites in terms of security because they provide channel binding. But they are rarely used. Binding the channel means the client and server authentication are intertwined with the communication channel setup. If the client or server fails to authenticate, then the channel setup fails. An interception proxy or DLP will fail to setup the channel, and a user will know there's an active MitM.
The browsers hate SRP and PSK because they can't MitM the comms. The browsers prefer transport schemes like basic_auth, where a secret can be passed around.
But same "implementation specific error"
However, if I remove the cipher suite, the ldap modify command is working.
Jeff