Search results for "starttls" - openldap-technical

Re: Syncrepl SSL fail

by Hugo Deprez

Hello, after reading : https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=734187 It seems that when the consumer provide ldaps service, I must specify tls_key and tls_cert parameter with the provider files. If not specified, syncrepl will use consumer certificat and they will never match the provider cert. This is why I got the error : slapd[31043]: do_syncrepl: rid=003 rc -1 retrying (9 retries left) the private key didn't match with the provider. So in this setup, cert and private key from provider must be deployed on each consumer. Regards, Hugo On 6 December 2011 12:04, Hugo Deprez <hugo.deprez(a)gmail.com> wrote: > Hello, > > if I don't sepcify the key path I get the following error when starting slpad : > > slap_client_connect: URI=ldaps://ldap.domain.fr:1024/ TLS context > initialization failed (-1) > slapd[31043]: do_syncrepl: rid=003 rc -1 retrying (9 retries left) > > So I need the tls_key=/etc/ldap/ssl/ldap-key.pem pointing to the key > of the provider. > > Any idea why I should specify the private key of the provider ? > > Regards, > > On 2 December 2011 15:11, Raffael Sahli <public(a)raffaelsahli.com> wrote: >> On 12/02/2011 02:50 PM, Hugo Deprez wrote: >>> >>> Hello Philip, >>> >>> thank you for your explanation. >>> >>> This is more clear now. >>> >>> So I changed my configuration like : >>> >>> Syncrepl rid=003 >>> provider=ldaps://my.server:1024/ >>> type=refreshOnly >>> retry="60 10 600 +" >>> interval=00:00:00:10 >>> searchbase="dc=my,dc=domain" >>> scope=sub >>> schemachecking=on >>> bindmethod=simple >>> tls_reqcert=demand >>> tls_cert=/etc/ssl/certs/ldap-cert.pem >>> tls_cacert=/etc/ssl/certs/ldap-cert.pem >>> tls_key=/etc/ldap/ssl/ldap-key.pem >>> binddn="cn=syncrepluser..." >>> credentials=******** >>> >>> I added the tls_key, tls_cacert, tls_reqcert parameter. >>> The tls option are using the certificate and the key of the LDAP Provider. >>> >>> The last thing I don't understand is that the tls_key is needed. So I >>> need to deploy the private key of the provider to each consumer. >>> >>> I though the certificate would be sufficient ? >> >> >> No you don't have to deploy the private key! >> In syncrepl, just define the tls_cacert, and it works. >> >> >> >>> >>> Regards, >>> >>> >>> >>> >>> >>> On 18 October 2011 06:28, Philip Guenther >>> <guenther+ldaptech(a)sendmail.com> wrote: >>>> >>>> On Sun, 16 Oct 2011, Hugo Deprez wrote: >>>>> >>>>> It seems that the proper configuration for my case is : >>>>> >>>>> 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 >>>>> tls_reqcert=never >>>>> binddn="cn=syncrepluser,o=others,dc=mydomain,dc=fr" >>>>> credentials=my_password >>>>> >>>>> It works, but I am confuse with those parameters. If I understand >>>>> well, I will never use TLS here, but only ssl ? >>>>> Hence, it was a TLS issue ? >>>> >>>> No, you're using TLS. You're just not using the StartTLS operation. >>>> >>>> There are two ways to use SSL/TLS: "negotiate-on-connect" and "upgrade >>>> from clear". The former is what you get when you use an ldaps:// URL, >>>> where the first data the client sends is the raw SSL/TLS ClientHello >>>> packet. The latter is what you get when you use an ldap:// URL and have >>>> starttls=yes or starttls=critical, where the first data the client sends >>>> is LDAP protocol data in the clear, including a StartTLS request. If the >>>> server sends a success response to that StartTLS request, then the client >>>> starts the SSL/TLS handshake with its ClientHello packet. >>>> >>>> This should answer why it failed when you tried to combine an ldaps:// >>>> URL >>>> with starttls=yes: the exchange was already using SSL/TLS and (rightly) >>>> libldap won't let you negotiate multiple levels of SSL/TLS encryption. >>>> >>>> (You may note that I write "SSL/TLS". That's because they're just >>>> different versions of the same protocol. Using 'SSL' as a shorthand for >>>> "negotiate on connect" and 'TLS' for "upgrade from clear" is poor naming, >>>> as the choice of method is orthogonal to the protocol version. Your >>>> ldaps:// connection is probably negotiating the TLS 1.0 protocol (aka SSL >>>> version 3.1), just as an ldap:// connection using StartTLS may, on a >>>> poorly configured server, negotiate SSL 3.0) >>>> >>>> >>>> Next: the fact that you need tls_reqcert=never for TLS negotiation to >>>> succeed strongly suggests the problem is either >>>> a) the subject and subjectAltName of the cert don't match the hostname in >>>> the URL, OR >>>> b) the client doesn't have the self-signed CA cert at the root of the >>>> signing chain for the server's cert. >>>> >>>> Those are both necessary to protect the server against Man-in-the-Middle >>>> attacks. >>>> >>>> (It used to be that tls_reqcert=allow would disable check (b) and only >>>> perform check (a), or at least that was the case when using the OpenSSL >>>> crypto backend, but that behavior has apparently been removed from the >>>> version in git as of August. Given the vagaries of the error reporting >>>> of >>>> the underlying crypto libraries, this was a useful tool in tracking down >>>> which check was causing TLS failures. Oh well.) >>>> >>>> So, does the server's certificate subject or subjectAltName match the >>>> hostname from the URL the client is using? Have you verified that the CA >>>> at the root of the server's cert's chain really is configured for the >>>> client? >>>> >>>> >>>> Philip Guenther >> >> >> >> -- >> Raffael Sahli >> public(a)raffaelsahli.com >> Switzerland >>

