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