Search results for "starttls" - openldap-technical

Re: TLS: during handshake: Peer certificate is not trusted: kSecTrustResultRecoverableTrustFailure

by Siddharth Jain

is it necessary to specify both TLS_CACERT and TLS_CACERTDIR ? or can the full path to ca cert be specified in TLS_CACERT? what does this mean? 16.2.2.1. TLS_CACERT <filename> This is equivalent to the server's TLSCACertificateFile option. As noted in the TLS Configuration<https://www.openldap.org/doc/admin24/tls.html#TLS%20Configuration> section, a client typically may need to know about more CAs than a server, but otherwise the same considerations apply. 16.2.2.2. TLS_CACERTDIR <path> This is equivalent to the server's TLSCACertificatePath option. The specified directory must be managed with the OpenSSL c_rehash utility as well. If using Mozilla NSS, <path> may contain a cert/key database. ________________________________ From: Howard Chu <hyc(a)symas.com> Sent: Friday, October 2, 2020 10:27 PM To: Siddharth Jain <siddjain(a)live.com>; openldap-technical(a)openldap.org <openldap-technical(a)openldap.org> Subject: Re: TLS: during handshake: Peer certificate is not trusted: kSecTrustResultRecoverableTrustFailure Quanah Gibson-Mount wrote: > > > --On Saturday, October 3, 2020 12:36 AM +0000 Siddharth Jain <siddjain(a)live.com> wrote: > >> >> But ldapsearch throws an error: >> >> >> $ ldapsearch -d 1 -x -H ldaps://ldap.foo.com:636 ... -ZZ > > This is not valid. > > Either you: > > (a) use ldap:// with -ZZ (startTLS) > > OR > > (b) use ldaps:// > > Both will result in a TLS secured connection if successful > > But you absolutely CANNOT combine startTLS + ldaps:// Also, TLS_CERT/TLS_KEY are user-only directives. Re-read the ldap.conf(5) manpage. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

4 years, 1 month

Re: Dovecot can't connect to openldap over starttls

by info＠gwarband.de

Am 2017-03-21 20:36, schrieb Dieter Klünter: > Am Mon, 20 Mar 2017 19:16:49 +0100 > schrieb info(a)gwarband.de: > >>> Am 2017-03-20 16:18, schrieb Dan White: >>>> On 03/20/17 16:06 +0100, info(a)gwarband.de wrote: >>>>> I don't have any idea how to set a higher debug level to dovecot. >>>>> In my opinion I have the highest. So I can't deliver a greater >>>>> log. >>>> >>>> I recommend consulting Dovecot's advice on how to run a debugger, >>>> or dig >>>> into the code which calls libldap. >> >>> There isn't too much to "debug" in Dovecot's TLS implementation, >>> it's not doing anything fancy asides from calling the >>> ldap_start_tls_s. >>> >>> I am not sure what debugging you could try further. >>> >>> Aki >> >> This was the answer of the dovecot mailing list. >> Maybe it would be possible that people from this mailinglist >> communicate directly with the dovecot mailinglist to find the >> soulution together and easier. > > You may test and debug by means of OpenSSL s_client(1). The starttls > and protocol options might provide some insight. > > -Dieter I have found with the dovecot mailinglist the soulution. It was a permission problem because dovecot can't access the *.crt with the rights of a subgroup. Thanks. Tobias

7 years, 7 months

Re: olcTLSVerifyClient: demand not taking effect

by Philip Guenther

