Just found the problem and the solution. It occurred that there was also a (probably mistakenly) second config module activated.
The module I had configured with ppolicy, was not used. The extra module that was active, did not have the ppolicy overlay loaded. After correcting this, all seems to work as expected. -----Oorspronkelijk bericht----- Van: openldap-technical [mailto:[email protected]] Namens [email protected] Verzonden: donderdag 28 juli 2016 14:00 Aan: [email protected] Onderwerp: openldap-technical Digest, Vol 104, Issue 21 Send openldap-technical mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit http://www.openldap.org/lists/mm/listinfo/openldap-technical or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of openldap-technical digest..." Send openldap-technical mailing list submissions to [email protected] When replying, please edit your Subject: header so it is more specific than "Re: openldap-technical digest..." Today's Topics: 1. Re: need to recover slapd password and upgrade openldap (Dan Hyatt) 2. Re: Antw: Intermediate certificates not being sent (Nat Sincheler) 3. Re: sizelimit (Maily Peng) 4. Missing user entries after restoring a backup ldif (Matt Spaulding) 5. password policies not functioning properly (Kruger, P (Justid)) 6. Re: sizelimit (Dieter Kl?nter) 7. Re: Antw: Intermediate certificates not being sent (Ulrich Windl) ---------------------------------------------------------------------- Message: 1 Date: Tue, 26 Jul 2016 12:15:00 -0500 From: Dan Hyatt <[email protected]> To: Aaron Richton <[email protected]>, [email protected] Cc: [email protected] Subject: Re: need to recover slapd password and upgrade openldap Message-ID: <[email protected]> Content-Type: text/plain; charset=windows-1252; format=flowed So, a more simple question... Can I install a current version of OpenLDAP on a current RedHat/Centos server (specially built for this purpose. Then use slapcat to export the information from the old server, import it to the new server, where the admin password is not corrupt. Can I import the schemas or are there likely substantial changes to the schemas across versions? My goals are to create a new LDAP server running Centos/Redhat, transfer 20 users and allow them to keep their existing passwords, allow them to access my servers, and allow them authentication to samba. and create an LDAP slave (or cluster) not sure if syncrepl is the current way to go. I have root to the server, but I do not have the admin password to the Openldap 2.2 as it became corrupted somehow. On 07/24/2016 09:15 PM, Aaron Richton wrote: > On Fri, 22 Jul 2016, Dan Hyatt wrote: > >> My admin openLDAP 2.2 password became corrupt in the last week and I >> cannot > [...] >> I found some instructions which seem simple risky and no backout >> strategy. Simply running >> http://techiezone.rottigni.net/2011/12/change-root-dn-password-on-openldap/ >> > > That link (apparently from 2011) doesn't apply to your software from > 2003. There's no back-config in OpenLDAP 2.2. So don't try that... @(#) $OpenLDAP: slapd 2.2.13 (Nov 26 2010 07:45:22) $ [email protected]:/builddir/build/BUILD/openldap-2.2.13/openldap-2.2.13/build-servers/servers/slapd > > [...] >> Having the LDAP on two separate hyper visors (with local disks) to >> avoid the storage/authentication chicken/egg >> Is there a better upgrade plan > > Are you saying that your one and only LDAP server uses itself for its > own A&A? Authentication and Authorization? The server provides authentication and authorization for my group. The server only does LDAP and home dirs. I want to upgrade it to Centos 6.8 or Centos 7 (that is equal to redhat 6.8 or redhat 7) on a hypervisor with a slave running the current favored release. > > [...] >> I have the log files, is there a way to backout to last week without >> the admin password (which became corrupt last week). > > I'm not sure what you're referring to by "log files." The general-case > OpenLDAP backup tool is slapcat(8). Hopefully you have been running it > routinely. The resulting LDIF can be easily inspected; if you have > enough backups, you might even be able to find one without corruption. We took over responsibility the LDAP in December, there was not a happy handoff... no documenation..just the password and had to move it to the new VLAN. ------------------------------ Message: 2 Date: Tue, 26 Jul 2016 08:20:14 -0700 From: Nat Sincheler <[email protected]> To: Ulrich Windl <[email protected]>, [email protected] Subject: Re: Antw: Intermediate certificates not being sent Message-ID: <[email protected]> Content-Type: text/plain; charset=windows-1252; format=flowed On 7/25/2016 11:24 PM, Ulrich Windl wrote: >>>> Nat Sincheler <[email protected]> schrieb am 25.07.2016 um 19:06 in > Nachricht <[email protected]>: >> We have an OpenLDAP server that is listening on port 636 over ldaps. >> When I run >> >> openssl s_client -showcerts -connect ldap-server:636 >> >> I only see the host certificate. The intermediate and root certificates >> do *not* come through. > > If I di that on one of outr servers, I get: > Root CA > Intermediate CA > Server Certificate > > ... > New, TLSv1/SSLv3, Cipher is AES256-SHA > Server public key is 2048 bit > >> >> For this server I have in the file slapd.d/cn=config.ldif the setting >> >> olcTLSCACertificatePath: /etc/ssl/certs > > Hi! > > Here it works with these settings: > olcTLSCACertificatePath: /etc/ssl/certs > olcTLSCertificateFile: /etc/ssl/servercerts/slapd.pem > olcTLSCertificateKeyFile: /etc/ssl/private/slapd.key > > Could it be a permissions problem? Did you try to check the certificate chain > with openssl (preferrable as LDAP user)? When I run the openssl s_client command I get no errors, but I also get no intermediate or root certificates sent. I see this in the output: "No client certificate CA names sent". It appears that OpenLDAP is not sending the intermediate or root certificates. However, if I put all the intermediate and root certificates into a single file and point olcTLSCACertificateFile at this file, those intermediate certificates _are_ sent. So, it appears that olcTLSCACertificateFile sends the certificates but but olcTLSCACertificatePath does not. Am I misunderstanding the purpose olcTLSCACertificatePath? Thanks. > > Regards, > Ulrich > >> >> I checked and all the intermediate and root certificates are in >> /etc/ssl/certs soft-linked via the usual OpenSSL rehash hash, e.g., >> >> lrwxrwxrwx 1 root root 42 Jul 14 19:03 b4261fc2.0 -> >> /etc/ssl/certs/incommon-usertrust-2024.pem >> >> Any idea why the intermediate and root certificates do not get sent to >> the LDAPS client? Is there something in the LDAP log that might give me >> a clue as to what is going on? > > > > ------------------------------ Message: 3 Date: Tue, 26 Jul 2016 19:47:27 +0200 From: Maily Peng <[email protected]> To: Frank Swasey <[email protected]> Cc: [email protected] Subject: Re: sizelimit Message-ID: <[email protected]> Content-Type: text/plain; charset="windows-1252"; Format="flowed" Hello Frank, Nope, the limits directive are unlimited on the provider. First of all, I need to have access to all of the entries on the consumers , in order to check EntryCSN between provider and consumers. I use the python script : check_syncrepl_extended that needs to bind provider and consumer via the same dn. That's why I could not use rootdn . ( not the same between slapd servers) . thank you Le 26/07/2016 ? 19:09, Frank Swasey a ?crit : > You have shown us what the syncrepl, sizelimit and limits look like on > your consumer. Have you got that limits directive also set up on your > provider? It is the provider that needs to allow your replication DN > to obtain unlimited entries. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.openldap.org/lists/openldap-technical/attachments/20160726/391713f4/attachment.html> ------------------------------ Message: 4 Date: Tue, 26 Jul 2016 22:16:24 -0700 From: Matt Spaulding <[email protected]> To: [email protected] Subject: Missing user entries after restoring a backup ldif Message-ID: <CAF8MFWUJo=5su_RyF0YUHv3hJjRJ6fdHCs7WbhYxqB_y=wf...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hello, I restored an ldap database using the command: slapadd -l /my/file.ldif The restore went completely without error. But when I go to do an ldapsearch I find that some of the users that should be in the database are not there. I go back and edit my ldif backup file and search for the uids of the users and confirm that they are in fact in the ldif file. Why would something like this happen? Best Regards, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.openldap.org/lists/openldap-technical/attachments/20160726/76b0d94a/attachment.html> ------------------------------ Message: 5 Date: Wed, 27 Jul 2016 14:48:03 +0000 From: "Kruger, P (Justid)" <[email protected]> To: "'[email protected]'" <[email protected]> Subject: password policies not functioning properly Message-ID: <0225c0718c172540817182b2e2b3160c20343...@jstd-psexch02.ad.minjus.nl> Content-Type: text/plain; charset="us-ascii" I've set password policies on my OpenLDAP 2.4. Unfortunately things do not work as expected and although extensively searched on forums and Google, I cannot get the proper results. What am I missing in what I did or should have done? What goes wrong: - Password policies seem not to be validated or I do get a failure message The failures depend on pwdinHistory setting to zero (no failure) to > 0 failure like given below 5798c94a <= acl_access_allowed: granted to database root 5798c94a bdb_modify_internal: replace userPassword 5798c94a bdb_modify_internal: replace pwdChangedTime 5798c94a bdb_modify_internal: add pwdHistory 5798c94a bdb_modify_internal: replace pwdChangedTime 5798c94a bdb_modify_internal: add pwdHistory 5798c94a bdb_modify_internal: 20 modify/add: pwdHistory: value #0 already exists 5798c94a hdb_modify: modify failed (20) 5798c94a send_ldap_result: conn=1000 op=18 p=3 5798c94a send_ldap_result: err=20 matched="" text="modify/add: pwdHistory: value #0 already exists" 5798c94a send_ldap_response: msgid=62 tag=103 err=20 ber_flush2: 61 bytes to sd 15 0000: 30 3b 02 01 3e 67 36 0a 01 14 04 00 04 2f 6d 6f 0;..>g6....../mo 0010: 64 69 66 79 2f 61 64 64 3a 20 70 77 64 48 69 73 dify/add: pwdHis 0020: 74 6f 72 79 3a 20 76 61 6c 75 65 20 23 30 20 61 tory: value #0 a 0030: 6c 72 65 61 64 79 20 65 78 69 73 74 73 lready exists ldap_write: want=61, written=61 0000: 30 3b 02 01 3e 67 36 0a 01 14 04 00 04 2f 6d 6f 0;..>g6....../mo 0010: 64 69 66 79 2f 61 64 64 3a 20 70 77 64 48 69 73 dify/add: pwdHis 0020: 74 6f 72 79 3a 20 76 61 6c 75 65 20 23 30 20 61 tory: value #0 a 0030: 6c 72 65 61 64 79 20 65 78 69 73 74 73 lready exists 5798c94a conn=1000 op=18 RESULT tag=103 err=20 text=modify/add: pwdHistory: value #0 already exists 5798c94a slap_graduate_commit_csn: removing 0x7f8a0c107960 20160727144634.392449Z#000000#000#000000 This makes, as far as I tested, no difference with just using a default policy or when using a default and specific policy with pwdPolicySubentry attribute in the user. I've used ACL's on my LDAP schema. My purpose: Use a default policy which basically says to use no policy Add a specific policy for users in a subtree. Below are the steps and LDAP LDIF files used to build the OpenLDAP. Included here are the LDIF files for: config, base and sub part of tree, replication ou and user, application users (service accounts), ldap managers ou, ACL's, OU's needed for application specific content, policy. Excluded here (but done) are the LDIF files for: enable logging, replication, TLS/SSL. The LDIF files first line contains the LDIF filename and the command used to apply them # ldapadd -Y EXTERNAL -H ldapi:/// -f 01_addrootpw.ldif dn: olcDatabase={0}config,cn=config changetype: modify add: olcRootPW olcRootPW: {SSHA}hashhashhashhashhashhash # ldapadd -Y EXTERNAL -H ldapi:/// -f 02_root-base.ldif # change olcRootPW to your Root password # change domain parts to your domain dn: olcDatabase={1}monitor,cn=config changetype: modify replace: olcAccess olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read by dn.base="cn=Manager,ou=ldapbeheerders,dc=example,dc=nl" read by * none dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcSuffix olcSuffix: dc=example,dc=nl dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcRootDN olcRootDN: cn=Manager,ou=ldapbeheerders,dc=example,dc=nl dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcRootPW olcRootPW: {SSHA} hashhashhashhashhashhash dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcAccess olcAccess: {0}to attrs=userPassword,shadowLastChange by dn="cn=Manager,ou=ldapbeheerders,dc=example,dc=nl" write by anonymous auth by self write by * none olcAccess: {1}to dn.base="" by * read # ldapadd -x -D cn=Manager,ou=ldapbeheerders,dc=example,dc=nl -W -f 03_ldap-manager.ldif dn: dc=example,dc=nl objectClass: top objectClass: dcObject objectclass: organization o: example nl dc: example dn: ou=ldapbeheerders,dc=example,dc=nl objectclass: organizationalUnit ou: ldapbeheerders dn: cn=Manager,ou=ldapbeheerders,dc=example,dc=nl objectclass: organizationalRole cn: Manager description: Directory Manager # ldapadd -x -D cn=Manager,ou=ldapbeheerders,dc=example,dc=nl -W -f 04_replication_user.ldif dn: ou=replicatie,dc=example,dc=nl objectclass: organizationalUnit ou: replicatie description: replicatie groep dn: cn=replicator,ou=replicatie,dc=example,dc=nl cn: replicator sn: user objectClass: person userPassword: passwordincleartext # ldapadd -x -D cn=Manager,ou=ldapbeheerders,dc=example,dc=nl -W -f 05_applications.ldif # Create ou generic application scheme dn: ou=applicaties,dc=example,dc=nl objectclass: organizationalUnit ou: applicaties # Aanmaak ou APP1 applicatieschema dn: ou=APP1,dc=example,dc=nl objectclass: organizationalUnit ou: APP1 # Aanmaak ou APP2 applicatieschemas dn: ou=APP2,dc=example,dc=nl objectclass: organizationalUnit ou: APP2 # ldapadd -x -D cn=Manager,ou=ldapbeheerders,dc=example,dc=nl -W -f 06_ServiceAccounts.ldif dn: ou=ServiceAccounts,dc=example,dc=nl objectclass: organizationalUnit ou: ServiceAccounts description: Service Accounts Applicaties #Service account APP1 dn: cn=SAAPP1,ou=ServiceAccounts,dc=example,dc=nl cn: SAAPP1 sn: user objectClass: person userPassword: {SSHA}hashedpassword description: Service Account APP1 #Service account APP2 dn: cn=SAAPP2,ou=ServiceAccounts,dc=example,dc=nl cn: SAAPP2 sn: user objectClass: person userPassword: {SSHA} hashedpassword description: Service Account APP2 # ldapadd -x -D cn=Manager,ou=ldapbeheerders,dc=example,dc=nl -W -f 07_ACL.ldif dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcAccess olcAccess: to attrs=userPassword by anonymous auth by self write by * break olcAccess: to dn="ou=replicatie,dc=example,dc=nl" by self write by * none olcAccess: to * by dn.base="cn=replicator,ou=replicatie,dc=example,dc=nl" read by * break olcAccess: to dn.subtree="cn=default,ou=policies,dc=example,dc=nl" by dn.children="ou=ldapbeheerders,dc=example,dc=nl" write by * none olcAccess: to dn="ou=ldapbeheerders,dc=example,dc=nl" by dn.children="ou=ldapbeheerders,dc=example,dc=nl" write by * none olcAccess: to dn="ou=ServiceAccounts,dc=example,dc=nl" by self search by * none olcAccess: to dn.subtree="ou=applicaties,dc=example,dc=nl" by dn.children="ou=ServiceAccounts,dc=example,dc=nl" write by * none olcAccess: to dn.subtree="ou=APP1,dc=example,dc=nl" by dn.base="cn=SAAPP1,ou=ServiceAccounts,dc=example,dc=nl" write by * none olcAccess: to dn.subtree="ou=APP2,dc=example,dc=nl" by dn.base="cn=SAAPP2,ou=ServiceAccounts,dc=example,dc=nl" write by * none olcAccess: to dn.children="dc=example,dc=nl" by * read olcAccess: to dn.children="dc=nl" by * read # ldapadd -x -D cn=Manager,ou=ldapbeheerders,dc=example,dc=nl -W -f 08_Add-testusers.ldif dn: uid=APP1_1,ou=APP1gebruikers,ou=APP1,dc=example,dc=nl objectClass: inetOrgPerson objectClass: organizationalPerson ObjectClass: person objectClass: top uid: APP1_1 cn: APP1_1 gebruiker sn: gebruiker pwdPolicySubentry: cn=default,ou=policies,ou=APP1,dc=example,dc=nl dn: uid=APP1_2,ou=APP1gebruikers,ou=APP1,dc=example,dc=nl objectClass: inetOrgPerson objectClass: organizationalPerson ObjectClass: person objectClass: top uid: APP1_2 cn: APP1_2 gebruiker sn: gebruiker pwdPolicySubentry: cn=default,ou=policies,ou=APP1,dc=example,dc=nl dn: cn=APP2_1,ou=APP2gebruikers,ou=APP2,dc=example,dc=nl objectClass: inetOrgPerson objectClass: organizationalPerson ObjectClass: person objectClass: top uid: APP2_1 cn: APP2_1 gebruiker sn: gebruiker dn: cn=APP2_2,ou=APP2gebruikers,ou=APP2,dc=example,dc=nl objectClass: inetOrgPerson objectClass: organizationalPerson ObjectClass: person objectClass: top uid: APP2_2 cn: APP2_2 gebruiker sn: gebruiker dn: cn=APP2_3,ou=gebruikers,ou=applicaties,dc=example,dc=nl objectClass: inetOrgPerson objectClass: organizationalPerson ObjectClass: person objectClass: top uid: APP2_3 cn: APP2_3 gebruikercat sn: gebruiker dn: cn=APP2_4,ou=gebruikers,ou=applicaties,dc=example,dc=nl objectClass: inetOrgPerson objectClass: organizationalPerson ObjectClass: person objectClass: top uid: APP2_4 cn: APP2_4 gebruiker sn: gebruiker Below is the part where the password policies are configured. # ldapadd -Y EXTERNAL -H ldapi:/// -f P01_ppolicymodule.ldif dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModuleLoad: ppolicy.la olcModulePath: /usr/lib64/openldap # ldapadd -Y EXTERNAL -H ldapi:/// -f P02_ppolicyoverlay.ldif dn: olcOverlay=ppolicy,olcDatabase={2}hdb,cn=config objectClass: olcPPolicyConfig olcOverlay: ppolicy olcPPolicyDefault: cn=default,ou=policies,dc=example,dc=nl olcPPolicyUseLockout: TRUE olcPPolicyHashCleartext: TRUE # ldapadd -x -D 'cn=Manager,ou=ldapbeheerders,dc=example,dc=nl' -W -f P03_default_ppolicy.ldif dn: ou=policies,dc=example,dc=nl objectClass: top objectClass: organizationalUnit ou: policies dn: cn=default,ou=policies,dc=example,dc=nl objectClass: top objectClass: device objectClass: pwdPolicyChecker objectClass: pwdPolicy cn: default pwdAttribute: userPassword pwdInHistory: 8 pwdMinLength: 8 pwdMaxFailure: 5 pwdFailureCountInterval: 1800 pwdCheckQuality: 1 pwdMustChange: TRUE pwdGraceAuthNLimit: 0 pwdMaxAge: 7776000 pwdExpireWarning: 1209600 pwdLockoutDuration: 900 pwdLockout: TRUE pwdSafeModify: FALSE # ldapadd -x -D 'cn=Manager,ou=ldapbeheerders,dc=example,dc=nl' -W -f P04_APP1_ppolicies.ldif dn: ou=policies,ou=APP1,dc=example,dc=nl ou: policies objectClass: top objectClass: organizationalUnit dn: cn=default,ou=policies,ou=APP1,dc=example,dc=nl objectClass: top objectClass: device objectClass: pwdPolicy cn: default pwdAttribute: userPassword pwdAllowUserChange: TRUE pwdCheckQuality: 0 pwdExpireWarning: 374400 pwdFailureCountInterval: 1800 pwdGraceAuthNLimit: 5 pwdInHistory: 12 pwdLockout: TRUE pwdLockoutDuration: 0 pwdMaxAge: 2592000 pwdMaxFailure: 5 pwdMinAge: 0 pwdMinLength: 8 pwdMustChange: TRUE pwdSafeModify: FALSE -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.openldap.org/lists/openldap-technical/attachments/20160727/75163e93/attachment.html> ------------------------------ Message: 6 Date: Wed, 27 Jul 2016 23:36:29 +0200 From: Dieter Kl?nter <[email protected]> To: [email protected] Subject: Re: sizelimit Message-ID: <[email protected]> Content-Type: text/plain; charset=UTF-8 Am Mon, 25 Jul 2016 13:23:50 +0200 schrieb Maily Peng <[email protected]>: > Hi all, > > I can not apply a limits directive to my slapd.conf. I need a user > (cn=replicator,ou=AppUsers,dc=company,dc=net) to have read access to > all entries of a database. > The global sizelimits ( 1000) seems to override any other database > directive. Each ldapsearch returns a " 4 Size limit exceeded". [...] read slapd.conf(5), section GENERAL DATABASE OPTIONS within a database declaration you may set limits dn.base=cn=replicator,..... size=unlimited time=unlimited and within a syncrepl configuration sizelimit=unlimited timelimit=unlimited Note that syncrepl is a ldap client, thus some parameters from ldap.conf(5) might be applicable. -Dieter -- Dieter Kl?nter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53?37'09,95"N 10?08'02,42"E ------------------------------ Message: 7 Date: Thu, 28 Jul 2016 08:19:43 +0200 From: "Ulrich Windl" <[email protected]> To: <[email protected]>,<[email protected]> Subject: Re: Antw: Intermediate certificates not being sent Message-ID: <[email protected]> Content-Type: text/plain; charset=US-ASCII >>> Nat Sincheler <[email protected]> schrieb am 26.07.2016 um 17:20 in Nachricht <[email protected]>: > > On 7/25/2016 11:24 PM, Ulrich Windl wrote: >>>>> Nat Sincheler <[email protected]> schrieb am 25.07.2016 um 19:06 in >> Nachricht <[email protected]>: >>> We have an OpenLDAP server that is listening on port 636 over ldaps. >>> When I run >>> >>> openssl s_client -showcerts -connect ldap-server:636 >>> >>> I only see the host certificate. The intermediate and root certificates >>> do *not* come through. >> >> If I di that on one of outr servers, I get: >> Root CA >> Intermediate CA >> Server Certificate >> >> ... >> New, TLSv1/SSLv3, Cipher is AES256-SHA >> Server public key is 2048 bit >> >>> >>> For this server I have in the file slapd.d/cn=config.ldif the setting >>> >>> olcTLSCACertificatePath: /etc/ssl/certs >> >> Hi! >> >> Here it works with these settings: >> olcTLSCACertificatePath: /etc/ssl/certs >> olcTLSCertificateFile: /etc/ssl/servercerts/slapd.pem >> olcTLSCertificateKeyFile: /etc/ssl/private/slapd.key >> >> Could it be a permissions problem? Did you try to check the certificate > chain with openssl (preferrable as LDAP user)? > > When I run the openssl s_client command I get no errors, but I also get > no intermediate or root certificates sent. I see this in the output: "No > client certificate CA names sent". Hi! To me it looks like a problem with your certificates. Try to verify them using openssl, like this: openssl verify -CApath /etc/ssl/certs -verbose /etc/ssl/servercerts/slapd.pem /etc/ssl/servercerts/slapd.pem: OK Regards, Ulrich > > It appears that OpenLDAP is not sending the intermediate or root > certificates. > > However, if I put all the intermediate and root certificates into a > single file and point olcTLSCACertificateFile at this file, those > intermediate certificates _are_ sent. > > So, it appears that olcTLSCACertificateFile sends the certificates but > but olcTLSCACertificatePath does not. > > Am I misunderstanding the purpose olcTLSCACertificatePath? > > Thanks. > > >> >> Regards, >> Ulrich >> >>> >>> I checked and all the intermediate and root certificates are in >>> /etc/ssl/certs soft-linked via the usual OpenSSL rehash hash, e.g., >>> >>> lrwxrwxrwx 1 root root 42 Jul 14 19:03 b4261fc2.0 -> >>> /etc/ssl/certs/incommon-usertrust-2024.pem >>> >>> Any idea why the intermediate and root certificates do not get sent to >>> the LDAPS client? Is there something in the LDAP log that might give me >>> a clue as to what is going on? >> >> >> >> ------------------------------ Subject: Digest Footer _______________________________________________ openldap-technical mailing list [email protected] http://www.openldap.org/lists/mm/listinfo/openldap-technical ------------------------------ End of openldap-technical Digest, Vol 104, Issue 21 ***************************************************
