Search results for "starttls" - openldap-technical

RE: SSL/TLS connection on port 389

by Carr, Chris

> > I've been running slapd with "-h ldaps:///" so that it > > takes SSL/TLS connections on port 636. This has worked > > with most clients (Outlook, Seamonkey, Thunderbird) > > but does not work for Evolution. I don't know why not, > > but Evolution seems to insist on using port 389 for > > secure connections. > > Which version of Evolution? I'm currently using 2.6.3 (Debian Etch), 2.8.2 (the Windoze port) and 2.12.3 (Debian Lenny), and have also tried 2.10.3 and 2.12.2 in between. The LDAP connection functionality seems unchanged in all these versions. > Mine has a "Use secure connection" drop-down box, with > "SSL encryption", "TLS encryption" and "No encryption" > options. Since the port doesn't change based on your > selection, I'll assume what they actually mean is > "ldaps", "STARTTLS", and "No encryption". Naturally, > STARTTLS would run on the normal unencrypted port (389 > by default), and "upgrade" to SSL/TLS with a STARTTLS > command. I have the same, and I had (belatedly) come to the same assumption. > It seems that no matter what you select here, if the port is > 389, it does STARTTLS: > > Jan 29 17:59:16 seaknight slapd[840]: conn=0 fd=15 ACCEPT from > IP=127.0.0.1:53243 (IP=0.0.0.0:389) > Jan 29 17:59:16 seaknight slapd[840]: conn=0 op=0 STARTTLS > Jan 29 17:59:16 seaknight slapd[840]: conn=0 op=0 RESULT oid= > err=0 text= Jan 29 17:59:16 seaknight slapd[840]: conn=0 > fd=15 TLS established tls_ssf=256 ssf=256 This is encouraging - I guess you are not using the same version of slapd as I am? (I'm using 2.4.7, which apparently has a bug with STARTTLS, at least in Debian it does). What log level are you choosing to get this output? Is it just "conns"? > However, if you select 636 as the port, it greys out the "Use secure > connection" drop-down box, and does ldaps. Yes. > Jan 29 18:03:51 seaknight slapd[840]: conn=14 fd=27 ACCEPT from > IP=127.0.0.1:54153 (IP=0.0.0.0:636) > Jan 29 18:03:51 seaknight slapd[840]: conn=14 fd=27 closed > (TLS negotiation > failure) > Jan 29 18:03:58 seaknight slapd[840]: conn=15 fd=27 ACCEPT from > IP=127.0.0.1:45074 (IP=0.0.0.0:389) > > (Can't get it to work right right now with ldaps ...). Me neither, though I had assumed that was password-related. > Note however that evo caches LDAP connections, it seems you > need to restart it for your config changes to take effect. Ah, I didn't know that - thanks. > And, it will only prompt you for the password once the > connection is up ... Hmmm. If I understand the output correctly, it's rejecting the connection before asking for a password. I will have to investigate this again. > > Could somebody explain to me how to tell slapd to accept secure > > connections on port 389? > > start slapd with with no -h flag, or -h "ldaps:/// ldap:///" > so it listens on port 636 for ldaps connections, and 389 for > ldap connections (which could use START_TLS to upgrade). I just have -h "ldaps:///" - I presumed the ldap:/// was covered automatically as the default. > > Sorry if this is a really stupid question, but according to > > the docs the "startTLS" process should be automatic if a > > secure connection comes in on port 389. Something is > > obviously not quite right. > > Hmm, SSL/TLS isn't really automatic ... Sorry, I meant that the connection is upgraded to SSL/TLS if the STARTTLS command is sent by the client (which you have verified Evolution does). Thanks muchly for your help. I will do some more testing with Evolution until I lose the will to live once again. I am now even getting errors with Outlook. It seems to connect ok, but whenever I do a search it says "The Properties dialog box could not be displayed. To display the Properties dialog box, you must select exactly one item." - I don't know what this is about, I get the same message whether my search is gibberish (should return no matches), unique (should return a single match) or general (should return multiple matches). No results are returned. It seems to be a completely incorrect error message. CC This e-mail may contain information which is confidential, legally privileged and/or copyright protected. This e-mail is intended for the addressee only. If you receive this in error, please contact the sender and delete the material from your computer

17 years, 4 months

Re: Ubuntu Server 12.04: StartTLS

by Dan White

On 11/04/12 23:13 +0100, admus wrote: >Hello, >I'm following https://help.ubuntu.com/12.04/serverguide/openldap-server.html#openldap-tls… how to: >LDAP serwer starts correctly but when I tries to test StartTLS: >ldapsearch -x -H ldap:/// -ZZ -d -1 >I gets the following error: >TLS: peer cert untrusted or revoked (0x42) >TLS: can't connect: (unknown error code). >ldap_err2string >ldap_start_tls: Connect error (-11) > additional info: (unknown error code) >Any idea? Your hostname will need to match the certificate you have installed. '-H ldap:///' will, instead, need to include the hostname matching your certificate. For project documentation, see chapter 16 of the OpenLDAP Administrator's Guide, slapd-config(5), ldap.conf(5), and ldapsearch(1). -- Dan White

12 years, 7 months

Re: TLS certs needed for Provider and consumer

by Dieter Kluenter

Am Tue, 1 Jun 2010 14:33:28 -0400 schrieb "Sotomayor, Vicente (ITD)" <Vicente.Sotomayor(a)state.ma.us>: > Hello Everyone: > > Does anyone a have a link the shows what steps are needed to for > creating certs for a Provider and Consumer? I've been able to do it > for Provider, but I'm stuck on what to do for the consumer. What do you want to achieve? Is it just a TLS session or in addition a SASL EXTERNAL authentication? A startTLS session requires olcSyncrepl: starttls=yes tls_cacert=/path/to/CA, you may add tls_reqcert=demand. A SASL EXTERNAL authentication in addition requires a user certificate and a certificate key. -Dieter -- Dieter Klünter | Systemberatung sip: +49.40.20932173 http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6

15 years

Re: Migrate from hdb/bdb to mdb backend.

by Quanah Gibson-Mount

--On Thursday, March 22, 2018 3:12 PM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > olcSyncrepl: {0}rid=1 provider=ldap://ldapservertest01:10389/ > binddn="cn=manager,dc=example,dc=com" bindmethod=simple > credentials=dontshare searchbase="dc=example,dc=com" attrs="*,+" > type=refreshAndPersist retry="5 +" timeout=0 keepalive=5:5:5 > network-timeout=0 starttls=no filter="(objectclass=*)" scope=sub > schemachecking=off > olcSyncrepl: {1}rid=2 provider=ldap://ldapservertest02:10389/ > binddn="cn=manager,dc=example,dc=com" bindmethod=simple > credentials=dontshare searchbase="dc=example,dc=com" attrs="*,+" > type=refreshAndPersist retry="5 +" timeout=0 keepalive=5:5:5 > network-timeout=0 starttls=no filter="(objectclass=*)" scope=sub > schemachecking=off > olcSyncrepl: {2}rid=3 provider=ldap://ldapservertest03:10389/ > binddn="cn=manager,dc=example,dc=com" bindmethod=simple > credentials=dontshare searchbase="dc=example,dc=com" attrs="*,+" > type=refreshAndPersist retry="5 +" timeout=0 keepalive=5:5:5 > network-timeout=0 starttls=no filter="(objectclass=*)" scope=sub > schemachecking=off > olcSyncrepl: {3}rid=4 provider=ldap://ldapservertest04:10389/ > binddn="cn=manager,dc=example,dc=com" bindmethod=simple > credentials=dontshare searchbase="dc=example,dc=com" attrs="*,+" > type=refreshAndPersist retry="5 +" timeout=0 keepalive=5:5:5 > network-timeout=0 starttls=no filter="(objectclass=*)" scope=sub > schemachecking=off Remove the pointer back to itself on each server, so they stop trying to replicate from themselves, or use a URL with the serverID. Also, what version of OpenLDAP are you using? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

7 years, 2 months

Problems with ppolicy_forward_updates and starttls with certificate-based auth

by Kartik Subbarao

I'm trying to get a consumer server to forward ppolicy-related updates to its provider server, and to use certificate-based authentication (SASL EXTERNAL) over STARTTLS when authenticating to the provider. This is with 2.4.23 on a Debian 5.0.5 system (I've seen similar issues reported elsewhere so I doubt this is platform specific). I'm running into multiple problems here. The core problem seems to be that enabling ppolicy_forward_updates breaks the chaining overlay such that it binds anonymously instead of with SASL EXTERNAL. Another problem is that bind operations to the consumer server start to return two result messages -- one with the error code of the chained operation, and one with the error code of the bind operation. This latter problem seems to the cause of the (still unresolved?) errors from this message thread earlier this year: http://www.mail-archive.com/openldap-technical@openldap.org/msg01215.html To simplify reproducing the problem, I've worked with test022-ppolicy in the openldap test framework. I've submitted ITS 6711 based on this. Here, I ran into another issue. I can't seem to be able to configure sasl external/starttls chaining properly with the cn=config style configuration that test022-ppolicy applies. The self-signed cert that I'm using works fine with replication, but it doesn't seem to work with chaining. This may or may not be another issue that needs to be resolved. In any case, with the attached files in the ITS, I hope that what I'm trying to do and the results that I'm getting should be as clear and unambiguous as possible. I'd appreciate any feedback on whether there is something else I need to configure or if there are bugs here that need to be fixed. Thanks, -Kartik

