Search results for "starttls" - openldap-technical

Re: how to configure use of tls w/ rwm-rewritemap

by Ron Peterson

Using an ldaps://... URI works, so I'll just do that I guess. If there's a starttls way of doing this, that would be nice to know about, but at least I can create a secure connection. -Ron- 2011-07-01_09:42:56-0400 Ron Peterson <rpeterso(a)mtholyoke.edu>: > Hi, > > I have a rewrite map configured like: > > database ldap > suffix "ou=myou" > uri "ldap://my.backend/" > tls start tls_cacertdir=/my/ca/cert/dir > rwm-rewriteMap ldap uid2adminDN "ldap://my.backend/ou=yada,dc=yada?dn?sub" binddn="uid=someone,..." credentials="etc" > > My back end is configured to require tls, i.e. > > security ssf=128 update_ssf=128 simple_bind=128 > > If I remove that requirement, everything works. When I add it, my back > end ldap server logs: > > Jul 1 09:24:28 mid slapd[13011]: conn=1006 op=0 BIND dn="uid=someone,..." method=128 > Jul 1 09:24:28 mid slapd[13011]: conn=1006 op=0 RESULT tag=97 err=13 text=confidentiality required > > How do I configure rwm-rewritemap to use tls? > > -Ron-

13 years, 4 months

Re: Ipad/iPhone ldap setup

by Mark Cave-Ayland

On 21/02/11 20:25, Chris Jackson wrote: > I am having trouble accessing my openldap server over SSL using an > iPhone/iPad/iPod Touch using ios 4.2.1. If I check the SSL box in the > client setup on the iPhone/iPad/iPod Touch I get an error in the slapd > log -- TLS negotiation Failure. With logging level 9 I get TLS accept > failure error=-1 id=1. > > Other clients work fine over SSL/StartTLS. Outlook, addressbook in osX > 10.6, jxplorer. > > I am using openldap 2.4.19-15 on RHEL6 with a comodo wildcard SSL cert. FWIW we had a similar problem here with our mail server accepting IMAPS connections fine from everything except iPhones. After some experimentation, I eventually found out it was because I had generated our new SSL keys with "openssl gendsa" and it seems that for some reason known only to Apple, only RSA keys as opposed to DSA keys are supported in their iPhone TLS/SSL implementation. Regenerating a new key with "openssl genrsa" instead and using that to sign the server SSL certificate instead solved the problem and allowed the iPhones to connect. HTH, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

13 years, 8 months

Re: MirrorMode sync only happening in one direction

by Howard Chu

Daniel Qian wrote: > The problem direction has the same syncrepl configuration as the working > one except for the rid and provider name: > > olcSyncrepl: {0} > rid=102 provider="ldap://server2.prod:389/" > type=refreshAndPersist > retry="60 30 300 +" > keepalive=1200:10:3 > searchbase="dc=mydomain,dc=com" > bindmethod=simple > binddn="cn=replica,dc=mydomain,dc=com" > credentials=xxxxxx > starttls=critical > tls_cacert="/etc/pki/CA/cacert.pem" > > On the consumer side I am seeing these messages: > > Sep 22 22:02:02 ldaprov1 slapd[15466]: do_syncrep2: rid=102 got search > entry without Sync State control > Sep 22 22:02:02 ldaprov1 slapd[15466]: do_syncrepl: rid=102 rc -1 > retrying (29 retries left) > > and on the provider side I am seeing these: > The sync connection is supposed to be persistent but it keeps closing > down and reconnecting. > > Anyone know what could be the reason? Obviously your "provider side" doesn't actually have the syncprov overlay configured. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

13 years, 1 month

Re: ldapsearch agains Tivoli Directory Server

by Dan White