On Tue, 13 Mar 2012, Peter Wood wrote: > Also I tried all variations of olcTLSVerifyClient: [demand|hard|true] with > the same result. olcTLSVerifyClient: <level> Specifies what checks to perform on client certificates in an incoming TLS session, if any. <...> Note the "if any" part. That config option says, "If the client negotiates TLS, whether because it's connecting via an ldaps connection or used the StartTLS operation on an ldap connection, then this is the requirements regarding client certificates." If the client connects via ldap (or ldapi) and doesn't use the StartTLS operation, then the olcTLSVerifyClient setting HAS NO EFFECT. If you want the server to reject authentication requests that don't use TLS, then you need to look at the olcSecurity setting. To quote the manpage: olcSecurity: <factors> Specify a set of security strength factors (separated by white space) to require (see olcSaslSecprops's minssf option for a description of security strength factors). The directive may be specified globally and/or per-database. ssf=<n> specifies the overall security strength factor. transport=<n> specifies the transport security strength factor. tls=<n> specifies the TLS security strength factor. sasl=<n> specifies the SASL security strength factor. update_ssf=<n> specifies the overall security strength factor to require for directory updates. update_transport=<n> specifies the transport security strength factor to require for directory updates. update_tls=<n> specifies the TLS security strength factor to require for directory updates. update_sasl=<n> specifies the SASL security strength factor to require for directory updates. simple_bind=<n> specifies the security strength factor required for simple username/password authentication. Note that the transport factor is measure of security provided by the underlying transport, e.g. ldapi:// (and eventually IPSEC). It is not normally used. Philip Guenther

12 years, 8 months

Re: RE24 testing call (2.4.45) LMDB RE0.9 testing call (0.9.20)

by Dieter Kluenter

Quanah Gibson-Mount <quanah(a)symas.com> writes: > This is expected to be the final testing call for 2.4.45, with an > anticipated release, depending on feedback, during the week of > 2017/05/29. > > For this testing call, we particularly need folks to test OpenLDAP > with startTLS/LDAPS when compiled against OpenSSL (both pre 1.1 series > and with the 1.1 series). There is currenly nothing in the test suite > that covers encrypted connections (Although it's on my todo list). To > build against OpenSSL 1.1 may also require cyrus-sasl HEAD out of the > cyrus-sasl GIT repository, depending on your build options as the > current cyrus-sasl release does not support the OpenSSL 1.1 series. > It can be found at <https://github.com/cyrusimap/cyrus-sasl>. If you > build with GSSAPI and use Heimdal, you will also need the Heimdal > 7.1.0 or later release (as that is where OpenSSL 1.1 support was > added). It can be obtained from <http://h5l.org/>. [...] All tests succeeded, source built against openssl-1.0.2j, startTLS. ldaps and sasl EXTERNAL showed no failures. ldapwhoami -Y EXTERNAL -Z -H ldap://localhost:9007 SASL/EXTERNAL authentication started SASL username: cn=Dieter Kluenter,ou=Partner,o=AVCI,c=DE SASL SSF: 0 dn:cn=dieter kluenter,ou=partner,o=avci,c=de ldapwhoami -Y EXTERNAL -H ldaps://localhost:9008 SASL/EXTERNAL authentication started SASL username: cn=Dieter Kluenter,ou=Partner,o=AVCI,c=DE SASL SSF: 0 dn:cn=dieter kluenter,ou=partner,o=avci,c=de -Dieter -- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E

7 years, 5 months

Re: ssf Security Question

by William Brown

On Fri, 2017-11-17 at 08:34 +0100, Michael Ströder wrote: > William Brown wrote: > > Just want to point out there are some security risks with ssf > > settings. > > I have documented these here: > > > > https://fy.blackhats.net.au/blog/html/2016/11/23/the_minssf_trap.ht > > ml > > Nice writeup. I always considered SSF values to be naive and somewhat > overrated. People expect too much when looking at these numbers - > especially regarding the "strength" of cryptographic algorithms which > changes over time anyway with new cryptanalysis results coming up. > > Personally I always try to implement a TLS-is-must policy and prefer > LDAPS (with correct protocol and ciphersuites configured) over > LDAP/StartTLS to avoid this kind of pre-TLS leakage. > Yes, I deliberately ignore "LDAPS is deprecated". ;-] I agree. If only there was a standards working group that could deprecate startTLS in favour of TLS .... :) > > Furthermore some LDAP server implementation (IIRC e.g. MS AD) refuse > to > accept SASL/GSSAPI bind requests sent over TLS-secured channel. Which > is > IMO also somewhat questionable. Yes, I really agree. While a plain text port exists, data leaks are possible. We should really improve this situation, where we have TLS for all data to prevent these mistakes. I think a big part of the issue is that GSSAPI forces the encryption layer, and can't work via an already encrypted channel. The people I know involved in this space are really resistant to changing this due to the "kerberos centric" nature of the products. > > Ciao, Michael. > -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane

6 years, 11 months

Re: Problems with 4-way multi-master

by Mark

Ok, that's embarrassing. I forgot the last couple lines of each of the slapd.confs. Just pretend each of the four ends with the following lines after all the syncrepl rids have been configured: mirrormode TRUE overlay syncprov syncprov-checkpoint 50 10 syncprov-sessionlog 100 On Thu, Mar 31, 2011 at 9:06 PM, Mark <mah042(a)gmail.com> wrote: > I've been testing a 4-way multi-master setup using OpenLDAP 2.4.25 and I'm > having some sporadic problems with it that I'm having difficulty > diagnosing.. > > I have four identical RHEL 4.9 machines on the same switch (NTP syncronized > to same stratum 2 servers): > dual-core Xeon 5110 1.60GHz > 8GB RAM > 100Mb full-duplex NIC > OpenLDAP 2.4.25, BDB 4.8.30, OpenSSL 1.0.0d, Cyrus SASL 2.1.23 (using no > tls/ssl at this time) > > I start the slapds with '-d conns,sync' then commence. I ldapadd 1000 DNs > to one of the servers. After all the syncing has stopped I then compare the > slapd contents against each other looking for differences. Occasionally > there are as much as a couple hundred DNs missing from one or more of the > instances. When that happens I've noticed that the mmaster with less DNs has > lost its consumer connection to a mmaster provider (confirmed using lsof and > netstat) and will never attempt a re-connect, but the provider still shows > the connection (using lsof and netstat). When the consumer gets in this > state I can connect to its cn=config and cn=monitor backends (and browse > them) but when I try to connect to its multi-master'd backend the connection > attempt just hangs. It's almost like the connect succeeds but the client is > waiting for a response from the server (and never gets it). Also, the > consumer slapd will not respond to a 'kill -TERM' at this time and must be > 'kill -KILL'd. The same thing occurs sometimes when I delete the entire > tree. > > I've been trying to catch logging information that might help but so far > nothing's jumping out at me. While I continue to try to reproduce and parse > through logfiles maybe someone can look at my slapd.confs below and see if I > might have configured something wrong (I'm listing the original slapd.conf > files below, but I've used slaptest to convert them to > slapd.d/cn=config.ldif format): > > HOST1 slapd.conf: > > include /tmp/openldap/multi-master/etc/schema/core.schema > include /tmp/openldap/multi-master/etc/schema/cosine.schema > include /tmp/openldap/multi-master/etc/schema/nis.schema > argsfile /tmp/openldap/multi-master/var/run/slapd.args > pidfile /tmp/openldap/multi-master/var/run/slapd.pid > threads 16 > idletimeout 0 > writetimeout 5 > reverse-lookup off > timelimit time.soft=30 time.hard=300 > sizelimit size.soft=500 size.hard=1000 > password-hash {SSHA} > loglevel stats sync > serverid 001 > modulepath /tmp/openldap/multi-master/libexec > moduleload back_monitor.la > moduleload back_hdb.la > moduleload syncprov.la > > database config > rootdn cn=manager,cn=config > rootpw {SSHA}yMFj3Y7KPh223NkkKLQsFeLUVm08Ckpm > > database monitor > rootdn cn=manager,cn=monitor > rootpw {SSHA}vPVSN8o8eRnLdC/bGS7yDwQGeH4BHc0R > > database hdb > suffix dc=example,dc=com > rootdn cn=manager,dc=example,dc=com > rootpw {SSHA}0obbsJw5Yq2XAkdd/kS7vokaB9rrSOtI > directory /tmp/openldap/multi-master/var/data/dc=example,dc=com > cachesize 30000 > cachefree 5 > checkpoint 128 15 > dncachesize 25000 > idlcachesize 100000 > index objectClass eq > index entryCSN eq > index entryUUID eq > > syncrepl rid=001 > provider=ldap://host2:1389 > type=refreshAndPersist > interval=00:00:05:00 > retry="15 +" > searchbase="dc=example,dc=com" > binddn="cn=manager,dc=example,dc=com" > credentials="example_pass" > starttls=no > schemachecking=off > > syncrepl rid=002 > provider=ldap://host3:1389 > type=refreshAndPersist > interval=00:00:05:00 > retry="15 +" > searchbase="dc=example,dc=com" > binddn="cn=manager,dc=example,dc=com" > credentials="example_pass" > starttls=no > schemachecking=off > > syncrepl rid=003 > provider=ldap://host4:1389 > type=refreshAndPersist > interval=00:00:05:00 > retry="15 +" > searchbase="dc=example,dc=com" > binddn="cn=manager,dc=example,dc=com" > credentials="example_pass" > starttls=no > schemachecking=off > > > HOST2 slapd.conf: > > include /tmp/openldap/multi-master/etc/schema/core.schema > include /tmp/openldap/multi-master/etc/schema/cosine.schema > include /tmp/openldap/multi-master/etc/schema/nis.schema > argsfile /tmp/openldap/multi-master/var/run/slapd.args > pidfile /tmp/openldap/multi-master/var/run/slapd.pid > threads 16 > idletimeout 0 > writetimeout 5 > reverse-lookup off > timelimit time.soft=30 time.hard=300 > sizelimit size.soft=500 size.hard=1000 > password-hash {SSHA} > loglevel stats sync > serverid 002 > modulepath /tmp/openldap/multi-master/libexec > moduleload back_monitor.la > moduleload back_hdb.la > moduleload syncprov.la > > database config > rootdn cn=manager,cn=config > rootpw {SSHA}yMFj3Y7KPh223NkkKLQsFeLUVm08Ckpm > > database monitor > rootdn cn=manager,cn=monitor > rootpw {SSHA}vPVSN8o8eRnLdC/bGS7yDwQGeH4BHc0R > > database hdb > suffix dc=example,dc=com > rootdn cn=manager,dc=example,dc=com > rootpw {SSHA}0obbsJw5Yq2XAkdd/kS7vokaB9rrSOtI > directory /tmp/openldap/multi-master/var/data/dc=example,dc=com > cachesize 30000 > cachefree 5 > checkpoint 128 15 > dncachesize 25000 > idlcachesize 100000 > index objectClass eq > index entryCSN eq > index entryUUID eq > > syncrepl rid=001 > provider=ldap://host1:1389 > type=refreshAndPersist > interval=00:00:05:00 > retry="15 +" > searchbase="dc=example,dc=com" > binddn="cn=manager,dc=example,dc=com" > credentials="example_pass" > starttls=no > schemachecking=off > > syncrepl rid=002 > provider=ldap://host3:1389 > type=refreshAndPersist > interval=00:00:05:00 > retry="15 +" > searchbase="dc=example,dc=com" > binddn="cn=manager,dc=example,dc=com" > credentials="example_pass" > starttls=no > schemachecking=off > > syncrepl rid=003 > provider=ldap://host4:1389 > type=refreshAndPersist > interval=00:00:05:00 > retry="15 +" > searchbase="dc=example,dc=com" > binddn="cn=manager,dc=example,dc=com" > credentials="example_pass" > starttls=no > schemachecking=off > > > HOST3 slapd.conf: > > include /tmp/openldap/multi-master/etc/schema/core.schema > include /tmp/openldap/multi-master/etc/schema/cosine.schema > include /tmp/openldap/multi-master/etc/schema/nis.schema > argsfile /tmp/openldap/multi-master/var/run/slapd.args > pidfile /tmp/openldap/multi-master/var/run/slapd.pid > threads 16 > idletimeout 0 > writetimeout 5 > reverse-lookup off > timelimit time.soft=30 time.hard=300 > sizelimit size.soft=500 size.hard=1000 > password-hash {SSHA} > loglevel stats sync > serverid 003 > modulepath /tmp/openldap/multi-master/libexec > moduleload back_monitor.la > moduleload back_hdb.la > moduleload syncprov.la > > database config > rootdn cn=manager,cn=config > rootpw {SSHA}yMFj3Y7KPh223NkkKLQsFeLUVm08Ckpm > > database monitor > rootdn cn=manager,cn=monitor > rootpw {SSHA}vPVSN8o8eRnLdC/bGS7yDwQGeH4BHc0R > > database hdb > suffix dc=example,dc=com > rootdn cn=manager,dc=example,dc=com > rootpw {SSHA}0obbsJw5Yq2XAkdd/kS7vokaB9rrSOtI > directory /tmp/openldap/multi-master/var/data/dc=example,dc=com > cachesize 30000 > cachefree 5 > checkpoint 128 15 > dncachesize 25000 > idlcachesize 100000 > index objectClass eq > index entryCSN eq > index entryUUID eq > > syncrepl rid=001 > provider=ldap://host1:1389 > type=refreshAndPersist > interval=00:00:05:00 > retry="15 +" > searchbase="dc=example,dc=com" > binddn="cn=manager,dc=example,dc=com" > credentials="example_pass" > starttls=no > schemachecking=off > > syncrepl rid=002 > provider=ldap://host2:1389 > type=refreshAndPersist > interval=00:00:05:00 > retry="15 +" > searchbase="dc=example,dc=com" > binddn="cn=manager,dc=example,dc=com" > credentials="example_pass" > starttls=no > schemachecking=off > > syncrepl rid=003 > provider=ldap://host4:1389 > type=refreshAndPersist > interval=00:00:05:00 > retry="15 +" > searchbase="dc=example,dc=com" > binddn="cn=manager,dc=example,dc=com" > credentials="example_pass" > starttls=no > schemachecking=off > > HOST4 slapd.conf: > > include /tmp/openldap/multi-master/etc/schema/core.schema > include /tmp/openldap/multi-master/etc/schema/cosine.schema > include /tmp/openldap/multi-master/etc/schema/nis.schema > argsfile /tmp/openldap/multi-master/var/run/slapd.args > pidfile /tmp/openldap/multi-master/var/run/slapd.pid > threads 16 > idletimeout 0 > writetimeout 5 > reverse-lookup off > timelimit time.soft=30 time.hard=300 > sizelimit size.soft=500 size.hard=1000 > password-hash {SSHA} > loglevel stats sync > serverid 004 > modulepath /tmp/openldap/multi-master/libexec > moduleload back_monitor.la > moduleload back_hdb.la > moduleload syncprov.la > > database config > rootdn cn=manager,cn=config > rootpw {SSHA}yMFj3Y7KPh223NkkKLQsFeLUVm08Ckpm > > database monitor > rootdn cn=manager,cn=monitor > rootpw {SSHA}vPVSN8o8eRnLdC/bGS7yDwQGeH4BHc0R > > database hdb > suffix dc=example,dc=com > rootdn cn=manager,dc=example,dc=com > rootpw {SSHA}0obbsJw5Yq2XAkdd/kS7vokaB9rrSOtI > directory /tmp/openldap/multi-master/var/data/dc=example,dc=com > cachesize 30000 > cachefree 5 > checkpoint 128 15 > dncachesize 25000 > idlcachesize 100000 > index objectClass eq > index entryCSN eq > index entryUUID eq > > syncrepl rid=001 > provider=ldap://host1:1389 > type=refreshAndPersist > interval=00:00:05:00 > retry="15 +" > searchbase="dc=example,dc=com" > binddn="cn=manager,dc=example,dc=com" > credentials="example_pass" > starttls=no > schemachecking=off > > syncrepl rid=002 > provider=ldap://host2:1389 > type=refreshAndPersist > interval=00:00:05:00 > retry="15 +" > searchbase="dc=example,dc=com" > binddn="cn=manager,dc=example,dc=com" > credentials="example_pass" > starttls=no > schemachecking=off > > syncrepl rid=003 > provider=ldap://host3:1389 > type=refreshAndPersist > interval=00:00:05:00 > retry="15 +" > searchbase="dc=example,dc=com" > binddn="cn=manager,dc=example,dc=com" > credentials="example_pass" > starttls=no > schemachecking=off > > > Thank you. > > >

13 years, 7 months

ldap_start_tls: Connect error - self signed certificate in certificate chain

by paul.jc＠yahoo.com

Hello, I have recently upgraded from openldap 2.4.45 to 2.5.53. I are running into one issue when running ldapsearch wth StartTLS locally on the openldap servers. I get the following error whereas I did not prior to upgrade. Any input/suggestions welcome. $ ldapsearch -ZZ -LLL -H ldap://<uri> -x -D "cn=admin, dc=<test.dc,dc=com" -b "dc=test,dc=com" -w ${pw} ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (self signed certificate in certificate chain) Here is the debug: -------------- TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 3, err: 19, subject: /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority, issuer: /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority TLS certificate verification: Error, self signed certificate in certificate chain TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in error TLS trace: SSL_connect:error in error TLS: can't connect: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (self signed certificate in certificate chain). ldap_err2string ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (self signed certificate in certificate chain) -------------- This does not happen with the same ldapsearch done remotely - TLS works just fine with remote ldapsearch queries. Running ldapsearch without StartTLS locally on the server works just fine as well. Prior to this upgrade, we had built openldap with MozNSS (--with-tls=moznss) but now are using the recommended openssl. With our earlier version, running ldapsearch with StartTLS locally on the openldap servers worked without issue. Our certs are not self signed but it appears tls with ldapsearch is seeing the CA cert from our CA as self signed when running locally on the server. Is this even a problem since remote connectivity with TLS works fine? Since we were running moznss prior, I am not sure what the expected behavior is now but it seems that it should work the same as before. A few more details: ------------------ -Servers are CentOS Linux release 7.5 -We are running Openldap version: OpenSSL 1.0.2k-fips 26 Jan 2017 -We are using the same certs (no changes to the certs as part of the upgrade) -Here is partial output from openssl s_client -connect <hostname-here>:636 (same result with openssl s_client -connect <hostname-here>:389 -starttls ldap): This shows return code of 0 (ok): -------------- New, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Verify return code: 0 (ok) -------------- -Ran openssl s_client -verify 3 -connect localhost:636 (and with hostname as well) and openssl s_client -showcerts -connect localhost:636. Both return code 0 (ok): Verify return code: 0 (ok) -Checked the certs: openssl verify -verbose -x509_strict -CAfile ca.crt slapd.crt slapd.crt: OK -Here is our cert config: olcTLSCACertificateFile: /etc/openldap/certs/ca.crt olcTLSCertificateFile: /etc/openldap/certs/slapd.crt olcTLSCertificateKeyFile: /etc/openldap/certs/slapd.key For reference, here is the debug output when running the same ldapsearch command locally on the server on our previous version (2.4.45 with moznss) and the same cert is validated. -------------- TLS: certdb config: configDir='/etc/openldap/certs' tokenDescription='ldap(0)' certPrefix='' keyPrefix='' flags=readOnly TLS: using moznss security dir /etc/openldap/certs prefix . TLS: certificate [CN=*<test-domain-here>,OU=Domain Control Validated] is valid TLS certificate verification: subject: CN=*<test-domain-here>,OU=Domain Control Validated, issuer: CN=Go Daddy Secure Certificate Authority - G2,OU=http://certs.godaddy.com/repository/,O="GoDaddy.com, Inc.",L=Scottsdale,ST=Arizona,C=US, cipher: AES-256-GCM, security level: high, secret key bits: 256, total key bits: 256, cache hits: 0, cache misses: 0, cache not reusable: 0 ldap_sasl_bind -------------- Any suggestions are appreciated. Thanks. Paul

4 years, 1 month

Re: Syncrepl SSL fail

by Rich Megginson

On 10/14/2011 07:10 AM, Hugo Deprez wrote: > Hello, > > On the provider I have the following settings : > > TLSCACertificateFile /etc/ssl/certs/ldap-cert.pem > TLSCertificateFile /etc/ssl/certs/ldap-cert.pem > TLSCertificateKeyFile /etc/ldap/ssl/ldap-key.pem > > but no TLSCipherSuite defined. That should be fine. You don't need to define a TLSCipherSuite > I added the starttls=yes on the consumer : > > Syncrepl rid=003 > provider=ldaps://ldap.mydomain.fr:1024/ > type=refreshOnly > retry="60 10 600 +" > interval=00:00:00:10 > searchbase="dc=mydomain,dc=fr" > scope=sub > schemachecking=on > bindmethod=simple > starttls=yes You should have starttls=critical or it will attempt to fallback to plain LDAP if it cannot establish TLS. > tls_cert=/etc/ssl/certs/ldap-cert.pem You should not have tls_cert here, since you are trying to use dn/password auth. tls_cert is useless without tls_key anyway. > tls_cacert=/etc/ssl/certs/ldap-cert-ca.pem > binddn="cn=syncrepluser,o=others,dc=mydomain,dc=fr" > credentials=my_password > > > But still the same error. > > Any idea ? > > Hugo > On 14 October 2011 13:52, Olivier Guillard<olivier(a)guillard.nom.fr> wrote: >> Hi, >> >> Have you set up the follwing appropriately : >> >> TLSCertificateFile >> TLSCertificateKeyFile >> TLSCipherSuite >> >> On the provider ? >> >> You probably also want to set this up correctly in >> your syncrepl section : >> >> starttls=yes >> tls_cacert=/path/to/certificate >> >> I suspect better if TLS_CACERT is also properly >> set up in both ldap server slapd config. >> >> --- >> Olivier >> >> On Thu, Oct 13, 2011 at 6:38 PM, Hugo Deprez<hugo.deprez(a)gmail.com> wrote: >>> Dear community, >>> >>> I setup a syncrepl between my master openldap server and a consumer. >>> >>> I am trying to use SSL for this syncrepl >>> I got the following error in the log when I start slapd on the consumer : >>> >>> Oct 13 17:04:59 server slapd[16905]: slapd starting >>> Oct 13 17:04:59 server slapd[16905]: slap_client_connect: >>> URI=ldaps://ldap.mydomain.fr:1024/ >>> DN="cn=syncrepluser,o=others,dc=mydomain,dc=fr" ldap_sasl_bind_s >>> failed (-1) >>> Oct 13 17:04:59 server slapd[16905]: do_syncrepl: rid=003 rc -1 >>> retrying (9 retries left) >>> >>> >>> I don't understand why it is failing as a single ldapsearch from the >>> same server with the syncrepl user is working. >>> >>> here is my syncrepl configuration : >>> >>> Syncrepl rid=003 >>> provider=ldaps://ldap.mydomain.fr:1024/ >>> type=refreshOnly >>> retry="60 10 600 +" >>> interval=00:00:00:10 >>> searchbase="dc=mydomain,dc=fr" >>> scope=sub >>> schemachecking=on >>> bindmethod=simple >>> binddn="cn=syncrepluser,o=others,dc=mydomain,dc=fr" >>> credentials=my_password >>> >>> >>> Any idea ? >>> >>> Regards, >>> >>> Hugo >>> >>>

13 years, 1 month

Re: LDAPS Multi-master replication

by Quanah Gibson-Mount

Hello, Please keep replies on the list. --On Tuesday, January 28, 2020 8:06 AM +0000 Клеусов Владимир Сергеевич <Kleusov.Vladimir(a)wildberries.ru> wrote: > Fixed Not sure what you're saying was fixed. There was not really any errors discussed in your prior email, simply a note that the replication you were configurating would only replicate the cn=config database. Your modification appears to keep that behavior. > dn: olcDatabase={0}config,cn=config > changetype: modify > replace: olcSyncRepl > olcSyncRepl: rid=001 provider=ldaps://infra-ldap-m9.wb.ru > searchbase="cn=config" bindmethod=simple credentials=5fX?BLR2 > binddn="cn=admin,cn=config" starttls=no > tls_cert="/etc/ldap/sasl2/wb.ru.crt" tls_key="/etc/ldap/sasl2/wb.ru.key" > tls_cacert="/etc/ldap/sasl2/commercial_ca.crt" tls_reqcert=allow > type=refreshAndPersist retry="5 5 300 5" timeout=1 > olcSyncRepl: rid=002 provider=ldaps://infra-ldap.dl.wb.ru > searchbase="cn=config" bindmethod=simple credentials=5fX?BLR2 > binddn="cn=admin,cn=config" credentials=5fX?BLR2 starttls=no > tls_cert="/etc/ldap/sasl2/w.ru.crt" tls_key="/etc/ldap/sasl2/wb.ru.key" > tls_cacert="/etc/ldap/sasl2/commercial_ca.crt" tls_reqcert=allow > type=refreshAndPersist retry="5 5 300 5" timeout=1 > olcSyncRepl: rid=003 provider=ldaps://infra-ldap.dp.wb.ru > searchbase="cn=config" bindmethod=simple credentials=5fX?BLR2 > binddn="cn=admin,cn=config" starttls=no > tls_cert="/etc/ldap/sasl2/wb.ru.crt" > tls_key="/etc/ldap/sasl2/wb.ru.key"tls_cacert="/etc/ldap/sasl2/commercial > _ca.crt" tls_reqcert=allow type=refreshAndPersist retry="5 5 300 5" > timeout=1 Your above configuration seems very odd. You are not doing client cert authentication via SASL EXTERNAL, and yet you've specified a client cert and key. I would expect the only TLS configuration bits to be for the CA cert. > But in logs on each server > slap_client_connect: URI=ldaps://infra-ldap.dl.wb.ru > DN="cn=admin,cn=config" ldap_sasl_bind_s failed So it's not able to bind with the configuration to the other server. > openssl s_client -connect infra-ldap.dp.wb.ru:636 > Verify return code: 0 (ok) > Do I need to specify port 636 in steps 5 and 7 ? For example, it was > ldaps:/ / infra-ldap-m9.wb. ru and will become ldaps://infra-ldap-m9.wb. > ru:636 No, port 636 is the default for ldaps. > And how else can you figure out what's wrong ? I would use the ldapwhoami utility to ensure you can bind with the specified identity to each server. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

4 years, 9 months

mdb grows to olcDbMaxsize if searched before syncrepl completes.

by Jancewicz, Russell

I am experiencing strange behavior when running an mdb database, as compared to the same system configured with hdb. If I conduct any queries while the server is receiving its initial data the server via syncrepl it stops receiving new entries and the data.mdb file balloons to the olcDbMaxsize value. I have tried adjusting configuration settings but regardless this continues to occur is this to be expected with mdb? It should be noted that if I wait for the entire database to replicate I can query the database fine and the size of data.mdb does not change. Furthermore if new changes are propagated down to the replica the issue does not arise. Any help would be appreciated. Please find below configuration ldifs and version information. -Russell J. Jancewicz University of Connecticut Version: @(#) $OpenLDAP: slapd 2.4.35 (Jun 17 2013 12:21:32) $ My olcDatabaseConfig: # {1}mdb, config dn: olcDatabase={1}mdb,cn=config changetype: add objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: mdb olcDbDirectory: /srv/ldap/example.com olcSuffix: dc=example,dc=com olcRootDN: dc=example,dc=com olcRootPW: secret olcDbMaxsize: 4294967296 olcDbNoSync: FALSE olcReadOnly: TRUE olcDbCheckpoint: 512 30 olcDbIndex: default pres,eq olcAccess: to * by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * break olcAccess: to * by * none olcSyncrepl: rid=101 provider=ldap://replica0.ldap.example.com starttls=critical bindmethod=simple binddn="dc=example,dc=com" credentials=secret searchbase="dc=example,dc=com" type=refreshAndPersist retry="5 5 300 +" olcSyncrepl: rid=102 provider=ldap://replica1.ldap.example.com starttls=critical bindmethod=simple binddn="dc=example,dc=com" credentials=secret searchbase="dc=example,dc=com" type=refreshAndPersist retry="5 5 300 +" # {1}memberof, {1}hdb, config dn: olcOverlay={0}memberof,olcDatabase={1}mdb,cn=config objectClass: top objectClass: olcOverlayConfig objectClass: olcMemberOf olcOverlay: {0}memberof

11 years, 4 months

openldap-technical search results for query "starttls"