On Thu, May 11, 2023 at 3:46 PM Howard Chu <[email protected]> wrote:
>
> [email protected] 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