On 10/18/12 13:28 -0700, Alejandro Rodriguez Luna wrote: >Hi all! >I have a TDS (Tivoli Directory Server) in one of my servers, every time i > need to query it i need to go to another server and do it, i'd like to >be able to query from my machine, but i can't using openldap, do you >guys have a hint/idea/clue?? > >i use this from another server > >idsldapsearch -h ldapserver.homeluna.org -Z -K /opt/PolicyDirector/ssl/homeluna.kdb -P passw0rd -b "" -s base objectclass=* > >btw, My servers only accepts SSL conections. Assuming that -Z has the same effect as with OpenLDAP's ldapsearch, it performs StartTLS over port 389, not ssl over port 636. >btw, i put the following values inside /etc/openldap/ldap.conf without succeed. > ># ># LDAP Defaults ># >BASE l=world >URI ldap://ldapserver.homeluna.org ldap://ldapserver.homeluna.org:636 >PORT 636 > >TLS_CACERT /home/alexrl/Desktop/ldapserver.homeluna.org.cer >TLS_REQCERT demand > >alexrl@localhost ~ $ ldapsearch -v -H ldaps://ldapserver.homeluna.org -Dcn=root -w passw0rd -bl=world uid=alex* >ldap_initialize( ldaps://ldapserver.homeluna.org:636/??base ) >ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) Try using options '-H ldap://ldapserver.homeluna.org' and '-Z' (or '-ZZ'). See the manpage for ldapsearch. -- Dan White

12 years

Re: Ubuntu Server 12.04: StartTLS

by Admus

On 11/05/2012 09:24 PM, Philip Guenther wrote: > On Mon, 5 Nov 2012, Admus wrote: > ... >> The output of `gnutls-cli --print-cert -p 636 ldap1.example.com` is: >> >> - The hostname in the certificate matches 'ldap1.example.com'. >> - Peer's certificate issuer is unknown >> - Peer's certificate is NOT trusted > In order to verify the server's certificate, root CA that's 'above' the > server's cert needs to be configured as a trusted CA for the client. > > For OpenSSL, that's done by placing it in the file designated by the > TLS_CACERT ldap.conf option, or in the directory designated by the > TLS_CACERTDIR ldap.conf option with the correct hashed filename. > > The ldap.conf(5) manpage indicates that the latter is ignored for GnuTLS, > so presumably you just have to place the trusted root certificate(s) in a > single file and point TLS_CACERT at that, in whatever format GnuTLS uses. > > > Philip Guenther > My cn=config looks as follow: olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem olcTLSCertificateFile: /etc/ssl/certs/ldap1_slapd_cert.pem olcTLSCertificateKeyFile: /etc/ssl/private/ldap1_slapd_key.pem I tried also set TLS_CACERT in /etc/ldap/ldap.conf to: TLS_CACERT /etc/ssl/certs/cacert.pem and TLS_CACERT /etc/ssl/certs/ldap1_slapd_cert.pem but without success, the error has became same. What should be TLS_CACERT value? Is /etc/ldap/ldap.conf respected at all? My client and server is the same host.

12 years

Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation

by Dieter Kluenter

Robert Heller <heller(a)deepsoft.com> writes: > OK, I have narrowed things down to slapd and sssd not playing nice with each > other. slapd is able to listen on ldaps (port 636) and accept SSL connections > (eg from openssl s_client and other applications using straight SSL). slapd > will also listen on ldap (port 389), but refuses to negotiate a TLS connection > on port 389. It also refuses to negotiate TLS connection on port 636. sssd > seems to *insist* on negotiating a TLS connection on port 636 or port 389 and > won't just connect using ssl to port 636. (At least that is what I *think* is > going on.) > > So, I either need to get slapd to do TLS negotiation on port 389 OR port 636, > or get sssd to NOT do TLS negotiation on port 636 and just connect with SSL. > > How the hell do I get that to happen? [...] These are two differnt ports and methods to connect. On port 389 a client initiates a secured session by calling startTLS extended operation. While on port 636 the server requests a secured session. Check your init script, or systemctl service script, whether ldap:/// or ldaps:// is initiated, or both. -Dieter -- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E

7 years, 1 month

Re: Syncrepl question

by Quanah Gibson-Mount

--On Friday, December 05, 2008 1:18 PM -0800 Ivan Ordonez <iordonez(a)nature.berkeley.edu> wrote: > Hi Quanah, > > I was able to get it to work earlier when I add the startls=critical > line. It work when I did it on the slave1, at the time, I made the > slave1 as the master. Thanks so much for that. Now moving on the the > real master, things did not go well. Now the issue is that, any changes > I make on the master, doesn't go to the slaves. I have two slaves and I > want those two to get the changes. > > example: > > Master > | > _ _ _ _ _| |_ _ _ _ _ > | | > | | > | | > Slave1 Slave2 > > Now, when I make any change on the master, the changes will take effect > only on master and not on the slaves. I will get this error on both > slaves. > Is this because of the acl.bdc.readonly.conf line I have on both slave's > slapd.conf file? pdbedit -Lv username still work only on account were no > changes are made. Do you see any errors on the master from the slaves binding? Are you sure they have the right permissions to the master? Did you look at what sync logging shows? What is the contextCSN on your master versus your slaves? At this point, I suggest we take this discussion back to the list, since we got back your earlier config issue (starttls not being set in the syncrepl config). --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

