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