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