15 years, 11 months

Re: Ldap is up, trying to get tls working.

by John Tobin

Certificates verify. That's a neat tool, put that information somewhere useful. I had been trying to prove that the certificates were good for a long time. I changed from nscd, to nslcd by installing via yast, nss-pam-ldapd That wasn't too bad. I configured nslcd with: Uri ldap://nightmare.dark.net:389/ Base "dc=dark,dc=net" Ssl start_tls Tls_req never Tls_cacertfile /var/lib/ldap/cacert.pem Tls_cert /var/lib/ldap/server.pem Tls_key /var/lib/ldap/server.key Ldapsearch still works .... With -ZZ But su - jtobin Gets the same error message this time from kdeinit: nightmare:/var/log # tail -f messages |grep tls Nov 1 11:48:11 nightmare kdeinit4: nss-ldap: do_open: do_start_tls failed:stat=-1 Nov 1 11:48:11 nightmare kdeinit4: nss-ldap: do_open: do_start_tls failed:stat=-1 I guess I am wondering if I configured something wrong.... Why am I seeing nss-ldap in here... I installed nslcd, configured it, and didn't change any thing in ldap.conf or nsswitch.conf, should anything else be changed? tob nighttrain:~ johntobin$ On 10/28/11 12:08 PM, "Christopher Wood" <christopher_wood(a)pobox.com> wrote: > Cheap advice inline. > > On Fri, Oct 28, 2011 at 11:44:25AM -0400, John Tobin wrote: >> Folks, >> >> I have openldap up, it supports vsftpd, sshd, and 5 client linux machines >> for remote login. >> >> I would like to get tls working. I would support either ldaps [port 636], >> or the tls available on port 389, I am aware of the differences in >> implementation, and the fact that an administrator effectively has to make >> a decision to support one or the other in most cases. >> >> Currently: >> I have slapd running configured for tls under ldap [std port 389]. >> I am testing it on the slapd machine, with a client on the same machine. >> I am pointing to the same cacertificate in slapd.d [cn=config.ldif] and >> ldap.conf. >> >> With that in place, and the ldap.conf below: >> nightmare:/etc # cat ldap.conf >> >> base dc=dark,dc=net >> uri ldap://nightmare.dark.net >> # scope sub >> # binddn "cn=admin,dc=dark,dc=net" >> # bindpw jackie >> bind_policy soft >> # The user ID attribute (defaults to uid) >> pam_login_attribute uid >> pam_lookup_policy yes >> pam_password exop >> nss_schema rfc2307bis >> tls_reqcert never >> pam_filter objectClass=posixAccount >> ldap_version 3 >> nss_map_attribute uniqueMember uniqueMember >> ssl start_tls >> tls_cacert /var/lib/ldap/cacert.pem >> tls_cert /var/lib/server.crt >> tls_key /var/lib/ldap/server.key >> >> I have run ldapsearch: >> nightmare:/media # ldapsearch -v -x -H ldap://nightmare.dark.net:389/ -b >> "dc=dark,dc=net" -Z > > Always test starttls with -ZZ, so if your starttls isn't working the > connection will fail. > >> ldap_initialize( ldap://nightmare.dark.net:389/??base ) >> filter: (objectclass=*) >> requesting: All userApplication attributes >> # extended LDIF >> # >> # LDAPv3 >> # base <dc=dark,dc=net> with scope subtree >> # filter: (objectclass=*) >> # requesting: ALL >> # >> >> # dark.net >> dn: dc=dark,dc=net >> dc: dark >> o: dark >> objectClass: organization >> objectClass: dcObject >> >> # admin, dark.net >> dn: cn=admin,dc=dark,dc=net >> objectClass: organizationalRole >> cn: admin >> >> # Default Policy, dark.net >> dn: cn=Default Policy,dc=dark,dc=net >> objectClass: namedObject >> objectClass: pwdPolicy >> cn: Default Policy >> >> # People, dark.net >> dn: ou=People,dc=dark,dc=net >> objectClass: organizationalUnit >> ou: People >> description: People is used in mapping the /etc/passwd entries >> >> # jtobin, People, dark.net >> dn: uid=jtobin,ou=People,dc=dark,dc=net >> uid: jtobin >> cn: John C. Tobin >> objectClass: account >> objectClass: posixAccount >> objectClass: top >> objectClass: shadowAccount >> loginShell: /bin/ksh >> uidNumber: 5000 >> gidNumber: 100 >> homeDirectory: /home/jtobin >> gecos: John C. Tobin >> >> # defaultDNS, dark.net >> dn: cn=defaultDNS,dc=dark,dc=net >> cn: defaultDNS >> objectClass: top >> objectClass: suseDnsConfiguration >> suseDefaultBase: ou=DNS,dc=dark,dc=net >> >> # DNS, dark.net >> dn: ou=DNS,dc=dark,dc=net >> objectClass: top >> objectClass: organizationalUnit >> ou: DNS >> >> # search result >> search: 3 >> result: 0 Success >> >> # numResponses: 8 >> # numEntries: 7 >> >> nightmare:~ # >> ##### >> >> So I am assuming the ldapserver on ldap://nightmare.dark.net:389/ with tls >> works. >> [I looked through the message output in /var/log/message and see the >> ³STARTTLS² and ³TLS established tls_ssf=256²] >> I have done a number of similar ldapsearches. This appears to work >> correctly. >> >> On the client machine I now do : >> >> nightmare:/media # su - jtobin >> su: user jtobin does not exist >> nightmare:/media # >> >> /var/log/message - output...... >> >> nightmare:/var/log # tail f |grep I tls >> >> Oct 28 11:29:01 nightmare slapd[11118]: conn=1217 op=0 STARTTLS >> Oct 28 11:29:01 nightmare worker_nscd: nss-ldap: do_open: do_start_tls >> failed:stat=-1 >> Oct 28 11:29:01 nightmare slapd[11118]: connection_read(14): TLS accept >> failure error=-1 id=1217, closing >> Oct 28 11:29:01 nightmare slapd[11118]: conn=1217 fd=14 closed (TLS >> negotiation failure) >> Oct 28 11:29:01 nightmare slapd[11118]: conn=1218 op=0 STARTTLS >> Oct 28 11:29:01 nightmare worker_nscd: nss-ldap: do_open: do_start_tls >> failed:stat=-1 > > Augh. If you can stop using nscd all this will be much easier for you. I > personally like nslcd rather than nss-ldap, but each to their own. > > If not, restart nscd before you start every troubleshooting round. > >> Oct 28 11:29:01 nightmare slapd[11118]: connection_read(14): TLS accept >> failure error=-1 id=1218, closing >> Oct 28 11:29:01 nightmare slapd[11118]: conn=1218 fd=14 closed (TLS >> negotiation failure) > > First I would test that all the CA certs and server certs in use are > understandable by each other. Does the server cert on the machine running > slapd validate against the CA cert on the machine running ldapsearch? Does the > server cert on the machine running slapd validate against the CA cert on the > client machine? > > openssl verify -CAfile cacert.pem servercert.pem > > If the output says "ok" then the actual cert part is fine. > > At this point I would crank up the slapd debug level (run it in the > foreground) and match it again your ldap client debug logs. See if you can > reproduce the error above using a client like ldapsearch, using the same > search parameters as the nss-ldap client would use. > >> [if you want more of the log, I can obviously get it, but these appear to >> be the important parts.] >> >> This is probably a configuration error, or a logical / architecture >> misunderstanding, ok, I m a newbie. >> Do I have certificates incorrectly generated? [certificates were generated >> via [1]http://www.openldap.org/faq/data/cache/185.html]. >> What did I do wrong? >> >> This is running openldap 2.4.26 off of Suse 12.1 milestone 5. > > I'm getting a puppetized starttls working with 2.4.26/openssl on debian, but > much the same thing. > >> Thanks in advance. >> tob >> >> References >> >> Visible links >> 1. http://www.openldap.org/faq/data/cache/185.html >

