On Wed, Aug 09, 2017 at 10:31:03AM +0200, r0m5 wrote:
>I still have issues though, with applications randomly failing STARTTLS
>to my consumers :-(
Are you still using the TLS_REQCERT option? If you are, you could be
seeing ITS#8385.
--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
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>
> There are some good instances where StartTLS isn't attractive: when the LDAP servers are behind F5 BigIPs for example.
> My 2 cents.
Yeah, true. Depends on environment and some kit just won't do StartTLS.
On Mon, Mar 12, 2012 at 9:41 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote:
> --On Monday, March 12, 2012 6:52 PM -0700 Peter Wood <
> peterwood.sd(a)gmail.com> wrote:
>
> Hi,
>>
>>
>> I setup openldap-2.4.23 server
>>
>
> Why? I'd suggest you start with the current release, 2.4.30. You may
> also want to look at <http://www.openldap.org/its/**index.cgi/?findid=7197<http://www.openldap.org/its/index.cgi/?findid=7197>
> >
>
>
That's the openldap version in centos6.2 repo. In production I try to stick
with stock versions.
Also I tried all variations of olcTLSVerifyClient: [demand|hard|true] with
the same result.
I don't think StartTLS is enabled. I'm wondering if just setting
olcTLSCACertificateFile, olcTLSCertificateFile and olcTLSCertificateKeyFile
is enough to get StartTLS enabled.
It's very frustrating. I'd hate to go to ldaps just because I can't get
StartTLS working.
Is there anything else I have to set on the server to get StartTLS working?
Thanks
Peter
ldap(a)mm.st writes:
> While sniffing traffic using tcpdump and using various
> ldapsearch options I noticed that if the client doesn't request starttls
> or connect on 636 is is possible to grab a users ldap record and the
> transmission is in clear text.
Yup...
> If I authenticate to the server using the -W option to ldapsearch the
> record is sent with the SSHA encrypted password.
No, -W has nothing to do with it. ldaps:// or -Z(Z) does.
Packet-sniff "ldapwhoami -xh ldap://<server>/ -W" without -Z to see.
> I guess this behavior is expected since the server is listening on 389
> and it is up to the client to initialize the starttls session, but I was
> wondering if there was a way to force the server to only use starttls on
> 398 and not rely on the the client to set up starttls?
No, it's the client which takes the initiative to send Bind with an
unencrypted password as its first network packet, without a StartTLS
first. The best you can do is to make the server complain in the
hope that the user will learn to Not Do That. We use this:
security simple_bind=128 update_ssf=128
localSSF 128
The first returns the error "Confidentiality required" to Bind and
update requests with security strength < 128, the 2nd raises the
security strength which slapd considers ldapi:// to have, so we
don't receive that error when updating the database over ldapi://.
(I don't know what would be good values nowadays, the rationale
of these numbers are lost in the mist of time. The default for
localSSF is 71, so maybe that's fine for security too.)
> One option
> would be to only have the server start on 636 and not have it listen on
> 389, but we would like to keep the same functionality if possible. Am I
> missing something obvious? The only option that I see as a possiblity is
> the TLSVerifyClient { never | allow | try | demand } in slapd.conf.
> But, it's unclear to me if this will provide the desired effect.
It won't. That is about what happens when the client does use TLS, it
doesn't affect what happens when it doesn't.
--
Hallvard
--On August 4, 2009 4:08:14 PM -0700 Ivan Ordonez
<iordonez(a)nature.berkeley.edu> wrote:
>> ldaps:// and startTLS are mutually exclusive. Pick one and only one.
> We tried removing the "s" on ldaps:// and still no go.
I probably would have tried just ldaps:// first and removed trying to do
startTLS and seeing if that works.
But if neither works, I'd advise spending some time with ldapsearch and
either ldaps:// uris or ldap:// uris with -ZZZ until you can see why your
ldap server doesn't like it.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
--On October 15, 2011 5:10:24 PM +0300 Nick Milas <nick(a)eurobjects.com>
wrote:
> On 15/10/2011 2:30 μμ, Olivier Guillard wrote:
>
>> If you youldaps:// add this :
>>
>> tls_reqcert=demand
>> and add starttls=critical
>
> In my installations, syncrepl doesn't work with these directives
> (although ldapsearch using ldaps: works fine).
startTLS and ldaps are two entirely different mechanisms, and do not work
together. I.e., you cannot do startTLS to an ldaps:// URI.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
On Thu, Mar 31, 2022 at 04:29:04 -0000, thomaswilliampritchard(a)gmail.com wrote:
> Quanah Gibson-Mount wrote:
> > So from that standpoint, I'd personally prefer to see ldaps:/// qualified
> > in an RFC so the standardization argument goes away and ldaps be noted as
> > the preferred method for sites that require encryption.
>
> I agree there is no technical reason LDAPS would not be better. It should be made standard.
There are technical reasons in fact, STARTTLS has (had) implementation
issues both on client- and server-side: https://nostarttls.secvuln.info/
Not necessarily in OpenLDAP, but it illustrates why in general, protocols
wrapped in TLS are now preferedd over STARTTLS. (See also RFC8314 for
e-mail protocols.)
Geert
Dieter Klünter wrote:
> Am Mon, 2 Nov 2015 17:28:06 +0100
> schrieb Matthias Apitz <guru(a)unixarea.de>:
>> I'm trying to make from FreeBSD a LDAPsearch in some Novell eDirectory
>> with the following command:
>>
>> $ ldapsearch -Z -H ldaps://romega:1027 -b 'ou=person,o=uni' -D
> [...]
>
> Quite obvious, you initiated startTLS AND ldaps. To my knowledge,
> edirectory does not support startTLS, so just omit -Z.
Novell eDirectory *does* support StartTLS ext. op.
At least 8.7 and later I have tested some years ago.
Did not test earlier versions though.
Ciao, Michael.
I've removed the starttls=no syntax and the line now reads.
olcDbStartTLS: ldaps tls_cacert="/appl/openldap/etc/openldap/tls/cacerts.cer
" tls_reqcert=demand tls_crlcheck=none
I have verified the change propagated to the configuration directory and restarted the instance. I saw no errors during configuration parsing in the log. I am still seeing this error when the chain overlay tries to follow the referral but no complaints when syncrepl connects.
TLS trace: SSL_connect:SSLv3 read server hello A
TLS certificate verification: depth: 1, err: 19, subject: /C=US/ST=Ohio/L=Columbus/O=American Electric Power/OU=Complex - Middleware/CN=AEP Root CA (2014)/emailAddress=middleware(a)aep.com, issuer: /C=US/ST=Ohio/L=Columbus/O=American Electric Power/OU=Complex - Middleware/CN=AEP Root CA (2014)/emailAddress=middleware(a)aep.com
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).
Thanks again for the assist(s). Any other thoughts?
-Jon
-----Original Message-----
From: Quanah Gibson-Mount [mailto:quanah@symas.com]
Sent: Friday, July 07, 2017 2:03 PM
To: Jon C Kidder; openldap-technical(a)OpenLDAP.org
Subject: [EXTERNAL] Re: back-ldap and ldaps not working
This is an EXTERNAL email. STOP. THINK before you CLICK links or OPEN attachments.
**********************************************************************
--On Friday, July 07, 2017 6:27 PM +0000 Jon C Kidder <jckidder(a)aep.com>
wrote:
> olcDbStartTLS: ldaps starttls=no
> tls_cacert="/appl/openldap/etc/openldap/tls/cacerts.cer"
> tls_reqcert=demand tls_crlcheck=none
There is no such option as "starttls" for the olcDbStartTLS parameter.
>From the man page:
tls {[try-]start|[try-]propagate|ldaps}
[tls_cert=<file>]
[tls_key=<file>] [tls_cacert=<file>]
[tls_cacertdir=<path>]
[tls_reqcert=never|allow|try|demand]
[tls_cipher_suite=<ciphers>] [tls_crlcheck=none|peer|all]
Specify the use of TLS when a regular connection is
initialized.
The StartTLS extended operation will be used unless the
URI
directive protocol scheme is ldaps://. In that case this
keyword
may only be set to "ldaps" and the StartTLS operation will
not
be used. propagate issues the StartTLS operation only if
the
original connection did. The try- prefix instructs the proxy
to
continue operations if the StartTLS operation failed; its use
is
not recommended.
My guess then is everything past that point is ignored, since you've
provided invalid configuration data.
The attribute is also poorly named, as it may or may not have anything to
do with startTLS. More likely it should have just been called olcDbTLS
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.symas.com&d=DwICAg&… >