14 years, 6 months

Re: About TLS - ldaps search

by Quanah Gibson-Mount

--On Friday, January 04, 2013 4:45 PM -0800 Bheeshma SM <bheeshma.manjunath(a)gmail.com> wrote: > > Is there a specific way, i have to configure the slapd to listem to 636 > port..? > > And does the 389 search is a secure search...? > > Is there a particular way of Starting the TLS operation..? > > Thanks in advance > As I already stated. Use "startTLS" with port 389 and it will be secure. This is all well documented. Please read the slapd(8C) manual page if you want to understand the options for which port(s) slapd should listen to. Please read the ldapsearch(1) man page to see the options to ldapsearch that you can use to require startTLS. --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

12 years, 5 months

Re: Syncrepl SSL fail

by Hugo Deprez

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 ? 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

13 years, 6 months

Re: IETF opinion change on "implicit TLS" vs. StartTLS

by Dieter Klünter

Am Mon, 12 Feb 2018 18:10:29 -0800 schrieb Quanah Gibson-Mount <quanah(a)symas.com>: > --On Tuesday, February 13, 2018 9:31 AM +1000 William Brown > <wibrown(a)redhat.com> wrote: > > > On Mon, 2018-02-12 at 14:30 +0100, Michael Ströder wrote: > >> HI! > >> > >> To me this rationale for SMTP submission with implicit TLS seems > >> also applicable to LDAPS vs. StartTLS: > >> > >> https://tools.ietf.org/html/rfc8314#appendix-A > >> > >> So LDAPS should not be considered deprecated. Rather it should be > >> recommended and the _optional_ use of StartTLS should be strongly > >> discouraged. > > > > Yes, I strongly agree with this. I have evidence to this fact and > > can provide it if required, > > Personally, I'm all for it. I'd suggest using the above RFC as a > template for one formalizing port 636, so it's finally a documented > standard. We have had discussed this topic some 10 years ago, at that time Kurt had some concerns with regard to ldaps and port 636. Unfortunately I can't remember details. -Dieter -- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E

7 years, 3 months

Re: IETF opinion change on "implicit TLS" vs. StartTLS

by William Brown

On Mon, 2018-02-12 at 18:10 -0800, Quanah Gibson-Mount wrote: > --On Tuesday, February 13, 2018 9:31 AM +1000 William Brown > <wibrown(a)redhat.com> wrote: > > > On Mon, 2018-02-12 at 14:30 +0100, Michael Ströder wrote: > > > HI! > > > > > > To me this rationale for SMTP submission with implicit TLS seems > > > also > > > applicable to LDAPS vs. StartTLS: > > > > > > https://tools.ietf.org/html/rfc8314#appendix-A > > > > > > So LDAPS should not be considered deprecated. Rather it should be > > > recommended and the _optional_ use of StartTLS should be strongly > > > discouraged. > > > > Yes, I strongly agree with this. I have evidence to this fact and > > can > > provide it if required, > > Personally, I'm all for it. I'd suggest using the above RFC as a > template > for one formalizing port 636, so it's finally a documented standard. Great! Where do we go from here to get this formalised properly? > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by > OpenLDAP: > <http://www.symas.com> > -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane

7 years, 3 months

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

by Howard Chu

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, 8 months

openldap-technical search results for query "starttls"