13 years

Re: Error: CSN too old and replication fails

by Howard Chu

Howard Chu wrote: > Jérémy Wagner wrote: >> Hello, >> >> I'm facing some issues with syncrepl... >> >> The simplest situation in which I was able to reproduce the problem >> consists of 1 provider and 1 consumer. >> >> I have configured syncrepl to do a partial replication : >> >> olcSyncrepl: >> {0}rid=105 >> provider=ldaps://****:636 >> bindmethod=simple >> timeout=0 >> network-timeout=0 >> starttls=no >> filter="(mail=*)" >> searchbase="ou=groups,o=mydir" >> scope=sub >> schemachecking=off >> attrs="cn description mail member +" >> type=refreshAndPersist >> retry="60 +" >> tls_cert=**** tls_cacert=**** tls_key=**** >> >> olcSyncrepl: >> {1}rid=107 >> provider=ldaps://****:636 >> bindmethod=simple >> timeout=0 >> network-timeout=0 >> starttls=no >> filter="(objectclass=*)" >> searchbase="ou=operators,o=mydir" >> scope=sub >> schemachecking=off >> type=refreshAndPersist >> retry="60 +" >> tls_cert=**** tls_cacert=**** tls_key=**** >> >> olcSyncrepl: >> {2}rid=104 >> provider=ldaps://****:636 >> bindmethod=simple >> timeout=0 >> network-timeout=0 >> starttls=no >> filter="(uid=mytestuser)" >> searchbase="ou=people,o=mydir" >> scope=sub >> schemachecking=off >> type=refreshAndPersist >> retry="60 +" >> tls_cert=**** tls_cacert=**** tls_key=**** >> >> The initial sync (i.e. from an empty base) is fine, but then when I >> modify an entry (uid=mytestuser), it is not updated on the consumer, and >> I get the >> following messages: >> >> Feb 16 15:42:32 do_syncrep2: rid=107 NEW_COOKIE: >> rid=107,csn=20110216144232.222152Z#000000#000#000000 >> Feb 16 15:42:32 do_syncrep2: rid=104 >> cookie=rid=104,csn=20110216144232.222152Z#000000#000#000000 >> Feb 16 15:42:32 slap_graduate_commit_csn: removing 0x7fb58c0227d0 >> 20110216144232.222152Z#000000#000#000000 >> Feb 16 15:42:32 do_syncrep2: rid=104 CSN too old, ignoring >> 20110216144232.222152Z#000000#000#000000 >> Feb 16 15:43:05 do_syncrep2: rid=105 LDAP_RES_INTERMEDIATE - NEW_COOKIE >> Feb 16 15:43:05 do_syncrep2: rid=105 NEW_COOKIE: >> rid=105,csn=20110216144305.545784Z#000000#000#000000 >> Feb 16 15:43:05 slap_queue_csn: queing 0x7fb58c020b50 >> 20110216144305.545784Z#000000#000#000000 >> Feb 16 15:43:05 do_syncrep2: rid=107 LDAP_RES_INTERMEDIATE - NEW_COOKIE >> Feb 16 15:43:05 do_syncrep2: rid=107 NEW_COOKIE: >> rid=107,csn=20110216144305.545784Z#000000#000#000000 >> Feb 16 15:43:05 do_syncrep2: rid=104 >> cookie=rid=104,csn=20110216144305.545784Z#000000#000#000000 >> Feb 16 15:43:05 slap_graduate_commit_csn: removing 0x7fb58c0227d0 >> 20110216144305.545784Z#000000#000#000000 >> Feb 16 15:43:05 do_syncrep2: rid=104 CSN too old, ignoring >> 20110216144305.545784Z#000000#000#000000 >> >> (both servers are perfectly in sync with an NTP daemon) >> >> It looks like ITS #6619 is quite similar, and unresolved. >> >> What do these messages mean ? Is there a way to force the update ? > > Your current configuration is unsupported. Ordinarily when you configure > multiple consumers in a DB it is assumed they are all pointing at different > providers, and each provider will have a different serverID. In your case, > since it is all a single provider with a single serverID, all 3 consumers will > share a single contextCSN. Any update in any branch will update the contextCSN > to that newest state. Any updates in other branches that hadn't been received > yet (due to random timing between threads) will be received as "too old" > because the contextCSN already has a newer state. > > A workaround for this would be to split each consumer into its own subordinate > database, then each will have a private copy of its own contextCSN to work with. Another potential workaround, if all of the consumer configs were identical except for their baseDN, would be to simply consolidate them all into a single consumer, with a more complex search filter. searchbase=o=mydir filter=(| (&(entryDN:dnSubtreematch:=ou=groups,o=mydir)(mail=*)) (entryDN:dnSubtreematch:=ou=operators,o=mydir) (&(entryDN:dnSubtreematch:=ou=people,o=mydir)(uid=mytestuser))) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

