On 09/19/2014 10:43 AM, Sterling Sahaydak wrote: > > I was told by the Chief Architect, OpenLDAP the following: > > "This has nothing to do with OpenLDAP. Your build is using the MozNSS > crypto library, ask them for help." > > > So, here is my setup - > > I've recently updated both my openldap servers to 2.4.39 version and > everything seems to be working EXCEPT the mirror synchronization which > was the issue I had previously with 2.4.23 > Running on CentOS 6.5 > > Setup - > > Server1(provider): ldap-east.xxxxx.net > Server2(consumer): ldap-west.xxxxx.net > > Not using self signed certs. Instead have a SAN(Subject Alternative > Name)cert from DigiCert with 4 hostnames: > > ldap.xxxxx.net > ldap-1.xxxxx.net > ldap-2.xxxxx.net > ldap-alt.xxxxx.net > > I'm using slapd.conf vs cn=config. > > A code snippet of my slapd.conf file showing the TLS setup: > > [root@ldap-east openldap]# cat slapd.conf > > include /etc/openldap/schema/core.schema > include /etc/openldap/schema/cosine.schema > include /etc/openldap/schema/inetorgperson.schema > include /etc/openldap/schema/nis.schema > include /etc/openldap/schema/sudo.schema > > allow bind_v2 > > TLSCertificateFile /etc/openldap/certs/ldap_xxxxx_net.crt > TLSCertificateKeyFile /etc/openldap/certs/ldap_xxxxx_net.key > TLSCACertificateFile /etc/openldap/certs/CAcompany.crt > > > > > > The details of the Error Msg: > > [root@ldap-east certs]# slapd -d sync > 541b16ed @(#) $OpenLDAP: slapd 2.4.39 (Sep 16 2014 19:42:16) $ > > r...@admin.pcoral.net:/root/rpmbuild/BUILD/openldap-2.4.39/openldap-2.4.39/servers/slapd > 541b16ed /etc/openldap/slapd.conf: line 165: warning, destination > attributeType 'sAMAccountName' is not defined in schema > 541b16ed PROXIED attributeDescription "SAMACCOUNTNAME" inserted. > 541b16ed /etc/openldap/slapd.conf: line 215: rootdn is always granted > unlimited privileges. > 541b16ed bdb_monitor_db_open: monitoring disabled; configure monitor > database to enable > 541b16ed slapd starting > TLS: error: the certificate '/etc/openldap/certs/ldap_xxxxx_net.crt' > could not be found in the database - error -12285:Unable to find the > certificate or key necessary for authentication.. > TLS: certificate '/etc/openldap/certs/ldap_xxxxx_net.crt' successfully > loaded from PEM file. > TLS: no unlocked certificate for certificate > 'CN=ldap.xxxxx.net,O="xxxxxx, INC.",L=Alviso,ST=California,C=US'. > 541b16ed do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - REFRESH_DELETE > > > *** I wonder if there is something about SAN certs where ldap is having > issues ? > *** Since it is a signed CA cert in a mirror sync setup do I need to set > it up in the local CA(using certutil) and add it? (didn't have to for > non-sync use) > *** Unclear of 'not found in database' - which one? I've tried adding > it using certutil in various permutations of setting adding the cert to > the local CA database with all the various SAN names as different nick > names > *** I've also setup symlinks in /etc/openldap/certs pointing from the > hashes -> certs - but all of these with the exact same output as above. > >
I saw a very similar question on the python-ldap list a couple of days ago, I wonder if this is related. The ldap library on Red Hat systems is configured to use NSS not OpenLDAP. The NSS support implemented in the tls_m.c file which is part of the ldap distribution. The LDAP folks generally don't want to support NSS which is probably why you were referred here. Your best bet might be work with the author of tls_m.c who is Rich Megginson <rmegg...@redhat.com> However having said that I took a look at what you posted and the source code tls_m.c. There is not enough information in what you provided to help in any great detail. I think you might be getting confused by some of the debug messages because the way tls_m.c works is it will try a few different approaches until one succeeds. Some of the messages you posted are examples of that. Note how you got a message about the cert being successfully loaded after the message about being unable to find the cert. The message about the NSS database is thus a red herring. tls_m.c should work fine with PEM files and thus I'd wouldn't go down the route of trying muck with NSS databases yet (unless you're really conversant with what you're doing). I would make sure the files you are providing are valid and in the right format. For instance is the key file actually PKCS12 format requiring a password or is it PEM? Is the cert chain fully available in the CA file? Are the files readable? Is SElinux enforcing enabled? Are there AVC's? Do the exact same files work in another context? If you're adventurous and can do C debugging I would ldap under GDB and break in the method tlsm_add_key_from_file() and make sure your private key is getting loaded. HTH, John -- John -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
