Hello,
I have configured OpenLDAP using SSL certificate, but I have a few issues.
Here the TLS configuration, especially "olcTLSProtocolMin: 3.3"
# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 c70363a6 dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcLogLevel: none olcPidFile: /var/run/slapd/slapd.pid olcToolThreads: 1 structuralObjectClass: olcGlobal entryUUID: 40ee991a-0efe-103d-855a-11ff3a5638b4 creatorsName: cn=config createTimestamp: 20221213065102Z olcPasswordCryptSaltFormat: $6$%.16s olcTLSCACertificateFile: /etc/ldap/certs/ldap.homebox.world.issuer.crt olcTLSCertificateKeyFile: /etc/ldap/certs/ldap.homebox.world.key olcTLSCertificateFile: /etc/ldap/certs/ldap.homebox.world.crt olcTLSProtocolMin: 3.3 entryCSN: 20221214054517.926245Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20221214054517Z
But if I try sslscan: I see TLSv1.0, TLSv1.1 and TLSv1.2 enabled. Why ?
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 enabled TLSv1.1 enabled TLSv1.2 enabled TLSv1.3 enabled
TLS Fallback SCSV: Server supports TLS Fallback SCSV
TLS renegotiation: Secure session renegotiation supported
TLS Compression: OpenSSL version does not support compression Rebuild with zlib1g-dev package for zlib support
Heartbleed: TLSv1.3 not vulnerable to heartbleed TLSv1.2 not vulnerable to heartbleed TLSv1.1 not vulnerable to heartbleed TLSv1.0 not vulnerable to heartbleed
Supported Server Cipher(s): Preferred TLSv1.3 128 bits TLS_AES_128_GCM_SHA256 Curve 25519 DHE 253 Accepted TLSv1.3 256 bits TLS_AES_256_GCM_SHA384 Curve 25519 DHE 253 Accepted TLSv1.3 256 bits TLS_CHACHA20_POLY1305_SHA256 Curve 25519 DHE 253 Accepted TLSv1.3 128 bits TLS_AES_128_CCM_SHA256 Curve 25519 DHE 253 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 Accepted TLSv1.2 256 bits AES256-GCM-SHA384 Accepted TLSv1.2 256 bits AES256-CCM Accepted TLSv1.2 128 bits AES128-GCM-SHA256 Accepted TLSv1.2 128 bits AES128-CCM Accepted TLSv1.2 256 bits AES256-SHA Accepted TLSv1.2 128 bits AES128-SHA Preferred TLSv1.1 256 bits ECDHE-RSA-AES256-SHA Curve 25519 DHE 253 Accepted TLSv1.1 128 bits ECDHE-RSA-AES128-SHA Curve 25519 DHE 253 Accepted TLSv1.1 256 bits AES256-SHA Accepted TLSv1.1 128 bits AES128-SHA Preferred TLSv1.0 256 bits ECDHE-RSA-AES256-SHA Curve 25519 DHE 253 Accepted TLSv1.0 128 bits ECDHE-RSA-AES128-SHA Curve 25519 DHE 253 Accepted TLSv1.0 256 bits AES256-SHA Accepted TLSv1.0 128 bits AES128-SHA
Server Key Exchange Group(s): TLSv1.3 128 bits secp256r1 (NIST P-256) TLSv1.3 192 bits secp384r1 (NIST P-384) TLSv1.3 260 bits secp521r1 (NIST P-521) TLSv1.3 128 bits x25519 TLSv1.3 224 bits x448 TLSv1.3 112 bits ffdhe2048 TLSv1.3 128 bits ffdhe3072 TLSv1.3 150 bits ffdhe4096 TLSv1.3 175 bits ffdhe6144 TLSv1.3 192 bits ffdhe8192 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
Thanks for your insights.
Andre
Hi,
Take a look at TLSCipherSuite
Erik
On Wed, Dec 14, 2022, 07:23 Andre Rodier andre@rodier.me wrote:
Hello,
I have configured OpenLDAP using SSL certificate, but I have a few issues.
Here the TLS configuration, especially "olcTLSProtocolMin: 3.3"
# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 c70363a6 dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcLogLevel: none olcPidFile: /var/run/slapd/slapd.pid olcToolThreads: 1 structuralObjectClass: olcGlobal entryUUID: 40ee991a-0efe-103d-855a-11ff3a5638b4 creatorsName: cn=config createTimestamp: 20221213065102Z olcPasswordCryptSaltFormat: $6$%.16s olcTLSCACertificateFile: /etc/ldap/certs/ldap.homebox.world.issuer.crt olcTLSCertificateKeyFile: /etc/ldap/certs/ldap.homebox.world.key olcTLSCertificateFile: /etc/ldap/certs/ldap.homebox.world.crt olcTLSProtocolMin: 3.3 entryCSN: 20221214054517.926245Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20221214054517Z
But if I try sslscan: I see TLSv1.0, TLSv1.1 and TLSv1.2 enabled. Why ?
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 enabled TLSv1.1 enabled TLSv1.2 enabled TLSv1.3 enabled
TLS Fallback SCSV: Server supports TLS Fallback SCSV
TLS renegotiation: Secure session renegotiation supported
TLS Compression: OpenSSL version does not support compression Rebuild with zlib1g-dev package for zlib support
Heartbleed: TLSv1.3 not vulnerable to heartbleed TLSv1.2 not vulnerable to heartbleed TLSv1.1 not vulnerable to heartbleed TLSv1.0 not vulnerable to heartbleed
Supported Server Cipher(s): Preferred TLSv1.3 128 bits TLS_AES_128_GCM_SHA256 Curve 25519
DHE 253
Accepted TLSv1.3 256 bits TLS_AES_256_GCM_SHA384 Curve 25519
DHE 253
Accepted TLSv1.3 256 bits TLS_CHACHA20_POLY1305_SHA256 Curve 25519
DHE 253
Accepted TLSv1.3 128 bits TLS_AES_128_CCM_SHA256 Curve 25519
DHE 253
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
Accepted TLSv1.2 256 bits AES256-GCM-SHA384 Accepted TLSv1.2 256 bits AES256-CCM Accepted TLSv1.2 128 bits AES128-GCM-SHA256 Accepted TLSv1.2 128 bits AES128-CCM Accepted TLSv1.2 256 bits AES256-SHA Accepted TLSv1.2 128 bits AES128-SHA Preferred TLSv1.1 256 bits ECDHE-RSA-AES256-SHA Curve 25519
DHE 253
Accepted TLSv1.1 128 bits ECDHE-RSA-AES128-SHA Curve 25519
DHE 253
Accepted TLSv1.1 256 bits AES256-SHA Accepted TLSv1.1 128 bits AES128-SHA Preferred TLSv1.0 256 bits ECDHE-RSA-AES256-SHA Curve 25519
DHE 253
Accepted TLSv1.0 128 bits ECDHE-RSA-AES128-SHA Curve 25519
DHE 253
Accepted TLSv1.0 256 bits AES256-SHA Accepted TLSv1.0 128 bits AES128-SHA
Server Key Exchange Group(s): TLSv1.3 128 bits secp256r1 (NIST P-256) TLSv1.3 192 bits secp384r1 (NIST P-384) TLSv1.3 260 bits secp521r1 (NIST P-521) TLSv1.3 128 bits x25519 TLSv1.3 224 bits x448 TLSv1.3 112 bits ffdhe2048 TLSv1.3 128 bits ffdhe3072 TLSv1.3 150 bits ffdhe4096 TLSv1.3 175 bits ffdhe6144 TLSv1.3 192 bits ffdhe8192 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
Thanks for your insights.
Andre
On 14/12/2022 07:32, Erik de Waard wrote:
Hi,
Take a look at TLSCipherSuite
Erik
On Wed, Dec 14, 2022, 07:23 Andre Rodier <andre@rodier.me mailto:andre@rodier.me> wrote:
Hello, I have configured OpenLDAP using SSL certificate, but I have a few issues. Here the TLS configuration, especially "olcTLSProtocolMin: 3.3" > # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. > # CRC32 c70363a6 > dn: cn=config > objectClass: olcGlobal > cn: config > olcArgsFile: /var/run/slapd/slapd.args > olcLogLevel: none > olcPidFile: /var/run/slapd/slapd.pid > olcToolThreads: 1 > structuralObjectClass: olcGlobal > entryUUID: 40ee991a-0efe-103d-855a-11ff3a5638b4 > creatorsName: cn=config > createTimestamp: 20221213065102Z > olcPasswordCryptSaltFormat: $6$%.16s > olcTLSCACertificateFile: /etc/ldap/certs/ldap.homebox.world.issuer.crt > olcTLSCertificateKeyFile: /etc/ldap/certs/ldap.homebox.world.key > olcTLSCertificateFile: /etc/ldap/certs/ldap.homebox.world.crt > olcTLSProtocolMin: 3.3 > entryCSN: 20221214054517.926245Z#000000#000#000000 > modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > modifyTimestamp: 20221214054517Z But if I try sslscan: I see TLSv1.0, TLSv1.1 and TLSv1.2 enabled. Why ? > 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 enabled > TLSv1.1 enabled > TLSv1.2 enabled > TLSv1.3 enabled > > TLS Fallback SCSV: > Server supports TLS Fallback SCSV > > TLS renegotiation: > Secure session renegotiation supported > > TLS Compression: > OpenSSL version does not support compression > Rebuild with zlib1g-dev package for zlib support > > Heartbleed: > TLSv1.3 not vulnerable to heartbleed > TLSv1.2 not vulnerable to heartbleed > TLSv1.1 not vulnerable to heartbleed > TLSv1.0 not vulnerable to heartbleed > > Supported Server Cipher(s): > Preferred TLSv1.3 128 bits TLS_AES_128_GCM_SHA256 Curve 25519 DHE 253 > Accepted TLSv1.3 256 bits TLS_AES_256_GCM_SHA384 Curve 25519 DHE 253 > Accepted TLSv1.3 256 bits TLS_CHACHA20_POLY1305_SHA256 Curve 25519 DHE 253 > Accepted TLSv1.3 128 bits TLS_AES_128_CCM_SHA256 Curve 25519 DHE 253 > 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 > Accepted TLSv1.2 256 bits AES256-GCM-SHA384 > Accepted TLSv1.2 256 bits AES256-CCM > Accepted TLSv1.2 128 bits AES128-GCM-SHA256 > Accepted TLSv1.2 128 bits AES128-CCM > Accepted TLSv1.2 256 bits AES256-SHA > Accepted TLSv1.2 128 bits AES128-SHA > Preferred TLSv1.1 256 bits ECDHE-RSA-AES256-SHA Curve 25519 DHE 253 > Accepted TLSv1.1 128 bits ECDHE-RSA-AES128-SHA Curve 25519 DHE 253 > Accepted TLSv1.1 256 bits AES256-SHA > Accepted TLSv1.1 128 bits AES128-SHA > Preferred TLSv1.0 256 bits ECDHE-RSA-AES256-SHA Curve 25519 DHE 253 > Accepted TLSv1.0 128 bits ECDHE-RSA-AES128-SHA Curve 25519 DHE 253 > Accepted TLSv1.0 256 bits AES256-SHA > Accepted TLSv1.0 128 bits AES128-SHA > > Server Key Exchange Group(s): > TLSv1.3 128 bits secp256r1 (NIST P-256) > TLSv1.3 192 bits secp384r1 (NIST P-384) > TLSv1.3 260 bits secp521r1 (NIST P-521) > TLSv1.3 128 bits x25519 > TLSv1.3 224 bits x448 > TLSv1.3 112 bits ffdhe2048 > TLSv1.3 128 bits ffdhe3072 > TLSv1.3 150 bits ffdhe4096 > TLSv1.3 175 bits ffdhe6144 > TLSv1.3 192 bits ffdhe8192 > 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 Thanks for your insights. Andre
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
add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/certs/ldap.homebox.world.crt
add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ssl/private/ldap.homebox.world.key
add: olcTLSProtocolMin olcTLSProtocolMin: 3.3
add: olcTLSCipherSuite olcTLSCipherSuite: HIGH
And then, when I try to set the cipher suite:
root@main:/etc/ldap/changes# ldapmodify -QY EXTERNAL -H ldapi:/// -d 99 -f /etc/ldap/changes/ssl-config.ldif ldap_url_parse_ext(ldapi:///) ldap_create ldap_url_parse_ext(ldapi:///??base) ldap_sasl_interactive_bind: user selected: EXTERNAL ldap_int_sasl_bind: EXTERNAL ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_path ldap_new_socket: 4 ldap_connect_to_path: Trying /var/run/slapd/ldapi ldap_connect_timeout: fd: 4 tm: -1 async: 0 ldap_ndelay_on: 4 ldap_ndelay_off: 4 ldap_int_sasl_open: host=main ldap_sasl_bind ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({i) ber: ber_flush2: 26 bytes to sd > ldap_write: want=26, written=26 0000: 30 18 02 01 01 60 13 02 01 03 04 00 a3 0c 04 08 0....`.......... 0010: 45 58 54 45 52 4e 41 4c 04 00 EXTERNAL.. ldap_msgfree ldap_result ld 0x5615325c7bd0 msgid 1 wait4msg ld 0x5615325c7bd0 msgid 1 (infinite timeout) wait4msg continue ld 0x5615325c7bd0 msgid 1 all 1 ** ld 0x5615325c7bd0 Connections:
- host: (null) port: 0 (default) refcnt: 2 status: Connected last used: Wed Dec 14 05:47:30 2022
** ld 0x5615325c7bd0 Outstanding Requests:
- msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0
ld 0x5615325c7bd0 request count 1 (abandoned 0) ** ld 0x5615325c7bd0 Response Queue: Empty ld 0x5615325c7bd0 response count 0 ldap_chkResponseList ld 0x5615325c7bd0 msgid 1 all 1 ldap_chkResponseList returns ld 0x5615325c7bd0 NULL ldap_int_select read1msg: ld 0x5615325c7bd0 msgid 1 all 1 ber_get_next ldap_read: want=8, got=8 0000: 30 0c 02 01 01 61 07 0a 0....a.. ldap_read: want=6, got=6 0000: 01 00 04 00 04 00 ...... ber_get_next: tag 0x30 len 12 contents: read1msg: ld 0x5615325c7bd0 msgid 1 message type bind ber_scanf fmt ({eAA) ber: read1msg: ld 0x5615325c7bd0 0 new referrals read1msg: mark request completed, ld 0x5615325c7bd0 msgid 1 request done: ld 0x5615325c7bd0 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_int_sasl_bind: EXTERNAL ldap_parse_sasl_bind_result ber_scanf fmt ({eAA) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree modifying entry "cn=config" ldap_modify_ext ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 54 bytes to sd 4 ldap_write: want=54, written=54 0000: 30 34 02 01 02 66 2f 04 09 63 6e 3d 63 6f 6e 66 04...f/..cn=conf 0010: 69 67 30 22 30 20 0a 01 00 30 1b 04 11 6f 6c 63 ig0"0 ...0...olc 0020: 54 4c 53 43 69 70 68 65 72 53 75 69 74 65 31 06 TLSCipherSuite1. 0030: 04 04 48 49 47 48 ..HIGH ldap_result ld 0x5615325c7bd0 msgid 2 wait4msg ld 0x5615325c7bd0 msgid 2 (timeout 100000 usec) wait4msg continue ld 0x5615325c7bd0 msgid 2 all 1 ** ld 0x5615325c7bd0 Connections:
- host: (null) port: 0 (default) refcnt: 2 status: Connected last used: Wed Dec 14 05:47:30 2022
** ld 0x5615325c7bd0 Outstanding Requests:
- msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0
ld 0x5615325c7bd0 request count 1 (abandoned 0) ** ld 0x5615325c7bd0 Response Queue: Empty ld 0x5615325c7bd0 response count 0 ldap_chkResponseList ld 0x5615325c7bd0 msgid 2 all 1 ldap_chkResponseList returns ld 0x5615325c7bd0 NULL ldap_int_select read1msg: ld 0x5615325c7bd0 msgid 2 all 1 ber_get_next ldap_read: want=8, got=8 0000: 30 0c 02 01 02 67 07 0a 0....g.. ldap_read: want=6, got=6 0000: 01 50 04 00 04 00 .P.... ber_get_next: tag 0x30 len 12 contents: read1msg: ld 0x5615325c7bd0 msgid 2 message type modify ber_scanf fmt ({eAA) ber: read1msg: ld 0x5615325c7bd0 0 new referrals read1msg: mark request completed, ld 0x5615325c7bd0 msgid 2 request done: ld 0x5615325c7bd0 msgid 2 res_errno: 80, res_error: <>, res_matched: <> ldap_free_request (origid 2, msgid 2) ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree ldap_err2string ldap_modify: Other (e.g., implementation specific) error (80)
ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 4 ldap_write: want=7, written=7 0000: 30 05 02 01 03 42 00 0....B. ldap_free_connection: actually freed
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
But same "implementation specific error"
However, if I remove the cipher suite, the ldap modify command is working.
Thanks for any advice.
Try "NORMAL:-RSA"
Your version is probably build against gnutls instead of openssl
See: the manual on TLSCipherSuite
On Wed, Dec 14, 2022, 08:41 Andre Rodier andre@rodier.me wrote:
On 14/12/2022 07:32, Erik de Waard wrote:
Hi,
Take a look at TLSCipherSuite
Erik
On Wed, Dec 14, 2022, 07:23 Andre Rodier <andre@rodier.me <mailto:
andre@rodier.me>> wrote:
Hello, I have configured OpenLDAP using SSL certificate, but I have a fewissues.
Here the TLS configuration, especially "olcTLSProtocolMin: 3.3" > # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. > # CRC32 c70363a6 > dn: cn=config > objectClass: olcGlobal > cn: config > olcArgsFile: /var/run/slapd/slapd.args > olcLogLevel: none > olcPidFile: /var/run/slapd/slapd.pid > olcToolThreads: 1 > structuralObjectClass: olcGlobal > entryUUID: 40ee991a-0efe-103d-855a-11ff3a5638b4 > creatorsName: cn=config > createTimestamp: 20221213065102Z > olcPasswordCryptSaltFormat: $6$%.16s > olcTLSCACertificateFile:/etc/ldap/certs/ldap.homebox.world.issuer.crt
> olcTLSCertificateKeyFile: /etc/ldap/certs/ldap.homebox.world.key > olcTLSCertificateFile: /etc/ldap/certs/ldap.homebox.world.crt > olcTLSProtocolMin: 3.3 > entryCSN: 20221214054517.926245Z#000000#000#000000 > modifiersName:gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
> modifyTimestamp: 20221214054517Z But if I try sslscan: I see TLSv1.0, TLSv1.1 and TLSv1.2 enabled.Why ?
> 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 nameldap.homebox.world
> > SSL/TLS Protocols: > SSLv2 disabled > SSLv3 disabled > TLSv1.0 enabled > TLSv1.1 enabled > TLSv1.2 enabled > TLSv1.3 enabled > > TLS Fallback SCSV: > Server supports TLS Fallback SCSV > > TLS renegotiation: > Secure session renegotiation supported > > TLS Compression: > OpenSSL version does not support compression > Rebuild with zlib1g-dev package for zlib support > > Heartbleed: > TLSv1.3 not vulnerable to heartbleed > TLSv1.2 not vulnerable to heartbleed > TLSv1.1 not vulnerable to heartbleed > TLSv1.0 not vulnerable to heartbleed > > Supported Server Cipher(s): > Preferred TLSv1.3 128 bits TLS_AES_128_GCM_SHA256 Curve25519 DHE 253
> Accepted TLSv1.3 256 bits TLS_AES_256_GCM_SHA384 Curve25519 DHE 253
> Accepted TLSv1.3 256 bits TLS_CHACHA20_POLY1305_SHA256 Curve25519 DHE 253
> Accepted TLSv1.3 128 bits TLS_AES_128_CCM_SHA256 Curve25519 DHE 253
> Preferred TLSv1.2 256 bits ECDHE-RSA-AES256-GCM-SHA384 Curve25519 DHE 253
> Accepted TLSv1.2 256 bits ECDHE-RSA-CHACHA20-POLY1305 Curve25519 DHE 253
> Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-GCM-SHA256 Curve25519 DHE 253
> Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA Curve25519 DHE 253
> Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA Curve25519 DHE 253
> Accepted TLSv1.2 256 bits AES256-GCM-SHA384 > Accepted TLSv1.2 256 bits AES256-CCM > Accepted TLSv1.2 128 bits AES128-GCM-SHA256 > Accepted TLSv1.2 128 bits AES128-CCM > Accepted TLSv1.2 256 bits AES256-SHA > Accepted TLSv1.2 128 bits AES128-SHA > Preferred TLSv1.1 256 bits ECDHE-RSA-AES256-SHA Curve25519 DHE 253
> Accepted TLSv1.1 128 bits ECDHE-RSA-AES128-SHA Curve25519 DHE 253
> Accepted TLSv1.1 256 bits AES256-SHA > Accepted TLSv1.1 128 bits AES128-SHA > Preferred TLSv1.0 256 bits ECDHE-RSA-AES256-SHA Curve25519 DHE 253
> Accepted TLSv1.0 128 bits ECDHE-RSA-AES128-SHA Curve25519 DHE 253
> Accepted TLSv1.0 256 bits AES256-SHA > Accepted TLSv1.0 128 bits AES128-SHA > > Server Key Exchange Group(s): > TLSv1.3 128 bits secp256r1 (NIST P-256) > TLSv1.3 192 bits secp384r1 (NIST P-384) > TLSv1.3 260 bits secp521r1 (NIST P-521) > TLSv1.3 128 bits x25519 > TLSv1.3 224 bits x448 > TLSv1.3 112 bits ffdhe2048 > TLSv1.3 128 bits ffdhe3072 > TLSv1.3 150 bits ffdhe4096 > TLSv1.3 175 bits ffdhe6144 > TLSv1.3 192 bits ffdhe8192 > 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 Thanks for your insights. AndreWell, 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
add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/certs/ldap.homebox.world.crt
add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ssl/private/ldap.homebox.world.key
add: olcTLSProtocolMin olcTLSProtocolMin: 3.3
add: olcTLSCipherSuite olcTLSCipherSuite: HIGH
And then, when I try to set the cipher suite:
root@main:/etc/ldap/changes# ldapmodify -QY EXTERNAL -H ldapi:/// -d 99
-f /etc/ldap/changes/ssl-config.ldif
ldap_url_parse_ext(ldapi:///) ldap_create ldap_url_parse_ext(ldapi:///??base) ldap_sasl_interactive_bind: user selected: EXTERNAL ldap_int_sasl_bind: EXTERNAL ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_path ldap_new_socket: 4 ldap_connect_to_path: Trying /var/run/slapd/ldapi ldap_connect_timeout: fd: 4 tm: -1 async: 0 ldap_ndelay_on: 4 ldap_ndelay_off: 4 ldap_int_sasl_open: host=main ldap_sasl_bind ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({i) ber: ber_flush2: 26 bytes to sd > ldap_write: want=26, written=26 0000: 30 18 02 01 01 60 13 02 01 03 04 00 a3 0c 04 08
0....`..........
0010: 45 58 54 45 52 4e 41 4c 04 00 EXTERNAL.. ldap_msgfree ldap_result ld 0x5615325c7bd0 msgid 1 wait4msg ld 0x5615325c7bd0 msgid 1 (infinite timeout) wait4msg continue ld 0x5615325c7bd0 msgid 1 all 1 ** ld 0x5615325c7bd0 Connections:
- host: (null) port: 0 (default) refcnt: 2 status: Connected last used: Wed Dec 14 05:47:30 2022
** ld 0x5615325c7bd0 Outstanding Requests:
- msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0
ld 0x5615325c7bd0 request count 1 (abandoned 0) ** ld 0x5615325c7bd0 Response Queue: Empty ld 0x5615325c7bd0 response count 0 ldap_chkResponseList ld 0x5615325c7bd0 msgid 1 all 1 ldap_chkResponseList returns ld 0x5615325c7bd0 NULL ldap_int_select read1msg: ld 0x5615325c7bd0 msgid 1 all 1 ber_get_next ldap_read: want=8, got=8 0000: 30 0c 02 01 01 61 07 0a 0....a.. ldap_read: want=6, got=6 0000: 01 00 04 00 04 00 ...... ber_get_next: tag 0x30 len 12 contents: read1msg: ld 0x5615325c7bd0 msgid 1 message type bind ber_scanf fmt ({eAA) ber: read1msg: ld 0x5615325c7bd0 0 new referrals read1msg: mark request completed, ld 0x5615325c7bd0 msgid 1 request done: ld 0x5615325c7bd0 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_int_sasl_bind: EXTERNAL ldap_parse_sasl_bind_result ber_scanf fmt ({eAA) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree modifying entry "cn=config" ldap_modify_ext ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 54 bytes to sd 4 ldap_write: want=54, written=54 0000: 30 34 02 01 02 66 2f 04 09 63 6e 3d 63 6f 6e 66
04...f/..cn=conf
0010: 69 67 30 22 30 20 0a 01 00 30 1b 04 11 6f 6c 63 ig0"0
...0...olc
0020: 54 4c 53 43 69 70 68 65 72 53 75 69 74 65 31 06
TLSCipherSuite1.
0030: 04 04 48 49 47 48 ..HIGH ldap_result ld 0x5615325c7bd0 msgid 2 wait4msg ld 0x5615325c7bd0 msgid 2 (timeout 100000 usec) wait4msg continue ld 0x5615325c7bd0 msgid 2 all 1 ** ld 0x5615325c7bd0 Connections:
- host: (null) port: 0 (default) refcnt: 2 status: Connected last used: Wed Dec 14 05:47:30 2022
** ld 0x5615325c7bd0 Outstanding Requests:
- msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0
ld 0x5615325c7bd0 request count 1 (abandoned 0) ** ld 0x5615325c7bd0 Response Queue: Empty ld 0x5615325c7bd0 response count 0 ldap_chkResponseList ld 0x5615325c7bd0 msgid 2 all 1 ldap_chkResponseList returns ld 0x5615325c7bd0 NULL ldap_int_select read1msg: ld 0x5615325c7bd0 msgid 2 all 1 ber_get_next ldap_read: want=8, got=8 0000: 30 0c 02 01 02 67 07 0a 0....g.. ldap_read: want=6, got=6 0000: 01 50 04 00 04 00 .P.... ber_get_next: tag 0x30 len 12 contents: read1msg: ld 0x5615325c7bd0 msgid 2 message type modify ber_scanf fmt ({eAA) ber: read1msg: ld 0x5615325c7bd0 0 new referrals read1msg: mark request completed, ld 0x5615325c7bd0 msgid 2 request done: ld 0x5615325c7bd0 msgid 2 res_errno: 80, res_error: <>, res_matched: <> ldap_free_request (origid 2, msgid 2) ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree ldap_err2string ldap_modify: Other (e.g., implementation specific) error (80)
ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 4 ldap_write: want=7, written=7 0000: 30 05 02 01 03 42 00 0....B. ldap_free_connection: actually freed
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
But same "implementation specific error"
However, if I remove the cipher suite, the ldap modify command is working.
Thanks for any advice.
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
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é
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
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
On Wed, 14 Dec 2022, Stuart Henderson wrote:
On 2022/12/14 06:22, Andre Rodier wrote:
olcTLSProtocolMin: 3.3
There is no TLS 3.3; try a valid version like 1.2 or 1.3.
No, that's correct. slapd.conf(5):
TLSProtocolMin <major>[.<minor>] Specifies minimum SSL/TLS protocol version that will be negotiated. If the server doesn't support at least that version, the SSL handshake will fail. To require TLS 1.x or higher, set this option to 3.(x+1), e.g.,
TLSProtocolMin 3.2
would require TLS 1.1. Specifying a minimum that is higher than that supported by the OpenLDAP implementation will result in it requiring the highest level that it does support. This directive is ignored with GnuTLS.
I wrote that code for openldap back when SSL 3 was still common so it (ugh) matches how the version number was carried in the TLS handshake. Do now I regret settling on that interface? Yes, but it's Not My Problem.
Andre is almost certainly using an OpenLDAP linked against gnuTLS which has to be configured (including protocol version) using a gnuTLS-style cipher string.
Philip Guenther
On Wed, Dec 14, 2022 at 4:29 AM Philip Guenther pguenther@proofpoint.com wrote:
On Wed, 14 Dec 2022, Stuart Henderson wrote:
On 2022/12/14 06:22, Andre Rodier wrote:
olcTLSProtocolMin: 3.3
There is no TLS 3.3; try a valid version like 1.2 or 1.3.
No, that's correct. slapd.conf(5):
TLSProtocolMin <major>[.<minor>] Specifies minimum SSL/TLS protocol version that will be negotiated. If the server doesn't support at least that version, the SSL handshake will fail. To require TLS 1.x or higher, set this option to 3.(x+1), e.g., TLSProtocolMin 3.2 would require TLS 1.1. Specifying a minimum that is higher than that supported by the OpenLDAP implementation will result in it requiring the highest level that it does support. This directive is ignored with GnuTLS.
A small nit... There is no SSL/TLS minimum and maximum version numbers.
There's a Record Layer version number [1] and a Handshake Protocol version number.[2] They do not specify a range.
Years ago I argued the TLS Working Group should interpret them as min and max version numbers because that's how people interpreted them. Min and max matched the mental models of users. The Working Group rejected the arguments stating the min-max range could have holes in it. That is, a server may support TLS 1.0 and 1.3, but lack TLS 1.1 and 1.2 support.
[1] https://www.rfc-editor.org/rfc/rfc5246.html#section-6.2 [2] https://www.rfc-editor.org/rfc/rfc5246.html#section-7.3
Jeff
On Wed, 14 Dec 2022, Jeffrey Walton wrote:
On Wed, Dec 14, 2022 at 4:29 AM Philip Guenther pguenther@proofpoint.com wrote:
On Wed, 14 Dec 2022, Stuart Henderson wrote:
On 2022/12/14 06:22, Andre Rodier wrote:
olcTLSProtocolMin: 3.3
There is no TLS 3.3; try a valid version like 1.2 or 1.3.
No, that's correct. slapd.conf(5):
TLSProtocolMin <major>[.<minor>] Specifies minimum SSL/TLS protocol version that will be negotiated. If the server doesn't support at least that version, the SSL handshake will fail. To require TLS 1.x or higher, set this option to 3.(x+1), e.g., TLSProtocolMin 3.2 would require TLS 1.1. Specifying a minimum that is higher than that supported by the OpenLDAP implementation will result in it requiring the highest level that it does support. This directive is ignored with GnuTLS.A small nit... There is no SSL/TLS minimum and maximum version numbers.
Your statement may be true in the context of the on-the-wire TLS representation, but the above quote is about TLS versions supported by slapd, which does have a minimum whenever TLS is enabled at all.
My recall is that OpenSSL's TLSv1.3 support involves a bunch of new functions. Hopefully OpenLDAP's support for that does or will include whatever it takes to make TLSProtocolMin 3.4 disable TLS v1.[012].
...
Years ago I argued the TLS Working Group should interpret them as min and max version numbers because that's how people interpreted them.
I certainly agree with you that people really want to think of protocol version support as a range.
Min and max matched the mental models of users. The Working Group rejected the arguments stating the min-max range could have holes in it. That is, a server may support TLS 1.0 and 1.3, but lack TLS 1.1 and 1.2 support.
That's hilarious, because that sort of config will have clients fail the TLS handshake with version mismatch despite having a common supported version: if the other side does 1.0 and either 1.1 or 1.2, but not 1.3, then it'll fail despite both supporting 1.0. Very few clients do any sort of retry while offering fewer version. If WG members claimed that non-contiguous versions are reliable in practice they would be incorrect.
Philip Guenther
On Wed, Dec 14, 2022 at 4:13 AM Stuart Henderson stu@spacehopper.org wrote:
On 2022/12/14 06:22, Andre Rodier wrote:
olcTLSProtocolMin: 3.3
There is no TLS 3.3; try a valid version like 1.2 or 1.3.
That's following the record version [1] specified in the RFC. While "TLS 3.3" does not exist, Record Layer ProtocolVersion = 3.3 does exist.
[1] https://www.rfc-editor.org/rfc/rfc5246.html#section-6.2
Jeff
Good morning,
I'm trying to configure ppolicy_forward_updates to master from slaves on Symas OpenLDAP 2.6.9, so that both successful authentications (ppolicy attribute pwdLastSuccess) and failed authentications (ppolicy attribute pwdFailureTime) get forwarded and written on the master.
Following some documentation [1] [2] I have configured on the slave:
* chain overlay in order to define how to connect to master (credentials, tls, etc) * updateref (after syncrepl section), in order to define where to send updates * ppolicy_forward_updates, in order to define that ppolicy operations must be forwarded.
I have also configured lastbind overlay to define desired precision to save pwdLastSuccess, and this is working perfectly on the master server. Both attributes (pwdLastSuccess and pwdFailureTime) are respectively being updated flawlessly when binding to the master server. Syncrepl between master and slave is also working properly, so that they both get replicated to the slave.
But when binding to the slave, the "ppolicy forward updates" functionality is not working and I can not find out why. I have looked at the usual suspects, as ACL permissions on master, connectivity, etc.
But after some debugging I don't see the slave trying to connect to the master (using tcpdump on the slave I can not see any traffic), so I have discarded any problems on the master itself (ACL), and I am guessing that the problem is on the slave part.
When trying to further debug the problem, I can see on the slave server:
* On *successful* auths, when trying to write pwdLastSuccess:
slapd[320250]: send_ldap_result: err=53 matched="" text="operation restricted" slapd[320250]: conn=1002 op=0 ppolicy_bind_response: ppolicy state change failed with rc=53 text=operation restricted slapd[320250]: conn=1002 op=0 RESULT tag=97 err=0 qtime=0.000005 etime=0.000335 text= slapd[320250]: connection_get(23)
* On *failed* auths, when trying to write pwdFailureTime:
slapd[320250]: send_ldap_result: err=49 matched="" text="" slapd[320250]: => mdb_entry_get: ndn: "<<userdn_redacted>>" slapd[320250]: => mdb_entry_get: oc: "(null)", at: "(null)" slapd[320250]: => mdb_entry_get: found entry: "<<userdn_redacted>>" slapd[320250]: send_ldap_result: err=53 matched="" text="operation restricted" slapd[320250]: conn=1003 op=0 ppolicy_bind_response: ppolicy state change failed with rc=53 text=operation restricted slapd[320250]: conn=1003 op=0 RESULT tag=97 err=49 qtime=0.000013 etime=0.000601 text= slapd[320250]: connection_get(23) slapd[320250]: conn=1003 op=1 UNBIND slapd[320250]: conn=1003 fd=23 close
And I am not able to get more detailed information to find out why this operation is restricted.
"ppolicy_bind_response" messages makes me suppose that it is indeed trying to bind somewhere, but I am not seeing any connection trying to be made outside the slave server. Is there some way to check where it is trying to bind?
I don't know where else to look in order to find out what 's wrong.
Anyone have any tips?
Thank you so much for your help.
[1] https://kb.symas.com/en_US/configuration/configuring-ppolicy-for-openldap-25 [2] https://kb.symas.com/en_US/configuration/referrals-and-chaining)
------------------------------ *Oscar Remírez de Ganuza Satrústegui* Technology and IT Operations IT Services
T: +34 948425600 x803130 oscarrdg@unav.es ------------------------------ [image: Universidad de Navarra] http://www.unav.edu/
Good morning everyone,
I'm pleased to report that I've identified and resolved the issue concerning ppolicy attribute updates on the slave server.
The root cause was the 'readonly on' setting configured on the slave. This option, historically used to prevent direct modify operations on the slave, was being evaluated *before* the attempt to bind to the master server for the ppolicy attribute update. Consequently, the update operation was blocked by the slave's read-only status.
Disabling this 'readonly on' option allowed the modify operations to be successfully forwarded to the master server. To maintain the desired security and control, I have configured specific ACLs on the master server. These ACLs now permit updates *only* on the ppolicy attributes for operations originating from the slave, preventing other standard modify operations against the slave from succeeding via this path.
Everything is now functioning as expected. I wanted to share this resolution in case it could help others who might encounter a similar debugging scenario in the future.
Thanks for your work and patience.
Regards,
On Thu, May 15, 2025 at 2:02 PM Óscar Remírez De Ganuza Satrústegui < oscarrdg@unav.es> wrote:
Good morning,
I'm trying to configure ppolicy_forward_updates to master from slaves on Symas OpenLDAP 2.6.9, so that both successful authentications (ppolicy attribute pwdLastSuccess) and failed authentications (ppolicy attribute pwdFailureTime) get forwarded and written on the master.
Following some documentation [1] [2] I have configured on the slave:
- chain overlay in order to define how to connect to master (credentials,
tls, etc)
- updateref (after syncrepl section), in order to define where to send
updates
- ppolicy_forward_updates, in order to define that ppolicy operations must
be forwarded.
I have also configured lastbind overlay to define desired precision to save pwdLastSuccess, and this is working perfectly on the master server. Both attributes (pwdLastSuccess and pwdFailureTime) are respectively being updated flawlessly when binding to the master server. Syncrepl between master and slave is also working properly, so that they both get replicated to the slave.
But when binding to the slave, the "ppolicy forward updates" functionality is not working and I can not find out why. I have looked at the usual suspects, as ACL permissions on master, connectivity, etc.
But after some debugging I don't see the slave trying to connect to the master (using tcpdump on the slave I can not see any traffic), so I have discarded any problems on the master itself (ACL), and I am guessing that the problem is on the slave part.
When trying to further debug the problem, I can see on the slave server:
- On *successful* auths, when trying to write pwdLastSuccess:
slapd[320250]: send_ldap_result: err=53 matched="" text="operation restricted" slapd[320250]: conn=1002 op=0 ppolicy_bind_response: ppolicy state change failed with rc=53 text=operation restricted slapd[320250]: conn=1002 op=0 RESULT tag=97 err=0 qtime=0.000005 etime=0.000335 text= slapd[320250]: connection_get(23)
- On *failed* auths, when trying to write pwdFailureTime:
slapd[320250]: send_ldap_result: err=49 matched="" text="" slapd[320250]: => mdb_entry_get: ndn: "<<userdn_redacted>>" slapd[320250]: => mdb_entry_get: oc: "(null)", at: "(null)" slapd[320250]: => mdb_entry_get: found entry: "<<userdn_redacted>>" slapd[320250]: send_ldap_result: err=53 matched="" text="operation restricted" slapd[320250]: conn=1003 op=0 ppolicy_bind_response: ppolicy state change failed with rc=53 text=operation restricted slapd[320250]: conn=1003 op=0 RESULT tag=97 err=49 qtime=0.000013 etime=0.000601 text= slapd[320250]: connection_get(23) slapd[320250]: conn=1003 op=1 UNBIND slapd[320250]: conn=1003 fd=23 close
And I am not able to get more detailed information to find out why this operation is restricted.
"ppolicy_bind_response" messages makes me suppose that it is indeed trying to bind somewhere, but I am not seeing any connection trying to be made outside the slave server. Is there some way to check where it is trying to bind?
I don't know where else to look in order to find out what 's wrong.
Anyone have any tips?
Thank you so much for your help.
[1] https://kb.symas.com/en_US/configuration/configuring-ppolicy-for-openldap-25 [2] https://kb.symas.com/en_US/configuration/referrals-and-chaining)
*Oscar Remírez de Ganuza Satrústegui* Technology and IT Operations IT Services
T: +34 948425600 x803130 oscarrdg@unav.es
[image: Universidad de Navarra] http://www.unav.edu/
openldap-technical@openldap.org
-
Andre Rodier -
Erik de Waard -
Jeffrey Walton -
Philip Guenther -
Stuart Henderson -
Óscar Remírez De Ganuza Satrústegui