13 years, 9 months

Re: updating from 2.4.20 to 2.4.22 breaks syncrepl/TLS

by Thierry Lacoste

On 20 oct. 10, at 18:04, Buchan Milne wrote: > On Wednesday, 20 October 2010 16:13:44 Thierry Lacoste wrote: >> Hello, >> >> I have 2 CentOS 5.4 servers running OpenLDAP 2.4.20 >> installed from Buchan Milne's repository (openldap2.4- >> servers-2.4.20-1.el5). >> >> The first server is a Sync Provider. >> The second is a consumer with 'starttls=critical'. >> >> I have no problem after 'yum update' of the master >> (openldap2.4-servers-2.4.22-1.el5 is installed and replication is >> OK). >> >> But after 'yum update' of the slave, syncrepl won't work anymore >> because of TLS failures. >> >> Here are the logs on the master : >> Oct 20 16:51:15 vcos-castor slapd2.4[20097]: @(#) $OpenLDAP: slapd >> 2.4.22 (Apr 27 2010 12:04:27) $ >> bgmilne@centos5-32.ranger.dnsalias.com:/home/bgmilne/rpm/BUILD/ >> openldap-2.4.22/servers/slapd >> Oct 20 16:51:15 vcos-castor slapd2.4[20098]: slapd starting >> Oct 20 16:51:46 vcos-castor slapd2.4[20098]: conn=1000 fd=16 ACCEPT >> from IP=IP.OF.THE.SLAVE:46212 (IP=0.0.0.0:389) >> Oct 20 16:51:46 vcos-castor slapd2.4[20098]: conn=1000 op=0 EXT >> oid=1.3.6.1.4.1.1466.20037 >> Oct 20 16:51:46 vcos-castor slapd2.4[20098]: conn=1000 op=0 STARTTLS >> Oct 20 16:51:46 vcos-castor slapd2.4[20098]: conn=1000 op=0 RESULT >> oid= err=0 text= >> Oct 20 16:51:46 vcos-castor slapd2.4[20098]: conn=1000 fd=16 closed >> (TLS negotiation failure) >> >> Here are the logs on the slave : >> Oct 20 16:51:45 vcos-pollux slapd2.4[1808]: @(#) $OpenLDAP: slapd >> 2.4.22 (Apr 27 2010 12:04:27) $ >> bgmilne@centos5-32.ranger.dnsalias.com:/home/bgmilne/rpm/BUILD/ >> openldap-2.4.22/servers/slapd >> Oct 20 16:51:45 vcos-pollux slapd2.4[1809]: slapd starting >> Oct 20 16:51:45 vcos-pollux slapd2.4[1809]: slap_client_connect: >> URI=ldap://NAME_OF_THE_MASTER Error, ldap_start_tls failed (-11) >> Oct 20 16:51:45 vcos-pollux slapd2.4[1809]: do_syncrepl: rid=000 rc >> -11 retrying (4 retries left) >> >> ldapsearch from the slave can do TLS : >> $ ldapsearch -ZZ -x -h NAME_OF_THE_MASTER >> This is ldapsearch from openldap-clients-2.3.43-12.el5_5.2 as >> packaged >> by CentOS >> >> Any ideas on how to troubleshoot the problem? > > Note that the syncrepl statement now has its own tls configuration, > see the > options tls_cert, tls_key, tls_cacert, tls_cacertdir, tls_reqcert, > tls_ciphersuite, tls_crlcheck to the syncrepl statement. > > Regards, > Buchan Thanks a lot. That solved it. I didn't find anything about that in the Release Changes. Regards, Thierry

14 years

openldap-technical search results for query "starttls"