Hi
I've followed the instructions in https://www.openldap.org/doc/admin26/quickstart.html to deploy openldap 2.6.4 on a SLES 15 SP4 system. Once I confirmed that this was working correctly, I moved on to configure TLS, following the instructions in https://www.openldap.org/doc/admin26/tls.html. When I try a connection to the LDAPS port (636), I see the following:
ldpdd040:~ # openssl s_client -connect ldpdd042.hop.lab.emc.com:636 CONNECTED(00000003) 139702302594704: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 293 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated 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: 1683823897 Timeout : 300 (sec) Verify return code: 0 (ok) --- ldpdd040:~ #
I'm using this command to start slapd: /usr/local/libexec/slapd -F /usr/local/etc/slapd.d -s 3 -h "ldap:/// ldaps:///"
When I execute the openssl command above, I look in /var/log/messages and see:
2023-05-11T12:51:55.213884-04:00 ldpdd042 slapd[20101]: conn=1000 fd=12 ACCEPT from IP=10.247.229.40:56844 (IP=0.0.0.0:636) 2023-05-11T12:51:55.213944-04:00 ldpdd042 slapd[20101]: connection_get(12): got connid=1000 2023-05-11T12:51:55.214004-04:00 ldpdd042 slapd[20101]: connection_read(12): checking for input on id=1000 2023-05-11T12:51:55.214065-04:00 ldpdd042 slapd[20101]: connection_read(12): TLS accept failure error=-1 id=1000, closing 2023-05-11T12:51:55.214138-04:00 ldpdd042 slapd[20101]: connection_close: conn=1000 sd=12 2023-05-11T12:51:55.214207-04:00 ldpdd042 slapd[20101]: conn=1000 fd=12 closed (TLS negotiation failure) ldpdd0
I've appended these lines to /usr/local/etc/openldap/slapd.conf:
# Added TLS directives # TLSCACertificateFile /var/lib/ca-certificates/ca-bundle.pem TLSCertificateFile /etc/ssl/private/server.cert TLSCertificateKeyFile /etc/ssl/private/server.key #TLSCipherSuite ALL
I can't find any log information that helps me understand what the problem is. I'm using a self-signed server certificate that has the cn using the FQDN of the server.
How can I debug this?
Thanks! tl
terry.lemons@dell.com wrote:
Hi
I've followed the instructions in https://www.openldap.org/doc/admin26/quickstart.html to deploy openldap 2.6.4 on a SLES 15 SP4 system. Once I confirmed that this was working correctly, I moved on to configure TLS, following the instructions in https://www.openldap.org/doc/admin26/tls.html. When I try a connection to the LDAPS port (636), I see the following:
ldpdd040:~ # openssl s_client -connect ldpdd042.hop.lab.emc.com:636
If you're going to use openssl s_client you also need to tell it which CA and/or server certs to trust. I'd start with using ldapsearch -d -1 instead.
CONNECTED(00000003) 139702302594704: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 293 bytes
New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated 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: 1683823897 Timeout : 300 (sec) Verify return code: 0 (ok)
ldpdd040:~ #
I'm using this command to start slapd: /usr/local/libexec/slapd -F /usr/local/etc/slapd.d -s 3 -h "ldap:/// ldaps:///"
When I execute the openssl command above, I look in /var/log/messages and see:
2023-05-11T12:51:55.213884-04:00 ldpdd042 slapd[20101]: conn=1000 fd=12 ACCEPT from IP=10.247.229.40:56844 (IP=0.0.0.0:636) 2023-05-11T12:51:55.213944-04:00 ldpdd042 slapd[20101]: connection_get(12): got connid=1000 2023-05-11T12:51:55.214004-04:00 ldpdd042 slapd[20101]: connection_read(12): checking for input on id=1000 2023-05-11T12:51:55.214065-04:00 ldpdd042 slapd[20101]: connection_read(12): TLS accept failure error=-1 id=1000, closing 2023-05-11T12:51:55.214138-04:00 ldpdd042 slapd[20101]: connection_close: conn=1000 sd=12 2023-05-11T12:51:55.214207-04:00 ldpdd042 slapd[20101]: conn=1000 fd=12 closed (TLS negotiation failure) ldpdd0
I've appended these lines to /usr/local/etc/openldap/slapd.conf:
# Added TLS directives # TLSCACertificateFile /var/lib/ca-certificates/ca-bundle.pem TLSCertificateFile /etc/ssl/private/server.cert TLSCertificateKeyFile /etc/ssl/private/server.key #TLSCipherSuite ALL
I can't find any log information that helps me understand what the problem is. I'm using a self-signed server certificate that has the cn using the FQDN of the server.
How can I debug this?
Thanks! tl
Hi Howard
Thanks very much for the reply and the suggestion. Here is the output of a ldapsearch command that completes successfully when I omit '-H ldaps://ldpdd042.hop.lab.emc.com:636':
ldpdd042:~ # ldapsearch -d -1 -x -b 'dc=example,dc=com' '(objectclass=*)' -H ldaps://ldpdd042.hop.lab.emc.com:636 ldap_url_parse_ext(ldaps://ldpdd042.hop.lab.emc.com:636) ldap_create ldap_url_parse_ext(ldaps://ldpdd042.hop.lab.emc.com:636/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP ldpdd042.hop.lab.emc.com:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 10.247.229.42:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect success TLS trace: SSL_connect:before SSL initialization tls_write: want=334, written=334 0000: 16 03 01 01 49 01 00 01 45 03 03 a2 85 24 0b ee ....I...E....$.. 0010: 8f 28 13 34 a4 e5 6a c3 48 50 69 d7 81 72 96 02 .(.4..j.HPi..r.. 0020: 7b 56 46 6a ec d0 f3 64 71 35 b2 20 fd 17 70 c9 {VFj...dq5. ..p. 0030: 15 23 3d 7c 31 66 99 84 f3 92 4b c7 a9 ab e2 f8 .#=|1f....K..... 0040: 5b b3 42 44 7e 91 f5 4b 9a 5b c9 b1 00 46 13 02 [.BD~..K.[...F.. 0050: 13 03 13 01 c0 2c c0 30 cc a9 cc a8 c0 ad c0 2b .....,.0.......+ 0060: c0 2f c0 ac c0 23 c0 27 c0 0a c0 14 c0 09 c0 13 ./...#.'........ 0070: 00 9d c0 9d 00 9c c0 9c 00 3d 00 3c 00 35 00 2f .........=.<.5./ 0080: 00 9f cc aa c0 9f 00 9e c0 9e 00 6b 00 67 00 39 ...........k.g.9 0090: 00 33 00 ff 01 00 00 b6 00 00 00 1d 00 1b 00 00 .3.............. 00a0: 18 6c 64 70 64 64 30 34 32 2e 68 6f 70 2e 6c 61 .ldpdd042.hop.la 00b0: 62 2e 65 6d 63 2e 63 6f 6d 00 0b 00 04 03 00 01 b.emc.com....... 00c0: 02 00 0a 00 0c 00 0a 00 1d 00 17 00 1e 00 19 00 ................ 00d0: 18 00 23 00 00 00 16 00 00 00 17 00 00 00 0d 00 ..#............. 00e0: 30 00 2e 04 03 05 03 06 03 08 07 08 08 08 09 08 0............... 00f0: 0a 08 0b 08 04 08 05 08 06 04 01 05 01 06 01 03 ................ 0100: 03 02 03 03 01 02 01 03 02 02 02 04 02 05 02 06 ................ 0110: 02 00 2b 00 09 08 03 04 03 03 03 02 03 01 00 2d ..+............- 0120: 00 02 01 01 00 33 00 26 00 24 00 1d 00 20 49 ea .....3.&.$... I. 0130: 8c 2a c7 1e 18 82 13 d1 46 3d 46 b0 b7 2b bd b2 .*......F=F..+.. 0140: 6e 13 ec ab c5 fa 25 4d 4f cc 58 77 78 69 n.....%MO.Xwxi TLS trace: SSL_connect:SSLv3/TLS write client hello tls_read: want=5, got=0
TLS trace: SSL_connect:error in SSLv3/TLS write client hello TLS: can't connect: . ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) ldpdd042:~ #
Here's what was written to /var/log/messages:
2023-05-11T16:04:32.584581-04:00 ldpdd042 slapd[21376]: conn=1000 fd=12 ACCEPT from IP=10.247.229.42:47346 (IP=0.0.0.0:636) 2023-05-11T16:04:32.594205-04:00 ldpdd042 slapd[21376]: connection_get(12) 2023-05-11T16:04:32.594295-04:00 ldpdd042 slapd[21376]: conn=1000 fd=12 closed (TLS negotiation failure)
I'm using a self-signed server certificate, so no CA should be involved. Not sure if that is causing the problem?
Thanks! tl
-----Original Message----- From: terry.lemons@dell.com terry.lemons@dell.com Sent: Thursday, May 11, 2023 1:10 PM To: openldap-technical@openldap.org Subject: Re: Debugging TLS negotiation failure
I'm using a self-signed server certificate, so no CA should be involved. Not sure if that is causing the problem?
Try prepending to your ldapsearch:
"LDAPTLS_REQCERT=allow ldapsearch ..."
I have also noticed that the errors returned when using StartTLS (TCP/389 "ldap://" prefix URIs) are more informative than when using (non-protocol but widely supported) TCP/636 "ldaps://".
Chris Paul | Rex Consulting | https://www.rexconsulting.net
On Thu, 11 May 2023, Christopher Paul wrote:
-----Original Message----- From: terry.lemons@dell.com terry.lemons@dell.com Sent: Thursday, May 11, 2023 1:10 PM To: openldap-technical@openldap.org Subject: Re: Debugging TLS negotiation failure
I'm using a self-signed server certificate, so no CA should be involved.
As Jeffery Walton observed, self-signed means the server's cert *IS* the CA you need.
Not sure if that is causing the problem?
Try prepending to your ldapsearch:
"LDAPTLS_REQCERT=allow ldapsearch ..."
To be clear, that setting disables the client's authentication of the server: no protection from active attacks, back to "trust the network layer". This is only useful for confirming that everything _except_ the CA/cert setup are fine.
Philip Guenther
-----Original Message----- From: Philip Guenther pguenther@proofpoint.com Sent: Thursday, May 11, 2023 2:06 PM To: Christopher Paul chris.paul@rexconsulting.net Cc: terry.lemons@dell.com; openldap-technical@openldap.org Subject: RE: Debugging TLS negotiation failure
Not sure if that is causing the problem?
Try prepending to your ldapsearch:
"LDAPTLS_REQCERT=allow ldapsearch ..."
To be clear, that setting disables the client's authentication of the server: no protection from active attacks, back to "trust the network layer". This is only useful for confirming that everything _except_ the CA/cert setup are fine.
Yes 100% agree. TLS in production should be used for encryption AND verification and so in production should use a signed cert and LDAPTLS_REQCERT=demand.
terry.lemons@dell.com wrote:
Hi Howard
Thanks very much for the reply and the suggestion. Here is the output of a ldapsearch command that completes successfully when I omit '-H ldaps://ldpdd042.hop.lab.emc.com:636':
The lack of any server reply to the client's Hello message strikes me as probably a TLS version mismatch. Check what versions of TLS libraries are in use on both the client and server, and if they've been configured to include or exclude any particular TLS versions.
Also, both slapd and the clients should be configured to use the self-signed server cert as a CA cert.
ldpdd042:~ # ldapsearch -d -1 -x -b 'dc=example,dc=com' '(objectclass=*)' -H ldaps://ldpdd042.hop.lab.emc.com:636 ldap_url_parse_ext(ldaps://ldpdd042.hop.lab.emc.com:636) ldap_create ldap_url_parse_ext(ldaps://ldpdd042.hop.lab.emc.com:636/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP ldpdd042.hop.lab.emc.com:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 10.247.229.42:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect success TLS trace: SSL_connect:before SSL initialization tls_write: want=334, written=334 0000: 16 03 01 01 49 01 00 01 45 03 03 a2 85 24 0b ee ....I...E....$.. 0010: 8f 28 13 34 a4 e5 6a c3 48 50 69 d7 81 72 96 02 .(.4..j.HPi..r.. 0020: 7b 56 46 6a ec d0 f3 64 71 35 b2 20 fd 17 70 c9 {VFj...dq5. ..p. 0030: 15 23 3d 7c 31 66 99 84 f3 92 4b c7 a9 ab e2 f8 .#=|1f....K..... 0040: 5b b3 42 44 7e 91 f5 4b 9a 5b c9 b1 00 46 13 02 [.BD~..K.[...F.. 0050: 13 03 13 01 c0 2c c0 30 cc a9 cc a8 c0 ad c0 2b .....,.0.......+ 0060: c0 2f c0 ac c0 23 c0 27 c0 0a c0 14 c0 09 c0 13 ./...#.'........ 0070: 00 9d c0 9d 00 9c c0 9c 00 3d 00 3c 00 35 00 2f .........=.<.5./ 0080: 00 9f cc aa c0 9f 00 9e c0 9e 00 6b 00 67 00 39 ...........k.g.9 0090: 00 33 00 ff 01 00 00 b6 00 00 00 1d 00 1b 00 00 .3.............. 00a0: 18 6c 64 70 64 64 30 34 32 2e 68 6f 70 2e 6c 61 .ldpdd042.hop.la 00b0: 62 2e 65 6d 63 2e 63 6f 6d 00 0b 00 04 03 00 01 b.emc.com....... 00c0: 02 00 0a 00 0c 00 0a 00 1d 00 17 00 1e 00 19 00 ................ 00d0: 18 00 23 00 00 00 16 00 00 00 17 00 00 00 0d 00 ..#............. 00e0: 30 00 2e 04 03 05 03 06 03 08 07 08 08 08 09 08 0............... 00f0: 0a 08 0b 08 04 08 05 08 06 04 01 05 01 06 01 03 ................ 0100: 03 02 03 03 01 02 01 03 02 02 02 04 02 05 02 06 ................ 0110: 02 00 2b 00 09 08 03 04 03 03 03 02 03 01 00 2d ..+............- 0120: 00 02 01 01 00 33 00 26 00 24 00 1d 00 20 49 ea .....3.&.$... I. 0130: 8c 2a c7 1e 18 82 13 d1 46 3d 46 b0 b7 2b bd b2 .*......F=F..+.. 0140: 6e 13 ec ab c5 fa 25 4d 4f cc 58 77 78 69 n.....%MO.Xwxi TLS trace: SSL_connect:SSLv3/TLS write client hello tls_read: want=5, got=0
TLS trace: SSL_connect:error in SSLv3/TLS write client hello TLS: can't connect: . ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) ldpdd042:~ #
Here's what was written to /var/log/messages:
2023-05-11T16:04:32.584581-04:00 ldpdd042 slapd[21376]: conn=1000 fd=12 ACCEPT from IP=10.247.229.42:47346 (IP=0.0.0.0:636) 2023-05-11T16:04:32.594205-04:00 ldpdd042 slapd[21376]: connection_get(12) 2023-05-11T16:04:32.594295-04:00 ldpdd042 slapd[21376]: conn=1000 fd=12 closed (TLS negotiation failure)
I'm using a self-signed server certificate, so no CA should be involved. Not sure if that is causing the problem?
Thanks! tl
Hi Howard
Thanks for the suggestion.
[tl] > The lack of any server reply to the client's Hello message strikes me as probably a TLS version mismatch. [tl] > Check what versions of TLS libraries are in use on both the client and server, and if they've been configured to include or exclude any particular TLS versions.
I've been running the ldapsearch and openssl commands on the OpenLDAP server, so the client and server are the same system. I only see openssl 1.1 installed on this OpenLDAP server system: ldpdd042:~ # rpm -qa | grep openssl openssl-1.1.1l-150400.1.5.noarch openssl-1_1-1.1.1l-150400.7.34.1.x86_64 libxmlsec1-openssl1-1.2.28-150100.7.13.4.x86_64 libopenssl1_1-1.1.1l-150400.7.34.1.x86_64 libopenssl-1_1-devel-1.1.1l-150400.7.34.1.x86_64 ldpdd042:~ #
I'm assuming that OpenLDAP 2.6.4 does support openssl 1.1, correct?
[tl] > Also, both slapd and the clients should be configured to use the self-signed server cert as a CA cert.
I believe the server is using the self-signed cert. I think another reply to this thread had suggested that I not use TLSCACertificateFile , so I commented it out: ldpdd042:~ # tail /usr/local/etc/openldap/slapd.conf ####################################################################### # monitor database definitions ####################################################################### database monitor # Added TLS directives # #TLSCACertificateFile /var/lib/ca-certificates/ca-bundle.pem TLSCertificateFile /etc/ssl/private/server.cert TLSCertificateKeyFile /etc/ssl/private/server.key
Thanks! tl
Internal Use - Confidential
On Thu, May 11, 2023 at 3:46 PM Howard Chu hyc@symas.com wrote:
terry.lemons@dell.com wrote:
I've followed the instructions in https://www.openldap.org/doc/admin26/quickstart.html to deploy openldap 2.6.4 on a SLES 15 SP4 system. Once I confirmed that this was working correctly, I moved on to configure TLS, following the instructions in https://www.openldap.org/doc/admin26/tls.html. When I try a connection to the LDAPS port (636), I see the following:
ldpdd040:~ # openssl s_client -connect ldpdd042.hop.lab.emc.com:636
If you're going to use openssl s_client you also need to tell it which CA and/or server certs to trust. I'd start with using ldapsearch -d -1 instead.
In addition, you should add -servername, too. The option engages SNI.
openssl s_client -connect ldpdd042.hop.lab.emc.com:636 \ -servername ldpdd042.hop.lab.emc.com
Otherwise, you might get the default server at the host ldpdd042. I'm not sure how that would work in this instance. (I know how it works with web servers).
CONNECTED(00000003) 139702302594704: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 293 bytes
New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated 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: 1683823897 Timeout : 300 (sec) Verify return code: 0 (ok)
ldpdd040:~ #
It appears that the server did not send a TLS response. Instead, it looks like an unencrypted channel with 0 bytes sent by the server.
(When this happens with a misconfigured web server, you will see a response with N bytes. But the N bytes are the chars of index.html or similar, and not a server's TLS response).
I'm using this command to start slapd: /usr/local/libexec/slapd -F /usr/local/etc/slapd.d -s 3 -h "ldap:/// ldaps:///"
When I execute the openssl command above, I look in /var/log/messages and see:
2023-05-11T12:51:55.213884-04:00 ldpdd042 slapd[20101]: conn=1000 fd=12 ACCEPT from IP=10.247.229.40:56844 (IP=0.0.0.0:636) 2023-05-11T12:51:55.213944-04:00 ldpdd042 slapd[20101]: connection_get(12): got connid=1000 2023-05-11T12:51:55.214004-04:00 ldpdd042 slapd[20101]: connection_read(12): checking for input on id=1000 2023-05-11T12:51:55.214065-04:00 ldpdd042 slapd[20101]: connection_read(12): TLS accept failure error=-1 id=1000, closing 2023-05-11T12:51:55.214138-04:00 ldpdd042 slapd[20101]: connection_close: conn=1000 sd=12 2023-05-11T12:51:55.214207-04:00 ldpdd042 slapd[20101]: conn=1000 fd=12 closed (TLS negotiation failure) ldpdd0
I've appended these lines to /usr/local/etc/openldap/slapd.conf:
# Added TLS directives # TLSCACertificateFile /var/lib/ca-certificates/ca-bundle.pem TLSCertificateFile /etc/ssl/private/server.cert TLSCertificateKeyFile /etc/ssl/private/server.key #TLSCipherSuite ALL
TLSCACertificateFile should probably be blank. It is probably the CA certs the server would use to authenticate a client when mutual authentication is used. I.e.e, client certificates.
TLSCertificateFile should probably be the entire chain used in path building, and not just the server's certificate. Since this is using a self-signed end-entity certificate, it would include just the end-entity certificate. No CA certificates needed.
Because you are using openssl s_client, you need to do something like:
openssl s_client -connect ldpdd042.hop.lab.emc.com:636 \ -servername ldpdd042.hop.lab.emc.com \ -cafile server.cert
Obviously, the client does not have access to /etc/ssl/private/server.cert. But it needs server.cert to verify the certificate used by the server, in PEM format. That's the key distribution problem. You have to supply every client with the server's certificate.
I can't find any log information that helps me understand what the problem is. I'm using a self-signed server certificate that has the cn using the FQDN of the server.
Yeah, this is wrong nowadays. All names go in the Subject Alt Names (SAN). It is Ok to put a name in the CN, but it must also appear in the SAN. If a name is in the CN, then it must also appear in the SAN. So says the CA/Browser Baseline requirements (CA/B BR).
Since the CN is a friendly name displayed to the user, I use a friendly name like 'CN = OpenLDAP Server." And then all names go in the SAN.
Here's an example of creating a well formed self-signed end-entity (server) certificate: https://www.cryptopp.com/wiki/X509Certificate#OpenSSL_x509
How can I debug this?
And finally, here is the man page for s_client. There are a lot of options, but -connect, -servername and -cafile should be enough to get you there. https://www.openssl.org/docs/man1.1.1/man1/openssl-s_client.html
Jeff
Hi Jeff
Thanks for your reply.
In addition, you should add -servername, too. The option engages SNI.
openssl s_client -connect ldpdd042.hop.lab.emc.com:636 \ -servername ldpdd042.hop.lab.emc.com
Otherwise, you might get the default server at the host ldpdd042. I'm not sure how that would work in this instance. (I know how it works with web servers).
I don't see any difference in the openssl output when I use the 'servername' option:
ldpdd042:~ # openssl s_client -connect ldpdd042.hop.lab.emc.com:636 CONNECTED(00000003) write:errno=0 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 334 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- ldpdd042:~ # openssl s_client -connect ldpdd042.hop.lab.emc.com:636 -servername ldpdd042.hop.lab.emc.com CONNECTED(00000003) write:errno=0 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 334 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- ldpdd042:~ #
TLSCACertificateFile should probably be blank. It is probably the CA certs the server would use to authenticate a client when mutual authentication is used. I.e.e, client certificates.
Okay. I commented out that parameter in /usr/local/etc/openldap/slapd.conf and restarted the daemon, with no apparent change in behavior.
TLSCertificateFile should probably be the entire chain used in path building, and not just the server's certificate. Since this is using a self-signed end-entity certificate, it would include just the end-entity certificate. No CA certificates needed.
Here is the certificate that I created for use with OpenLDAP; please let me know of any deficiencies with it.
ldpdd042:~ # openssl x509 -in /etc/ssl/private/server.cert -noout -text Certificate: Data: Version: 3 (0x2) Serial Number: 29:c5:df:63:73:c6:ae:91:95:0c:4d:7a:7e:8c:b2:25:50:43:93:15 Signature Algorithm: sha256WithRSAEncryption Issuer: C = US, ST = MA, L = Hopkinton, O = Dell Technologies, OU = DPC Engineering, CN = ldpdd042.hop.lab.emc.com Validity Not Before: May 10 16:10:25 2023 GMT Not After : Jun 9 16:10:25 2023 GMT Subject: C = US, ST = MA, L = Hopkinton, O = Dell Technologies, OU = DPC Engineering, CN = ldpdd042.hop.lab.emc.com Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (2048 bit) Modulus: 00:cc:fd:1d:97:da:63:20:a4:04:e0:30:de:b2:1f: 85:df:3f:ff:c9:a1:e9:02:53:cd:2e:cf:14:f3:45: 20:49:9c:29:e3:1c:6b:7e:9a:a8:45:42:bb:53:e9: b2:20:c4:c7:80:05:cb:ae:ad:1f:de:2a:0e:8a:0a: ab:ff:d6:3b:a0:22:56:ef:4a:c4:f5:4f:54:82:90: 44:38:c6:2c:ac:9d:95:b8:07:f2:7f:76:74:01:47: 56:c5:7e:45:f9:f8:94:25:24:20:b6:56:36:a4:27: 20:99:51:64:12:1b:0a:ba:c3:90:bc:59:58:ad:42: 04:72:76:80:b4:8e:aa:29:1d:59:6b:04:c5:64:15: d9:3a:7d:dd:b5:b7:f4:ed:a7:da:18:f1:82:65:12: 7f:36:32:78:d1:bf:cf:06:12:41:8f:bc:d1:f5:bf: 7d:5d:d8:7b:dd:27:90:34:80:fa:44:44:a9:21:bc: d1:d4:03:d8:ac:03:d4:5b:89:25:f9:f7:da:b5:7e: b1:9e:c9:46:1b:91:e0:78:43:0f:3b:05:64:32:b7: a2:d5:c1:58:4b:ab:1b:a0:a6:77:40:32:30:ef:dc: a2:04:f6:4a:35:57:9b:be:0a:46:32:a5:bc:e1:04: 99:c7:4c:2c:d3:61:f8:f2:3f:7d:5d:4c:76:1a:bb: ba:af Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: 4B:36:FE:7A:3C:A2:24:A1:35:18:A0:FA:BE:75:DA:03:6C:CC:DF:F8 X509v3 Authority Key Identifier: keyid:4B:36:FE:7A:3C:A2:24:A1:35:18:A0:FA:BE:75:DA:03:6C:CC:DF:F8
X509v3 Basic Constraints: critical CA:TRUE Signature Algorithm: sha256WithRSAEncryption 1c:ab:88:54:79:8e:86:54:49:35:b7:81:3b:35:84:7e:d3:4f: 4d:12:a1:86:73:38:e1:7f:b0:d5:6f:99:f3:c2:bb:f4:8a:60: c5:75:67:10:b4:03:80:6e:bb:14:6f:3f:e6:d3:9b:a1:d4:d3: 36:82:45:14:8c:1e:e7:f1:88:91:6d:36:ea:6d:0a:07:ef:ba: 16:43:f9:0e:81:e7:77:bd:20:23:ad:45:54:6e:d4:09:e5:3e: 36:79:63:35:5f:63:57:e6:93:4a:19:5a:46:82:fd:43:aa:2d: cf:1f:9a:fe:3d:5c:d8:60:cb:f6:76:fd:fd:22:92:21:4f:0b: 76:a2:44:36:a9:26:f5:01:a0:c9:83:3f:26:e1:8b:4f:65:93: d6:c7:47:e9:af:c4:d6:37:21:e3:07:6b:20:ae:38:81:30:26: 41:68:fa:99:3a:c3:9c:df:43:4f:37:76:94:cb:88:ae:46:a8: b4:1a:12:bf:01:77:ad:0d:be:20:6b:26:8e:f5:94:91:7f:28: 5c:3c:72:7a:b9:26:b9:69:d7:10:38:60:b7:ec:74:f5:b5:ed: 00:86:9a:5a:28:95:c2:51:d5:af:ef:74:a3:1f:d2:0d:4b:53: bc:e5:b7:3d:63:40:ee:28:0c:ff:7d:bc:88:e4:ab:49:5a:b3: 82:a7:ea:0f ldpdd042:~ #
Because you are using openssl s_client, you need to do something like:
openssl s_client -connect ldpdd042.hop.lab.emc.com:636 \ -servername ldpdd042.hop.lab.emc.com \ -cafile server.cert
When I execute this openssl command on the OpenLDAP server (which, of course, has access to the server certificate), again, no information is read by the 'SSL handshake':
ldpdd042:~ # openssl s_client -connect ldpdd042.hop.lab.emc.com:636 -servername ldpdd042.hop.lab.emc.com -CAfile /etc/ssl/private/server.cert CONNECTED(00000003) write:errno=0 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 334 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- ldpdd042:~ #
Here's an example of creating a well formed self-signed end-entity (server) certificate:
Here is the command that I used to create the self-signed server certificate; please let me know if it isn't correct for this application: openssl req -nodes -new -x509 -keyout server.key -out server.cert
Thanks for the help! tl
Internal Use - Confidential
On Fri, May 12, 2023 at 1:20 PM Lemons, Terry Terry.Lemons@dell.com wrote:
Hi Jeff
Thanks for your reply.
In addition, you should add -servername, too. The option engages SNI.
openssl s_client -connect ldpdd042.hop.lab.emc.com:636 \ -servername ldpdd042.hop.lab.emc.com
Otherwise, you might get the default server at the host ldpdd042. I'm not sure how that would work in this instance. (I know how it works with web servers).
I don't see any difference in the openssl output when I use the 'servername' option:
ldpdd042:~ # openssl s_client -connect ldpdd042.hop.lab.emc.com:636 CONNECTED(00000003) write:errno=0
no peer certificate available
No client certificate CA names sent
SSL handshake has read 0 bytes and written 334 bytes Verification: OK
New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok)
ldpdd042:~ # openssl s_client -connect ldpdd042.hop.lab.emc.com:636 -servername ldpdd042.hop.lab.emc.com CONNECTED(00000003) write:errno=0
no peer certificate available
No client certificate CA names sent
SSL handshake has read 0 bytes and written 334 bytes Verification: OK
New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok)
ldpdd042:~ #
TLSCACertificateFile should probably be blank. It is probably the CA certs the server would use to authenticate a client when mutual authentication is used. I.e.e, client certificates.
Okay. I commented out that parameter in /usr/local/etc/openldap/slapd.conf and restarted the daemon, with no apparent change in behavior.
TLSCertificateFile should probably be the entire chain used in path building, and not just the server's certificate. Since this is using a self-signed end-entity certificate, it would include just the end-entity certificate. No CA certificates needed.
Here is the certificate that I created for use with OpenLDAP; please let me know of any deficiencies with it.
ldpdd042:~ # openssl x509 -in /etc/ssl/private/server.cert -noout -text Certificate: Data: Version: 3 (0x2) Serial Number: 29:c5:df:63:73:c6:ae:91:95:0c:4d:7a:7e:8c:b2:25:50:43:93:15 Signature Algorithm: sha256WithRSAEncryption Issuer: C = US, ST = MA, L = Hopkinton, O = Dell Technologies, OU = DPC Engineering, CN = ldpdd042.hop.lab.emc.com Validity Not Before: May 10 16:10:25 2023 GMT Not After : Jun 9 16:10:25 2023 GMT Subject: C = US, ST = MA, L = Hopkinton, O = Dell Technologies, OU = DPC Engineering, CN = ldpdd042.hop.lab.emc.com Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (2048 bit) Modulus: 00:cc:fd:1d:97:da:63:20:a4:04:e0:30:de:b2:1f: 85:df:3f:ff:c9:a1:e9:02:53:cd:2e:cf:14:f3:45: 20:49:9c:29:e3:1c:6b:7e:9a:a8:45:42:bb:53:e9: b2:20:c4:c7:80:05:cb:ae:ad:1f:de:2a:0e:8a:0a: ab:ff:d6:3b:a0:22:56:ef:4a:c4:f5:4f:54:82:90: 44:38:c6:2c:ac:9d:95:b8:07:f2:7f:76:74:01:47: 56:c5:7e:45:f9:f8:94:25:24:20:b6:56:36:a4:27: 20:99:51:64:12:1b:0a:ba:c3:90:bc:59:58:ad:42: 04:72:76:80:b4:8e:aa:29:1d:59:6b:04:c5:64:15: d9:3a:7d:dd:b5:b7:f4:ed:a7:da:18:f1:82:65:12: 7f:36:32:78:d1:bf:cf:06:12:41:8f:bc:d1:f5:bf: 7d:5d:d8:7b:dd:27:90:34:80:fa:44:44:a9:21:bc: d1:d4:03:d8:ac:03:d4:5b:89:25:f9:f7:da:b5:7e: b1:9e:c9:46:1b:91:e0:78:43:0f:3b:05:64:32:b7: a2:d5:c1:58:4b:ab:1b:a0:a6:77:40:32:30:ef:dc: a2:04:f6:4a:35:57:9b:be:0a:46:32:a5:bc:e1:04: 99:c7:4c:2c:d3:61:f8:f2:3f:7d:5d:4c:76:1a:bb: ba:af Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: 4B:36:FE:7A:3C:A2:24:A1:35:18:A0:FA:BE:75:DA:03:6C:CC:DF:F8 X509v3 Authority Key Identifier: keyid:4B:36:FE:7A:3C:A2:24:A1:35:18:A0:FA:BE:75:DA:03:6C:CC:DF:F8
X509v3 Basic Constraints: critical CA:TRUE Signature Algorithm: sha256WithRSAEncryption 1c:ab:88:54:79:8e:86:54:49:35:b7:81:3b:35:84:7e:d3:4f: 4d:12:a1:86:73:38:e1:7f:b0:d5:6f:99:f3:c2:bb:f4:8a:60: c5:75:67:10:b4:03:80:6e:bb:14:6f:3f:e6:d3:9b:a1:d4:d3: 36:82:45:14:8c:1e:e7:f1:88:91:6d:36:ea:6d:0a:07:ef:ba: 16:43:f9:0e:81:e7:77:bd:20:23:ad:45:54:6e:d4:09:e5:3e: 36:79:63:35:5f:63:57:e6:93:4a:19:5a:46:82:fd:43:aa:2d: cf:1f:9a:fe:3d:5c:d8:60:cb:f6:76:fd:fd:22:92:21:4f:0b: 76:a2:44:36:a9:26:f5:01:a0:c9:83:3f:26:e1:8b:4f:65:93: d6:c7:47:e9:af:c4:d6:37:21:e3:07:6b:20:ae:38:81:30:26: 41:68:fa:99:3a:c3:9c:df:43:4f:37:76:94:cb:88:ae:46:a8: b4:1a:12:bf:01:77:ad:0d:be:20:6b:26:8e:f5:94:91:7f:28: 5c:3c:72:7a:b9:26:b9:69:d7:10:38:60:b7:ec:74:f5:b5:ed: 00:86:9a:5a:28:95:c2:51:d5:af:ef:74:a3:1f:d2:0d:4b:53: bc:e5:b7:3d:63:40:ee:28:0c:ff:7d:bc:88:e4:ab:49:5a:b3: 82:a7:ea:0fldpdd042:~ #
CA:TRUE is wrong:
X509v3 Basic Constraints: critical CA:TRUE
This is an end-entity certificate, not a CA certificate.
In X.500, there are two types of certificates: (1) CA certificates, and (2) End-Entity certificates. CA certificates can be used to issue other certificates. End-Entity certificates are used to bind a public key to an individual or other entity.
CA certificates have basic_constraint.ca = true. End-Entity certificates have basic_constraint.ca = false. That's this line here in an openssl configuration file (https://www.cryptopp.com/wiki/X509Certificate#OpenSSL_x509):
basicConstraints = critical,CA:FALSE
Key Usage and Extended Key Usage determines what an individual or entity can do with the public key in their end-entity certificate.
Jeff
Hi Jeff
CA:TRUE is wrong:
Oh! I took a look at https://www.cryptopp.com/wiki/X509Certificate#OpenSSL_x509, and created this openssl configuration file:
ldpdd042:/tmp # cat openssl.conf [ req ] prompt = no default_bits = 4096 distinguished_name = subject x509_extensions = x509_ext
[ subject ] countryName = US stateOrProvinceName = NY localityName = New York organizationName = Example, LLC commonName = Example Company emailAddress = test@example.com
[ x509_ext ] basicConstraints = critical,CA:FALSE subjectAltName = DNS:ldpdd042.hop.lab.emc.com,IP:10.247.226.42 ldpdd042:/tmp #
I then re-created the server cert/key pair:
openssl req -x509 -config openssl.conf -newkey rsa:4096 -sha256 -days 3650 -nodes -keyout example.key -out example.crt -subj "/CN=ldpdd042.hop.lab.emc.com"
Updated the /usr/local/etc/openldap/slapd.conf to use the new cert/key values:
ldpdd042:/tmp # tail /usr/local/etc/openldap/slapd.conf ####################################################################### # monitor database definitions ####################################################################### database monitor # Added TLS directives # #TLSCACertificateFile /var/lib/ca-certificates/ca-bundle.pem TLSCertificateFile /etc/ssl/private/example.crt TLSCertificateKeyFile /etc/ssl/private/example.key #TLSCipherSuite ALL ldpdd042:/tmp #
and restarted the slapd service:
ps -ef | grep slapd kill xxxxx /usr/local/libexec/slapd -F /usr/local/etc/slapd.d -s 1 -h "ldap:/// ldaps:///"
No change in behavior, though:
ldpdd042:/tmp # openssl s_client -connect ldpdd042.hop.lab.emc.com:636 -servername ldpdd042.hop.lab.emc.com -CAfile /etc/ssl/private/example.crt CONNECTED(00000003) write:errno=0 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 334 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- ldpdd042:/tmp #
slapd IS reading the /usr/local/etc/openldap/slapd.conf, right (and isn't looking in the openldap database for the TLS information)?
Thanks for the help! tl
Internal Use - Confidential
-----Original Message----- From: Jeffrey Walton noloader@gmail.com Sent: Friday, May 12, 2023 1:55 PM To: Lemons, Terry Cc: openldap-technical@openldap.org Subject: Re: Debugging TLS negotiation failure
[EXTERNAL EMAIL]
On Fri, May 12, 2023 at 1:20 PM Lemons, Terry Terry.Lemons@dell.com wrote:
Hi Jeff
Thanks for your reply.
In addition, you should add -servername, too. The option engages SNI.
openssl s_client -connect ldpdd042.hop.lab.emc.com:636 \ -servername ldpdd042.hop.lab.emc.com
Otherwise, you might get the default server at the host ldpdd042. I'm not sure how that would work in this instance. (I know how it works with web servers).
I don't see any difference in the openssl output when I use the 'servername' option:
ldpdd042:~ # openssl s_client -connect ldpdd042.hop.lab.emc.com:636 CONNECTED(00000003) write:errno=0
no peer certificate available
No client certificate CA names sent
SSL handshake has read 0 bytes and written 334 bytes Verification: OK
New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok)
ldpdd042:~ # openssl s_client -connect ldpdd042.hop.lab.emc.com:636 -servername ldpdd042.hop.lab.emc.com CONNECTED(00000003) write:errno=0
no peer certificate available
No client certificate CA names sent
SSL handshake has read 0 bytes and written 334 bytes Verification: OK
New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok)
ldpdd042:~ #
TLSCACertificateFile should probably be blank. It is probably the CA certs the server would use to authenticate a client when mutual authentication is used. I.e.e, client certificates.
Okay. I commented out that parameter in /usr/local/etc/openldap/slapd.conf and restarted the daemon, with no apparent change in behavior.
TLSCertificateFile should probably be the entire chain used in path building, and not just the server's certificate. Since this is using a self-signed end-entity certificate, it would include just the end-entity certificate. No CA certificates needed.
Here is the certificate that I created for use with OpenLDAP; please let me know of any deficiencies with it.
ldpdd042:~ # openssl x509 -in /etc/ssl/private/server.cert -noout -text Certificate: Data: Version: 3 (0x2) Serial Number: 29:c5:df:63:73:c6:ae:91:95:0c:4d:7a:7e:8c:b2:25:50:43:93:15 Signature Algorithm: sha256WithRSAEncryption Issuer: C = US, ST = MA, L = Hopkinton, O = Dell Technologies, OU = DPC Engineering, CN = ldpdd042.hop.lab.emc.com Validity Not Before: May 10 16:10:25 2023 GMT Not After : Jun 9 16:10:25 2023 GMT Subject: C = US, ST = MA, L = Hopkinton, O = Dell Technologies, OU = DPC Engineering, CN = ldpdd042.hop.lab.emc.com Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (2048 bit) Modulus: 00:cc:fd:1d:97:da:63:20:a4:04:e0:30:de:b2:1f: 85:df:3f:ff:c9:a1:e9:02:53:cd:2e:cf:14:f3:45: 20:49:9c:29:e3:1c:6b:7e:9a:a8:45:42:bb:53:e9: b2:20:c4:c7:80:05:cb:ae:ad:1f:de:2a:0e:8a:0a: ab:ff:d6:3b:a0:22:56:ef:4a:c4:f5:4f:54:82:90: 44:38:c6:2c:ac:9d:95:b8:07:f2:7f:76:74:01:47: 56:c5:7e:45:f9:f8:94:25:24:20:b6:56:36:a4:27: 20:99:51:64:12:1b:0a:ba:c3:90:bc:59:58:ad:42: 04:72:76:80:b4:8e:aa:29:1d:59:6b:04:c5:64:15: d9:3a:7d:dd:b5:b7:f4:ed:a7:da:18:f1:82:65:12: 7f:36:32:78:d1:bf:cf:06:12:41:8f:bc:d1:f5:bf: 7d:5d:d8:7b:dd:27:90:34:80:fa:44:44:a9:21:bc: d1:d4:03:d8:ac:03:d4:5b:89:25:f9:f7:da:b5:7e: b1:9e:c9:46:1b:91:e0:78:43:0f:3b:05:64:32:b7: a2:d5:c1:58:4b:ab:1b:a0:a6:77:40:32:30:ef:dc: a2:04:f6:4a:35:57:9b:be:0a:46:32:a5:bc:e1:04: 99:c7:4c:2c:d3:61:f8:f2:3f:7d:5d:4c:76:1a:bb: ba:af Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: 4B:36:FE:7A:3C:A2:24:A1:35:18:A0:FA:BE:75:DA:03:6C:CC:DF:F8 X509v3 Authority Key Identifier:
keyid:4B:36:FE:7A:3C:A2:24:A1:35:18:A0:FA:BE:75:DA:03:6C:CC:DF:F8
X509v3 Basic Constraints: critical CA:TRUE Signature Algorithm: sha256WithRSAEncryption 1c:ab:88:54:79:8e:86:54:49:35:b7:81:3b:35:84:7e:d3:4f: 4d:12:a1:86:73:38:e1:7f:b0:d5:6f:99:f3:c2:bb:f4:8a:60: c5:75:67:10:b4:03:80:6e:bb:14:6f:3f:e6:d3:9b:a1:d4:d3: 36:82:45:14:8c:1e:e7:f1:88:91:6d:36:ea:6d:0a:07:ef:ba: 16:43:f9:0e:81:e7:77:bd:20:23:ad:45:54:6e:d4:09:e5:3e: 36:79:63:35:5f:63:57:e6:93:4a:19:5a:46:82:fd:43:aa:2d: cf:1f:9a:fe:3d:5c:d8:60:cb:f6:76:fd:fd:22:92:21:4f:0b: 76:a2:44:36:a9:26:f5:01:a0:c9:83:3f:26:e1:8b:4f:65:93: d6:c7:47:e9:af:c4:d6:37:21:e3:07:6b:20:ae:38:81:30:26: 41:68:fa:99:3a:c3:9c:df:43:4f:37:76:94:cb:88:ae:46:a8: b4:1a:12:bf:01:77:ad:0d:be:20:6b:26:8e:f5:94:91:7f:28: 5c:3c:72:7a:b9:26:b9:69:d7:10:38:60:b7:ec:74:f5:b5:ed: 00:86:9a:5a:28:95:c2:51:d5:af:ef:74:a3:1f:d2:0d:4b:53: bc:e5:b7:3d:63:40:ee:28:0c:ff:7d:bc:88:e4:ab:49:5a:b3: 82:a7:ea:0fldpdd042:~ #
CA:TRUE is wrong:
X509v3 Basic Constraints: critical CA:TRUE
This is an end-entity certificate, not a CA certificate.
In X.500, there are two types of certificates: (1) CA certificates, and (2) End-Entity certificates. CA certificates can be used to issue other certificates. End-Entity certificates are used to bind a public key to an individual or other entity.
CA certificates have basic_constraint.ca = true. End-Entity certificates have basic_constraint.ca = false. That's this line here in an openssl configuration file (https://urldefense.com/v3/__https://www.cryptopp.com/wiki/X509Certificate*Op... [cryptopp[.]com]):
basicConstraints = critical,CA:FALSE
Key Usage and Extended Key Usage determines what an individual or entity can do with the public key in their end-entity certificate.
Jeff
[ Sigh. Please ignore the previous message that I sent from a totally inappropriate address. ]
A packet capture and analysis by a tool like Wireshark may be helpful.
Hi Jordan
Thanks for the suggestion. My testing so far has used queries executed on the openldap server itself. To do a Wireshark capture, I need to have the query go over the network. So I generated the openssl command on a SLES 12 system (10.247.229.40) using openssl 1.0.2, sending to the SLES 15 (10.247.229.42) openldap system which is using openssl 1.1. Here's the command execution:
ldpdd040:~ # openssl s_client -connect ldpdd042.hop.lab.emc.com:636 -servername ldpdd042.hop.lab.emc.com CONNECTED(00000003) 139644189292176: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 326 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated 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: 1683920466 Timeout : 300 (sec) Verify return code: 0 (ok) --- ldpdd040:~ #
Here's the capture:
[cid:image001.png@01D984E9.21F5BEE0]
So, the openldap server does not reply to the TLS Client Hello with the TLS Server Hello.
Thanks tl
Internal Use - Confidential From: Jordan Brown openldap@jordan.maileater.net Sent: Friday, May 12, 2023 3:26 PM To: Lemons, Terry; noloader@gmail.com Cc: openldap-technical@openldap.org Subject: Re: Debugging TLS negotiation failure
[EXTERNAL EMAIL] [ Sigh. Please ignore the previous message that I sent from a totally inappropriate address. ]
A packet capture and analysis by a tool like Wireshark may be helpful.
--
Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris
So, as s_client implies when it says "read 0 bytes", the client said "hello" and the server hung up the phone.
That means that the server doesn't like the way that the client said hello.
There are three obvious reasons why that might happen:
* The server doesn't really speak TLS, and when the client sent it this TLS gibberish the server just gave up. * The server doesn't like the maximum TLS version that the client specified; it demands a later version. * The server doesn't support any ciphers that the client offered.
For the first, there's no telling what the server might do.
For the second and third, I don't remember what the usual response is. I wouldn't be surprised if an immediate disconnect is usual.
So, what does that Client Hello packet look like?
On Fri, May 12, 2023 at 8:30 PM Jordan Brown openldap@jordan.maileater.net wrote:
So, as s_client implies when it says "read 0 bytes", the client said "hello" and the server hung up the phone.
That means that the server doesn't like the way that the client said hello.
There are three obvious reasons why that might happen:
The server doesn't really speak TLS, and when the client sent it this TLS gibberish the server just gave up. The server doesn't like the maximum TLS version that the client specified; it demands a later version. The server doesn't support any ciphers that the client offered.
For the first, there's no telling what the server might do.
For the second and third, I don't remember what the usual response is. I wouldn't be surprised if an immediate disconnect is usual.
So, what does that Client Hello packet look like?
For the third:
> The server doesn't support any > ciphers that the client offered.
That will generate an alert, which should cause traffic. For example, RFC 8446, Section 4.1.1 says: [1]
If the server is unable to negotiate a supported set of parameters (i.e., there is no overlap between the client and server parameters), it MUST abort the handshake with either a "handshake_failure" or "insufficient_security" fatal alert.
That should generate a message, and the client should read something.
I really feel like there's something wrong with the server configuration.
Doesn't systemd open a socket even if a service is _not_ running? I think systemd does it to make the service start fast. I.e., a `systemctl start slapd.service` will happen quickly because the listening socket is already operating.
Jeff
On 5/12/2023 6:35 PM, Jeffrey Walton wrote:
I really feel like there's something wrong with the server configuration.
Entirely possible but, like the guy looking for his keys under the streetlight, I wanted to check something I knew how to check :-)
If the client is saying something reasonable (like TLS 1.2 or 1.3, not 1.1 or 1.0) and is offering a reasonable set of ciphers, then the server is sick.
Doesn't systemd open a socket even if a service is _not_ running? I think systemd does it to make the service start fast. I.e., a `systemctl start slapd.service` will happen quickly because the listening socket is already operating.
I'm not a Linux guy - I work on Solaris - but assuming that systemd operates something like its predecessor inetd, it opens sockets for transient services, so that the system can receive a connection and only *then* start up a program to handle it. Long-lived servers aren't handled that way. (And the cost to set up a listening socket is negligible.)
On Fri, May 12, 2023 at 07:19:42PM +0000, Lemons, Terry wrote:
/usr/local/libexec/slapd -F /usr/local/etc/slapd.d -s 1 -h "ldap:/// ldaps:///"
This says to use the config database (not file) located at /etc/ldap/slapd.d
slapd IS reading the /usr/local/etc/openldap/slapd.conf, right
Not if the command line you wrote above is accurate. (Unless there's a file-to-database conversion happening that you didn't mention.)
So, has most/all of my TLS problems been because I'm not using the correct command to start slapd?
Here is the command I've been using:
/usr/local/libexec/slapd -F /usr/local/etc/slapd.d -s 1 -h "ldap:/// ldaps:///"
What command should I use if I want slapd to read the TLS values from /usr/local/etc/openldap/slapd.conf?
Thanks tl
Internal Use - Confidential
-----Original Message----- From: Ryan Tandy ryan@nardis.ca Sent: Friday, May 12, 2023 8:40 PM To: Lemons, Terry Cc: openldap-technical@openldap.org Subject: Re: Debugging TLS negotiation failure
[EXTERNAL EMAIL]
On Fri, May 12, 2023 at 07:19:42PM +0000, Lemons, Terry wrote:
/usr/local/libexec/slapd -F /usr/local/etc/slapd.d -s 1 -h "ldap:/// ldaps:///"
This says to use the config database (not file) located at /etc/ldap/slapd.d
slapd IS reading the /usr/local/etc/openldap/slapd.conf, right
Not if the command line you wrote above is accurate. (Unless there's a file-to-database conversion happening that you didn't mention.)
--On Monday, May 15, 2023 6:25 PM +0000 "Lemons, Terry" Terry.Lemons@dell.com wrote:
So, has most/all of my TLS problems been because I'm not using the correct command to start slapd?
Here is the command I've been using:
/usr/local/libexec/slapd -F /usr/local/etc/slapd.d -s 1 -h "ldap:/// ldaps:///"
What command should I use if I want slapd to read the TLS values from /usr/local/etc/openldap/slapd.conf?
slapd.conf is the historic method of configuring OpenLDAP. General best advise these days is to use cn=config. I would suggest you familiarize yourself with how to use cn=config rather than change to using slapd.conf.
--Quanah
Hi Quanah
Thanks for the recommendation. I'm confused, then, that the official openldap.org documentation at https://www.openldap.org/doc/admin26/tls.html does NOT suggest use of cn=config. Can someone explain why?
Thanks tl
Internal Use - Confidential
-----Original Message----- From: Quanah Gibson-Mount quanah@fast-mail.org Sent: Monday, May 15, 2023 2:00 PM To: Lemons, Terry Cc: openldap-technical@openldap.org Subject: RE: Debugging TLS negotiation failure
[EXTERNAL EMAIL]
--On Monday, May 15, 2023 6:25 PM +0000 "Lemons, Terry" Terry.Lemons@dell.com wrote:
So, has most/all of my TLS problems been because I'm not using the correct command to start slapd?
Here is the command I've been using:
/usr/local/libexec/slapd -F /usr/local/etc/slapd.d -s 1 -h "ldap:/// ldaps:///"
What command should I use if I want slapd to read the TLS values from /usr/local/etc/openldap/slapd.conf?
slapd.conf is the historic method of configuring OpenLDAP. General best advise these days is to use cn=config. I would suggest you familiarize yourself with how to use cn=config rather than change to using slapd.conf.
--Quanah
--On Monday, May 15, 2023 7:03 PM +0000 "Lemons, Terry" Terry.Lemons@dell.com wrote:
Hi Quanah
Thanks for the recommendation. I'm confused, then, that the official openldap.org documentation at https://www.openldap.org/doc/admin26/tls.html does NOT suggest use of cn=config. Can someone explain why?
I don't see anything in there saying not to use cn=config. Note that much of the documentation still needs conversion for cn=config, feel free to open up PRs in git.openldap.org fixing such documentation under ITS#7335.
Generally, I'd advise reading the slapd-config(5) man page. The Admin guide is a best effort, man page are authoratative.
--Quanah
First, thanks to all who contributed to this discussion. I much appreciate this help. I now have a working environment, and wanted to share how I got there (for others who will follow).
The documentation in https://www.openldap.org/doc/admin26/quickstart.html is great, and can be followed completely, except that between step 8 and 9, you'll need to manually create two needed directories: mkdir /usr/local/etc/slapd.d mkdir /usr/local/var/openldap-data
The TLS instructions at https://www.openldap.org/doc/admin26/tls.html are misleading, as they describe use of slapd.conf, while we should be using the slapd.d directory and the 'olcTLS...' form of the parameters. While 'man slapd' states that both the slapd config file and the slapd config directory can be specified at the same time, this did not work in my testing. All of the hours that I spent trying to figure out how to enable use of TLS could have been saved by use of the instructions below:
1. Create, if needed, a server certificate / private key pair for the openldap server.
(I was able to use the certificate generated by the following command; nothing special regarding CA:False was needed)
/etc/ssl/private # openssl req -nodes -new -x509 -keyout server.key -out server.cert . . .
2. Add the lines below the "# TLS parameters" comment at the end of the 'dn: cn=config' section of /usr/local/etc/openldap/slapd.ldif (I specified use of some currently-strong TLS ciphers, as (by default) many weak ciphers will also be used):
ldpdd042:/usr/local/etc/openldap # cat slapd.ldif # # See slapd-config(5) for details on configuration options. # This file should NOT be world readable. # dn: cn=config objectClass: olcGlobal cn: config # # # Define global ACLs to disable default read access. # olcArgsFile: /usr/local/var/run/slapd.args olcPidFile: /usr/local/var/run/slapd.pid # # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #olcReferral: ldap://root.openldap.org # # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 64-bit encryption for simple bind #olcSecurity: ssf=1 update_ssf=112 simple_bind=64 # TLS parameters olcTLSCertificateFile: /etc/ssl/private/server.cert olcTLSCertificateKeyFile: /etc/ssl/private/server.key olcTLSCipherSuite: TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256
3. Remove the existing slapd configuration: rm /usr/local/etc/slapd.d/*
4. Stop the existing slapd daemon ps -ef | grep slapd kill nnnn
5. Re-create the openldap environment, using the updated slapd.ldif
/usr/local/sbin/slapadd -n 0 -F /usr/local/etc/slapd.d -l /usr/local/etc/openldap/slapd.ldif
6. Start the slapd daemon for both ldap (TCP port 389 by default) and ldaps (port 636 by default)
/usr/local/libexec/slapd -F /usr/local/etc/slapd.d -h "ldap:/// ldaps:///"
7. Verify that the slapd process is running
ps -ef | grep slapd
tail /var/log/messages
I found use of ldapmodify to be problematic regarding authentication, so opted to just delete the current configuration and replace it.
Please let me know of any additional suggestions. I'm happy to create a doc RFE, if some/all of what I've written would be useful.
Thanks! tl
Internal Use - Confidential
On Tue, May 16, 2023 at 03:18:18PM +0000, Lemons, Terry wrote:
- Remove the existing slapd configuration:
rm /usr/local/etc/slapd.d/*
[...]
- Re-create the openldap environment, using the updated slapd.ldif
/usr/local/sbin/slapadd -n 0 -F /usr/local/etc/slapd.d -l /usr/local/etc/openldap/slapd.ldif
I found use of ldapmodify to be problematic regarding authentication, so opted to just delete the current configuration and replace it.
If server is stopped, you can always use slapmodify to edit the current configuration in-place instead of a wipe/reimport.
Regards,
--On Tuesday, May 16, 2023 6:48 PM +0200 Ondřej Kuzník ondra@mistotebe.net wrote:
On Tue, May 16, 2023 at 03:18:18PM +0000, Lemons, Terry wrote:
- Remove the existing slapd configuration:
rm /usr/local/etc/slapd.d/*
[...]
- Re-create the openldap environment, using the updated slapd.ldif
/usr/local/sbin/slapadd -n 0 -F /usr/local/etc/slapd.d -l /usr/local/etc/openldap/slapd.ldif
I found use of ldapmodify to be problematic regarding authentication, so opted to just delete the current configuration and replace it.
If server is stopped, you can always use slapmodify to edit the current configuration in-place instead of a wipe/reimport.
Additionally, you should learn how to use ldapmodify to change the configuration on the fly, not hand-hack config file snippets.
--Quanah
terry.lemons@dell.com wrote:
I've followed the instructions in https://www.openldap.org/doc/admin26/quickstart.html to deploy openldap 2.6.4 on a SLES 15 SP4 system. Once I confirmed that this was working correctly, I moved on to configure TLS, following the instructions in https://www.openldap.org/doc/admin26/tls.html. When I try a connection to the LDAPS port (636), I see the following:
ldpdd040:~ # openssl s_client -connect ldpdd042.hop.lab.emc.com:636
If you're going to use openssl s_client you also need to tell it which CA and/or server certs to trust. I'd start with using ldapsearch -d -1 instead.
CONNECTED(00000003) 139702302594704: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 293 bytes
New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated 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: 1683823897 Timeout : 300 (sec) Verify return code: 0 (ok)
The '0 bytes read' keeps bothering me.
Is there a firewall on the machine? Maybe a WAF with knowledge of ldap? If it was a regular firewall, the connection would not be setup. Things would fail immediately before the client tries the handshake.
A WAF might allow the connection to succeed, but then filter the response. That might explain the 0 bytes read.
Jeff
Hi Jeff
The '0 bytes read' keeps bothering me.
Is there a firewall on the machine? Maybe a WAF with knowledge of ldap? If it was a regular firewall, the connection would not be setup. Things would fail immediately before the client tries the handshake.
A WAF might allow the connection to succeed, but then filter the response. That might explain the 0 bytes read.
I'm using a freshly-deployed SLES 15 SP4 system, on which the firewall is not installed. When I use these two commands, I see the same output (which, I _think_ would not be the case if a firewall were active on this system):
openssl s_client -connect localhost:636 -servername ldpdd042.hop.lab.emc.com -CAfile /etc/ssl/private/server.cert openssl s_client -connect ldpdd042.hop.lab.emc.com:636 -servername ldpdd042.hop.lab.emc.com -CAfile /etc/ssl/private/server.cert
Thanks tl
Internal Use - Confidential
terry.lemons@dell.com wrote:
Looping back to this... This smells bad, too:
CONNECTED(00000003) 139702302594704:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:
OpenSSL 3.x does not have the s23*.c files. Confer, https://github.com/openssl/openssl/tree/master/ssl .
The last time there were s23*.c files, like s23_lib.c, was OpenSSL 1.0.2. Confer, https://github.com/openssl/openssl/tree/OpenSSL_1_0_2-stable/ssl .
When I look that error up with with OpenSSL 3.0.2, I get a bogus error back:
$ openssl errstr 0x140790E5 error:140790E5:UI routines::reason(495845)
$ openssl version OpenSSL 3.0.2 15 Mar 2022
I'm wondering if OpenLDAP was compiled and linked against one version of the OpenSSL library, but it is getting runtime-linked with another [non-binary compat] version of OpenSSL by ldd.
Are there multiple versions of OpenSSL available on that machine?
Jeff
On Fri, May 12, 2023 at 9:59 PM Jeffrey Walton noloader@gmail.com wrote:
terry.lemons@dell.com wrote:
Looping back to this... This smells bad, too:
CONNECTED(00000003) 139702302594704:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:
OpenSSL 3.x does not have the s23*.c files. Confer, https://github.com/openssl/openssl/tree/master/ssl .
The last time there were s23*.c files, like s23_lib.c, was OpenSSL 1.0.2. Confer, https://github.com/openssl/openssl/tree/OpenSSL_1_0_2-stable/ssl .
When I look that error up with with OpenSSL 3.0.2, I get a bogus error back:
$ openssl errstr 0x140790E5 error:140790E5:UI routines::reason(495845) $ openssl version OpenSSL 3.0.2 15 Mar 2022I'm wondering if OpenLDAP was compiled and linked against one version of the OpenSSL library, but it is getting runtime-linked with another [non-binary compat] version of OpenSSL by ldd.
Are there multiple versions of OpenSSL available on that machine?
I probably should have mentioned... OpenSSL 1.0.2 is End of Life. It only supports up to TLS v1.2. But it does have full ECC support.
See how this command works for you:
openssl s_client -tls1_2 \ -connect ldpdd042.hop.lab.emc.com:636 ...
Jeff
terry.lemons＠dell.com wrote:
Hi
I've followed the instructions in https://www.openldap.org/doc/admin26/quickstart.html to deploy openldap 2.6.4 on a SLES 15 SP4 system. Once I confirmed that this was working correctly, I moved on to configure TLS, following the instructions in https://www.openldap.org/doc/admin26/tls.html. When I try a connection to the LDAPS port (636), I see the following:
ldpdd040:~ # openssl s_client -connect ldpdd042.hop.lab.emc.com:636 CONNECTED(00000003) 139702302594704: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 293 bytes
New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated 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: 1683823897 Timeout : 300 (sec) Verify return code: 0 (ok)
ldpdd040:~ #
I'm using this command to start slapd: /usr/local/libexec/slapd -F /usr/local/etc/slapd.d -s 3 -h "ldap:/// ldaps:///"
When I execute the openssl command above, I look in /var/log/messages and see:
2023-05-11T12:51:55.213884-04:00 ldpdd042 slapd[20101]: conn=1000 fd=12 ACCEPT from IP=10.247.229.40:56844 (IP=0.0.0.0:636) 2023-05-11T12:51:55.213944-04:00 ldpdd042 slapd[20101]: connection_get(12): got connid=1000 2023-05-11T12:51:55.214004-04:00 ldpdd042 slapd[20101]: connection_read(12): checking for input on id=1000 2023-05-11T12:51:55.214065-04:00 ldpdd042 slapd[20101]: connection_read(12): TLS accept failure error=-1 id=1000, closing 2023-05-11T12:51:55.214138-04:00 ldpdd042 slapd[20101]: connection_close: conn=1000 sd=12 2023-05-11T12:51:55.214207-04:00 ldpdd042 slapd[20101]: conn=1000 fd=12 closed (TLS negotiation failure) ldpdd0
I've appended these lines to /usr/local/etc/openldap/slapd.conf:
# Added TLS directives # TLSCACertificateFile /var/lib/ca-certificates/ca-bundle.pem TLSCertificateFile /etc/ssl/private/server.cert TLSCertificateKeyFile /etc/ssl/private/server.key #TLSCipherSuite ALL
I can't find any log information that helps me understand what the problem is. I'm using a self-signed server certificate that has the cn using the FQDN of the server.
How can I debug this?
Thanks! tl
Hello list,
if I understand the listed configuration correctly slapd is started with online config and the TLS information is configured in the static config file slapd.conf. Is this kind of mixed configuration valid or do the TLS information have to be configured in corresponding olc-Attributes in cn=config?
Hi Carsten
Thanks for your reply.
Hello list,
if I understand the listed configuration correctly slapd is started with online config and the TLS information is configured in the static config file slapd.conf. Is this kind of mixed configuration valid or do the TLS information have to be configured in corresponding olc-Attributes in cn=config?
I followed the instructions in https://www.openldap.org/doc/admin26/tls.html. That document contains:
16.2.1. Server Configuration The configuration directives for slapd belong in the global directives section of slapd.conf(5).
This meant, to me, that I needed to add them to /usr/local/etc/openldap/slapd.conf. Please correct me if needed.
Thanks tl
Internal Use - Confidential
Hi,
Lemons, Terry, 12.05.23:
I followed the instructions inhttps://www.openldap.org/doc/admin26/tls.html. That document contains:
16.2.1. Server Configuration The configuration directives for slapd belong in the global directives section of slapd.conf(5).
This meant, to me, that I needed to add them to /usr/local/etc/openldap/slapd.conf. Please correct me if needed.
slapd uses the static config file *or* the "modern" slapd.d directory. It cannot use both, which means that you need to choose one.
Either you take your SSL configuration settings in the modern slapd.d way (use slapd -F /path/to/slapd.d) or you use the old slapd.conf way (call slapd -f /path/to/slapd.conf then). See "man slapd" for more information.
Regards, Christian
openldap-technical@openldap.org
-
Carsten Jäckel -
Christian Schmidt -
Christopher Paul -
Howard Chu -
Jeffrey Walton -
Jordan Brown -
Lemons, Terry -
Ondřej Kuzník -
Philip Guenther -
Quanah Gibson-Mount -
Ryan Tandy -
terry.lemons＠dell.com