--On Friday, September 22, 2017 5:32 PM -0400 Christopher Wood christopher_wood@pobox.com wrote:
Two things I notice from below:
olcTLSCACertificateFile: /etc/openldap/certs/ca_cert.pem -rw-r--r--. 1 root root 1696 Sep 22 14:18 ca-cert.pem
Underscore in the first, dash in the second.
Good catch!
It's also important to note that RedHat links to MozNSS rather than GnuTLS or OpenSSL, so the standard caveats apply, and be sure to follow the documentation to MozNSS when setting up both the slapd and client (ldapsearch) side of things.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
At Fri, 22 Sep 2017 13:59:46 -0700 Quanah Gibson-Mount quanah@symas.com wrote:
--On Friday, September 22, 2017 5:32 PM -0400 Christopher Wood christopher_wood@pobox.com wrote:
Two things I notice from below:
olcTLSCACertificateFile: /etc/openldap/certs/ca_cert.pem -rw-r--r--. 1 root root 1696 Sep 22 14:18 ca-cert.pem
Underscore in the first, dash in the second.
OK, this is fixed, but it still does not work.
Good catch!
It's also important to note that RedHat links to MozNSS rather than GnuTLS or OpenSSL, so the standard caveats apply, and be sure to follow the documentation to MozNSS when setting up both the slapd and client (ldapsearch) side of things.
Where can I find a good how to for this?
All of the how tos I am finding (including RedHat's!) don't talk about MozNSS.
This is what I have now:
[root@c764guest heller]# cat /etc/openldap/slapd.d/cn=config.ldif # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 446109a2 dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/openldap/slapd.args olcPidFile: /var/run/openldap/slapd.pid olcTLSCACertificatePath: /etc/openldap/certs structuralObjectClass: olcGlobal entryUUID: 7e6a3298-30da-1037-9c4f-458bcc6c0ce0 creatorsName: cn=config createTimestamp: 20170918163057Z olcTLSCACertificateFile: /etc/openldap/certs/ca-cert.pem olcTLSCertificateFile: /etc/openldap/certs/c764guest.cert olcTLSCertificateKeyFile: /etc/openldap/certs/privkey.pem entryCSN: 20170923152535.247964Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20170923152535Z [root@c764guest heller]# dir /etc/openldap/certs/ 142f2e54.0 c764guest.cert ca-cert.pem key3.db privkey.pem 6a5e6ef2.0 c764guest.csr cert8.db password secmod.db [root@c764guest heller]# dir -l /etc/openldap/certs/ total 104 lrwxrwxrwx. 1 root root 11 Sep 23 11:28 142f2e54.0 -> ca-cert.pem lrwxrwxrwx. 1 root root 14 Sep 23 11:28 6a5e6ef2.0 -> c764guest.cert -rw-r--r--. 1 ldap ldap 5137 Sep 22 14:42 c764guest.cert -rw-r--r--. 1 root root 1074 Sep 22 14:37 c764guest.csr -rw-r--r--. 1 ldap ldap 1696 Sep 22 14:18 ca-cert.pem -rw-r--r--. 1 root root 65536 Sep 18 12:30 cert8.db -rw-r--r--. 1 root root 16384 Sep 18 12:30 key3.db -r--r-----. 1 root ldap 45 Jan 10 2016 password -rw-r--r--. 1 ldap ldap 1834 Sep 22 14:37 privkey.pem -rw-r--r--. 1 root root 16384 Jan 10 2016 secmod.db
And openssl c_connect is giving me this:
[root@c764guest heller]# openssl s_client -msg -state -showcerts -debug -CAfile /etc/openldap/certs/ca-cert.pem -connect 192.168.250.98:389 CONNECTED(00000003) write to 0x23dd760 [0x23e0400] (247 bytes => 247 (0xF7)) 0000 - 16 03 01 00 f2 01 00 00-ee 03 03 59 c6 83 16 30 ...........Y...0 0010 - 62 4c 15 7a aa ae da d3-1c 78 95 25 17 25 1d c4 bL.z.....x.%.%.. 0020 - b5 fe 0f 7a a0 f1 a2 46-d7 c4 da 00 00 84 c0 30 ...z...F.......0 0030 - c0 2c c0 28 c0 24 c0 14-c0 0a 00 a3 00 9f 00 6b .,.(.$.........k 0040 - 00 6a 00 39 00 38 00 88-00 87 c0 32 c0 2e c0 2a .j.9.8.....2...* 0050 - c0 26 c0 0f c0 05 00 9d-00 3d 00 35 00 84 c0 2f .&.......=.5.../ 0060 - c0 2b c0 27 c0 23 c0 13-c0 09 00 a2 00 9e 00 67 .+.'.#.........g 0070 - 00 40 00 33 00 32 00 9a-00 99 00 45 00 44 c0 31 .@.3.2.....E.D.1 0080 - c0 2d c0 29 c0 25 c0 0e-c0 04 00 9c 00 3c 00 2f .-.).%.......<./ 0090 - 00 96 00 41 c0 12 c0 08-00 16 00 13 c0 0d c0 03 ...A............ 00a0 - 00 0a 00 07 c0 11 c0 07-c0 0c c0 02 00 05 00 04 ................ 00b0 - 00 ff 01 00 00 41 00 0b-00 04 03 00 01 02 00 0a .....A.......... 00c0 - 00 08 00 06 00 19 00 18-00 17 00 23 00 00 00 0d ...........#.... 00d0 - 00 20 00 1e 06 01 06 02-06 03 05 01 05 02 05 03 . .............. 00e0 - 04 01 04 02 04 03 03 01-03 02 03 03 02 01 02 02 ................ 00f0 - 02 03 00 0f 00 01 01 .......
TLS 1.2 Handshake [length 00f2], ClientHello
01 00 00 ee 03 03 59 c6 83 16 30 62 4c 15 7a aa ae da d3 1c 78 95 25 17 25 1d c4 b5 fe 0f 7a a0 f1 a2 46 d7 c4 da 00 00 84 c0 30 c0 2c c0 28 c0 24 c0 14 c0 0a 00 a3 00 9f 00 6b 00 6a 00 39 00 38 00 88 00 87 c0 32 c0 2e c0 2a c0 26 c0 0f c0 05 00 9d 00 3d 00 35 00 84 c0 2f c0 2b c0 27 c0 23 c0 13 c0 09 00 a2 00 9e 00 67 00 40 00 33 00 32 00 9a 00 99 00 45 00 44 c0 31 c0 2d c0 29 c0 25 c0 0e c0 04 00 9c 00 3c 00 2f 00 96 00 41 c0 12 c0 08 00 16 00 13 c0 0d c0 03 00 0a 00 07 c0 11 c0 07 c0 0c c0 02 00 05 00 04 00 ff 01 00 00 41 00 0b 00 04 03 00 01 02 00 0a 00 08 00 06 00 19 00 18 00 17 00 23 00 00 00 0d 00 20 00 1e 06 01 06 02 06 03 05 01 05 02 05 03 04 01 04 02 04 03 03 01 03 02 03 03 02 01 02 02 02 03 00 0f 00 01 01 read from 0x23dd760 [0x23e5960] (7 bytes => 0 (0x0)) --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 247 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE ---
And slapd log contains this at the end:
Sep 23 11:51:31 c764guest.deepsoft.com slapd[28950]: conn=1036 fd=13 ACCEPT from IP=192.168.250.98:33578 (IP=192.168.250.98:389) Sep 23 11:51:31 c764guest.deepsoft.com slapd[28950]: conn=1036 fd=13 closed (connection lost) Sep 23 11:51:50 c764guest.deepsoft.com slapd[28950]: conn=1037 fd=13 ACCEPT from IP=192.168.250.98:33580 (IP=192.168.250.98:389) Sep 23 11:51:50 c764guest.deepsoft.com slapd[28950]: conn=1037 fd=13 closed (connection lost)
At this point I have no clue as to what is wrong and don't really have a clue where to look. All of the web search results suggest that I am doing the right things, but slapd is just not behaving for some unspecificed reason.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Robert Heller wrote:
All of the how tos I am finding (including RedHat's!) don't talk about MozNSS.
Unfortunately the libnss wrapper code re-uses the directives TLSCACertificatePath, TLSCertificateFile and TLSCertificateKeyFile in a different way.
So when using the RHEL/CentOS packages linked to libnss you should read slapd.conf(5) or slapd-config(5) more carefully, especially the text after "When using Mozilla NSS..".
Ciao, Michael.
P.S.: I consider this abuse of well-known TLS config directives for other purposes to be a real deficiency of the crypto lib wrappers for libnss and GnuTLS. Library-specific configuration options should be just that: Library-specific with their own specific name.
openldap-technical@openldap.org