13 years, 6 months

Re: Security between server and client nodes.

by Jayavant Patil

>Mon, 28 Nov 2011 11:25:16 +0100 Raffael Sahli <public(a)raffaelsahli.com> wrote: >Hi >I think you mean SSL connection or the STARTTLS Layer...? >Please read the manual http://www.openldap.org/doc/admin24/tls.html Ok. >And tree security: >On my server, a client user can only see his own object: Are you using simple authentication mechanism? >Maybe create a rule like this: >access to filter=(objectClass= >simpleSecurityObject) > by self read > by * none I am not getting what the ACL rule specifies. Any suggestions? -- Thanks & Regards, Jayavant Ningoji Patil Engineer: System Software Computational Research Laboratories Ltd. Pune-411 004. Maharashtra, India. +91 9923536030.

13 years, 6 months

Re: Trying to understand an error message

by Khaled Blah

I see. I will have to look at it more closley. Thanks for your reply, Hallvard! Regards, Khaled 2010/11/12 Hallvard B Furuseth <h.b.furuseth(a)usit.uio.no>: > Khaled Blah writes: >> Thanks for your reply, Hallvard. Do I understand it correctly that I >> can re-use LDAP structures on which a bind has already been done? > > Yes, a Bind on an LDAP* remains in force until the next Bind, possibly > StartTLS (I don't remember) or Unbind. > >> Do you know of any other stateful data I would have to look at? > > The assertion implies a broken data structure, so my guess is you either > reused the LDAP* after Unbind, or you have some data corruption in your > program. > > -- > Hallvard >

14 years, 6 months

Re: ldapi and StartTLS

by Norman Gray

Michael and Richard, hello. On 16 Jul 2018, at 5:09, Richard Gray wrote: > Have a look at 'olcLocalSSF' in slapd-config(5), which lets you set > the security strength factor for local (i.e. ldapi://) sessions. It > defaults to 71, which is likely why you're seeing that error message. > Personally, I bump it up to 256, to match the ssf=256 I have set in > the olcSecurity attribute on cn=config. Many thanks for this advice -- it works perfectly. I've set olcLocalSSF to 256. Hmm: 71 is an oddly-chosen default. Is there a story there, I wonder? (Apologies, also, for taking so long to respond: this project had swapped right out of my head, and it was only a couple of days ago that it was able to page back in). Best wishes, Norman -- Norman Gray : https://nxg.me.uk

6 years, 10 months

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

by Michael Wandel

On 28.09.2017 21:41, Robert Heller wrote: > Will these spit out useful error messages? If I just get "TLS Negotiation > failure" it is not going to be helpful. > You can make it a little bit more verbose with the option "-d -1" It is only a suggestion, but can you test the parameter TLS_REQCERT allow in your /etc/openldap/ldap.conf This ist not a good option for production systems, but it seems you come in trouble with your certificates. You have to set your TLS_CACERT xor TLS_CACERTDIR correctly in your /etc/openldap/slapd.conf to work stressless with your ssl/tls. best regards Michael > At Thu, 28 Sep 2017 12:29:19 -0700 Quanah Gibson-Mount <quanah(a)symas.com> wrote: > >> >> --On Thursday, September 28, 2017 3:34 PM -0400 Robert Heller >> <heller(a)deepsoft.com> wrote: >> >> >>> Slapd is reporting TLS Negotiation failure when SSSD tries to connect to >>> it. For both port 389 (ldap:///) and 636 (ldaps:///). So I guess >>> something is wrong with slapd's TLS configuration -- it is failing to do >>> TLS Negotiation, either it is just not doing it or it is doing it wrong >>> (somehow). Unless SSSD is not configured properly. >> >> You need to start with the following: >> >>>> ldapwhoami -x -ZZ -H ldap://myhost:389 -D binddn -w >> >> to test startTLS >> >> and >> >> ldapwhoami -x -H ldaps://myhost:636 -D binddn -w >> >> to test without startTLS >> >> If you can get those to work, then you can move on to SSSD. >> >> --Quanah >> >> -- >> >> Quanah Gibson-Mount >> Product Architect >> Symas Corporation >> Packaged, certified, and supported LDAP solutions powered by OpenLDAP: >> <http://www.symas.com> >> >> > -- Michael Wandel Braakstraße 43 33647 Bielefeld

7 years, 8 months

Re: How do tool verify certs with ldapi:// ?

by Peter Marschall

Hi, On Monday, 28. May 2012, Philip Guenther wrote: > ...which then remaps that to the local hostname (if available) for the > actual check. > > Huh. So for any URI that doesn't specify a host component, be it > "ldapi://" or "ldap://" or "ldaps://", the OpenLDAP tools will connect to > the default 'host' for the schema, be it "/var/run/ldpai" or "localhost", > but for StartTLS they'll match the server cert against the *hostname*. > > I did not expect that, though I can see how it can be justified. Sounds like a/the "clever trick" I was looking for. Now that I knew for what I was looking ,I was able to find it in ibraries/libldap/tls_{o,g,m}.c Thanks a lot Peter -- Peter Marschall peter(a)adpm.de

13 years

RE: openldap and MozNSS

by Quanah Gibson-Mount

--On Tuesday, June 25, 2013 11:40 AM -0400 Rodney Simioni <rodney.simioni(a)verio.net> wrote: > I'm getting further, I went to http://ltb-project.org and downloaded a > newer version of openldap. BTW, thank you, it's a nice site. > > But when I do a 'ldapsearch -d -1 -x -LLL -ZZ', I'm getting " unsupported > extended operation" > > Does anybody have a clue? I would advise you to specifically use -H <URI> so it is clear what you are connecting to and how. For example, -ZZ requests startTLS, but if you are using an ldaps:// URI, that makes no sense, because they are mutually exclusive. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

11 years, 11 months

Re: TLS Connectivity

by Quanah Gibson-Mount

--On Wednesday, October 9, 2019 3:23 PM +0000 Howard.Gillison(a)gvltec.edu wrote: > > > Good morning to you, I suggest you read the OpenLDAP client code and the libldap code which fully utilizes the API to make connections with or without TLS. I think the *function* you're looking for is ldap_start_tls_s (at least for startTLS over port 389): <https://www.openldap.org/software/man.cgi?query=ldap_start_tls_s&apropos=0&…> >From the library, I would suggest perusing libldap/init.c, libldap/open.c, libldap/options.c, and libldap/unbind.c Since this is open source software it is of course trivial to access the code and have working examples before you. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

5 years, 8 months

Re: ldaprc with ldaps:// and ldap:// fallback

by Dan White

On 24/06/10 11:57 +0200, Emmanuel Dreyfus wrote: >Dieter Kluenter <dieter(a)dkluenter.de> wrote: > >> No, ldapi:/// doesn't present a certificate, but you may establish a >> startTLS session to ldapi:///, in this case the client requests a >> server certificate. > >Let me rephrase: I would like to specify two LDAP servers in ldaprc >- one ldapi:/// with anonymous bind >- one ldaps:// with SASL EXTERNAL for and required server certificate > >It seems to me it is not possible. You could do SASL EXTERNAL over both, with ldapi:/// using Unix peercred, i.e.: authz-regexp ".*uidNumber=([^,]+),cn=peercred,cn=external,cn=auth" ldap:///ou=People,dc=example,dc=net??one?(uidNumber=$1) -- Dan White

14 years, 11 months

Re: seg fault with TLS syncrepl ?

by Rich Megginson

On 08/12/2011 07:17 AM, Olivier wrote: > My N-WAY replication works properly with a > "bindmethod=simple". > > However, I don't like keeping a password in clear in > a configuration file, then I tryed this : > > On server "ldap-master1.example.fr" : > > TLSVerifyClient allow > > syncrepl rid=101 > provider=ldap://ldap-master2.example.fr:389 > searchbase="dc=example,dc=fr" > schemachecking=on > type=refreshOnly > interval=00:00:01:00 > retry="10 +" > bindmethod=sasl > saslmech=EXTERNAL > starttls=critical > tls_cert=/etc/openldap/cacerts/master1/server.crt > tls_key=/etc/openldap/cacerts/master1/server.key > tls_cacert=/etc/openldap/cacerts/CA.crt > tls_reqcert=demand > > On server "ldap-master2.example.fr" : > > TLSVerifyClient allow > > syncrepl rid=201 > provider=ldap://ldap-master1.example.fr:389 > searchbase="dc=example,dc=fr" > schemachecking=on > type=refreshOnly > interval=00:00:01:00 > retry="10 +" > bindmethod=sasl > saslmech=EXTERNAL > starttls=critical > tls_cert=/etc/openldap/cacerts/master2/server.crt > tls_key=/etc/openldap/cacerts/master2/server.key > tls_cacert=/etc/openldap/cacerts/CA.crt > > I get a segmentation fault : > > ldap-master1 #$ /usr/sbin/slapd -h ldap:/// -u ldap -d256 > > @(#) $OpenLDAP: slapd 2.4.23 (Apr 12 2011 19:26:36) $ > mockbuild@x86-001.build.bos.redhat.com:/builddir/build/BUILD/openldap-2.4.23/openldap-2.4.23/build-servers/servers/slapd > bdb_monitor_db_open: monitoring disabled; configure monitor database to enable > <= bdb_inequality_candidates: (entryCSN) not indexed > slapd starting > slap_client_connect: URI=ldap://ldap-master2.example.fr:389 Error, > ldap_start_tls failed (-1) > do_syncrepl: rid=101 rc -1 retrying > conn=1000 fd=12 ACCEPT from IP=10.1.92.25:47353 (IP=0.0.0.0:389) > conn=1000 op=0 EXT oid=1.3.6.1.4.1.1466.20037 > conn=1000 op=0 STARTTLS > conn=1000 op=0 RESULT oid= err=0 text= > conn=1000 fd=12 TLS established tls_ssf=256 ssf=256 > conn=1000 op=1 BIND dn="" method=163 > conn=1000 op=1 BIND > authcid="email=max(a)example.fr,cn=ldap-master2.example.fr,ou=ldap,o=example,l=somewhere,st=france,c=fr" > authzid="email=max(a)example.fr,cn=ldap-master2.example.fr,ou=ldap,o=example,l=somewhere,st=france,c=fr" > conn=1000 op=1 BIND > dn="email=max(a)example.fr,cn=ldap-master2.example.fr,ou=ldap,o=example,l=somewhere,st=france,c=fr" > mech=EXTERNAL sasl_ssf=0 ssf=256 > conn=1000 op=1 RESULT tag=97 err=0 text= > conn=1000 op=2 SRCH base="dc=example,dc=fr" scope=2 deref=0 > filter="(objectClass=*)" > conn=1000 op=2 SRCH attr=* + > conn=1000 op=2 SEARCH RESULT tag=101 err=0 nentries=0 text= > conn=1000 op=3 UNBIND > conn=1000 fd=12 closed > Erreur de segmentation > > The segfault happened when the second server tried to sync with the first one : > > [root@ldap-master2 cacerts]# /usr/sbin/slapd -h ldap:/// -u ldap -d256 > @(#) $OpenLDAP: slapd 2.4.23 (Apr 12 2011 19:26:36) $ > mockbuild@x86-001.build.bos.redhat.com:/builddir/build/BUILD/openldap-2.4.23/openldap-2.4.23/build-servers/servers/slapd > bdb_monitor_db_open: monitoring disabled; configure monitor database to enable > slapd starting > conn=1000 fd=12 ACCEPT from IP=10.1.92.24:55208 (IP=0.0.0.0:389) > conn=1000 op=0 EXT oid=1.3.6.1.4.1.1466.20037 > conn=1000 op=0 STARTTLS > conn=1000 op=0 RESULT oid= err=0 text= > TLS: error: accept - force handshake failure: errno 2 - moznss error -5938 > TLS: can't accept: TLS error -5938:Encountered end of file. > conn=1000 fd=12 closed (TLS negotiation failure) > ^C > daemon: shutdown requested and initiated. > slapd shutdown: waiting for 0 operations/tasks to finish > slapd stopped. > > Any idea ? Can you get a core file and a stack trace from the server that gets the seg fault? I'm assuming from the build that you are running on Fedora 14 or later, or RHEL6.1. You should make sure the openldap-debuginfo package is installed (e.g. debuginfo-install openldap) and install abrt. This will collect the core files in /var/spool/abrt > NOTE : if I start the daemon on ldap-master2, that's ldap-master2 that > produce the seg fault. > > --- > Olivier >

13 years, 10 months

openldap-technical search results for query "starttls"