Search results for "starttls" - openldap-technical

Re: Openldap server with TLS not working

by Michael Ströder

btb wrote: > On 2013.10.03 12.13, Michael Ströder wrote: >> "Although there is no technical specification for ldaps:// it is widely used." > > sorry, i'm not sure what you're getting at. i've already clearly stated > exactly that, as is clearly seen below. The point is that everybody should also configure ldaps:// to provide the service for a wide range of implementations which are not capable to do StartTLS ext.op. And therefore it's pure nonsense to babble about LDAPS being deprecated and people should not configure it. > you're welcome to find ldaps more secure than starttls. plenty of others don't. So I'm very curious whether you have a single argument why not. Again: With StartTLS ext.op. it's more likely that a misconfigured client sends a clear-text password in a clear-text LDAP PDU and thinks everything works. Ciao, Michael.

11 years, 1 month

Ubuntu Server 12.04: StartTLS

by admus

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?

12 years

Re: Upgrading from 2.4.26 to 2.4.41: Stricter checks prevent startup?

by Michael Ströder

On 10/25/18 8:59 AM, Ulrich Windl wrote: > As we do not actually use ldaps for replication that second line could be dropped easily As a side note: You should really use LDAPS or LDAP with StartTLS ext.op. for replication. Otherwise a MITM attacker could trick a replica into delivering false data to clients. Are you using StartTLS in syncrepl statement? Ciao, Michael.

6 years, 1 month

Re: Syncrepl SSL fail

by Philip Guenther

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, 1 month

Re: Openldap server with TLS not working

by btb＠bitrate.net

On Oct 2, 2013, at 20.16, Axel Grosse <agrosse(a)axway.com> wrote: > Hi ben, > thanks for the comment. > agree with you on TLS usage should be perferred > but the client that is connecting is only capable of LDAPS ... he has not implemented TLS Client jet . > > But can you please take a look to the error I am facing > > openssl s_client -connect 192.168.30.169:389 -showcerts -CAfile ./ssl/VordelCA.crt > CONNECTED(00000003) > 710:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188: > > any idea what can cause this ? if you have a client that is only capable of ldaps, then you should be connecting to port 636, the ldaps port. under nominal circumstances, you cannot do ldaps via port 389. to make use of encryption and use port 389, you need to use starttls [not ldaps], which for s_client means using the -starttls option [but s_client does not do starttls for ldap anyway]. -ben

11 years, 1 month

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

by Quanah Gibson-Mount

--On Thursday, September 28, 2017 2:08 PM -0400 Robert Heller <heller(a)deepsoft.com> wrote: > 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. You're using a bit of a confusing word soup. ldaps == Deprecated, non-standard way of securing connection to LDAP. Usually on port 636 startTLS == RFC standard way of securing connections to LDAP. Usually on port 389 If you are using ldaps, then you want startTLS to be disabled if you are using startTLS, then you want it enabled. Your SSD config has: ldap_id_use_start_tls = false so this would be correct with use with ldaps:/// You don't provide any error messages or other useful information, so one can only specualte what issues you may be having. I would note that most versions of openssl s_client do not support startTLS with LDAP (Thus you cannot use it to test port 389). That feature was only recently added to OpenSSL. If you want to test startTLS on port 389, your best bet is to use an ldap client utility such as ldapwhoami, like: ldapwhoami -x -ZZ -H ldap://myhost:389 -D binddn -w --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

7 years, 1 month

Re: openLDAP: LDAP and LDAP over TLS support at same time

by Raf Czlonka

On Wed, Mar 28, 2018 at 09:15:51PM BST, Quanah Gibson-Mount wrote: > --On Sunday, March 25, 2018 5:29 PM +0530 GOKUL G <g.gokul1991(a)gmail.com> > wrote: > > > ISSUE: > > We are able to integrate openLDAP with our application and achieve LDAP > > or LDAP/TLS requirement separately. > > Since, the support for TLS in openLDAP is macro controlled (HAVE_TLS), at > > compile time itself its decided whether LDAP or LDAPs . And we are not > > able to take this decision at run-time. > > If we compile openLDAP software with HAVE_TLS and use it for normal > > ldapsearch, this ldap command is seen in trace as ldap message over SSL > > without any encryption. But not as normal LDAP message. > > You appear to be misunderstanding something if you believe you require two > different library builds. Clearly all of the existing C based clients can > do plaintext (ldap) with a library where TLS support is enabled (note: NOT > required). > > I would also note there is much more to TLS encryption with LDAP than you've > noted. > > There are two methods of doing TLS encryption. One uses the RFC STARTTLS > method, the other uses a TLS dedicated port (defaults to 443) using the ^^^ Hi Quanah, You obviously meant 636, right[0]? [0] https://www.iana.org/assignments/service-names-port-numbers/service-names-p… Regards, Raf > non-RFC ldaps URI. > > So, an LDAP client can connect in the following methods: > > a) plain text (ldap:/// or ldapi:///) > b) issuing a startTLS operation (ldap:/// or ldapi:///) > c) dedicated TLS port (ldaps:///) > > I would note that it is entirely possible, with a well written application, > to support all of the above with the OpenLDAP C API compiled with HAVE_TLS. > If you are unable to do this, you're misusing the API and/or do not > understand the API. Generally, your client simply needs to know: > > Should the connection be encrypted? > No? -> > Use ldap:/// without the startTLS control > Yes? -> > Do they want to use ldaps or startTLS? > startTLS -> Use ldap with the startTLS control > use ldaps > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

6 years, 8 months

Re: tls issues with clients

by Quanah Gibson-Mount

--On May 19, 2008 1:26:34 PM -0700 Kyle Corupe <kcorupe(a)corpedia.com> wrote: > I'm pretty confused, because my clients are setup with almost identical > ldap://heracross.corpedia.internal/ > ldaps://heracross.corpedia.internal/ -b dc=corpedia,dc=internal -x -Z ldaps:// uses SSL (via LDAPv2), not startTLS (LDAPv3). You cannot combine startTLS (-Z) with SSL. Fix your configuration. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

16 years, 6 months

Re: problem with syncrepl and STARTTLS

by Ryan Tandy

On Wed, Aug 09, 2017 at 07:47:06PM +0200, r0m5 wrote: >Yes so far "TLS_REQCERT allow" on the PHP applications' OS because the >OpenLDAP consumers certs are still self-signed. > >Indeed I saw #8385 linked in ITS#8427. From my understanding #8385 deals >with certificate validation using libldap. php5-ldap depends on libldap >and the versions of libldap install on our php frontends are old >(jessie...). I'm actually about to propose an update for stretch including that fix along with some others (and will update jessie-backports once it's released for stretch). I hadn't intended to backport it as far as jessie, but I have some other changes pending for jessie as well so I may as well include it. >So I will also make sure that the PHP frontends trust the CA that will >sign the new LDAP consumer's certificates. I guess that should solve the >STARTTLS problems from application to consumer the same way it (looks >like it) solved the STARTTLS problems from consumers to providers. Yes, it should.

7 years, 3 months

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

by Quanah Gibson-Mount

--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. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

6 years, 9 months

openldap-technical search results for query "starttls"