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-required
> 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 <[email protected]> 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
