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&… >
--On Tuesday, March 13, 2012 11:03 AM -0700 Peter Wood
<peterwood.sd(a)gmail.com> wrote:
>
>
>
> 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>
>
>
>
>
>
> 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?
How are you testing to see if it or is not working? Just run ldapsearch -x
-ZZ -H ldap://<hostname>
to force 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
Is it possible to configure the server to reject requests on non-secure connections with the exception of the StartTLS extended request? In other words, when an LDAP client connects on the clear-text port, can the server be configured to reject all requests on that exception except for the StartTLS extended request in order to prevent clients from transmitting data in the clear?
Patrick Patterson writes:
>On Wed, Jul 30, 2008 at 9:59 AM, J Davis <mrsalty0(a)gmail.com> wrote:
Pet peeve: While it doesn't help your problem, you should in addition to
this:
>> access to *
>> by tls_ssf=128 ssf=128 anonymous auth
>> by tls_ssf=128 ssf=128 self write
use something like 'security simple_bind=128 update_ssf=128'. This
gives the result code confidentialityRequired instead of
invalidCredentials when the ssf is insufficient. Thus users who did not
use TLS don't get the impression that they just sent the wrong password
- and maybe then send the unprotected password again.
> You may want to try adding -q as one of the options to your ldapsearch.
No, OpenLDAP ldapsearch has no -q option. There is a -Q option, but
that's for SASL which is something else than SSL.
> It appears that the tls_ssf turns on STARTTLS, instead of LDAP over
> SSL and in order to use that, you need to tell the client to use
> starttls as well, which is what (if I read the man page correctly), -q
> does.
No. STARTTLS is turned on in the client, not the server. And whether
you use SSL aka TLS via STARTTLS or ldaps:// is irrelevant for the
tls_ssf access control clause.
--
Hallvard
> Is there anything else I have to set on the server to get StartTLS
> working?
Check "man ldapsearch" for -Z[Z] option.
If you want to enforce StartTLS, set appropriate SSF with olcSecurity:
$ ldapsearch -x -H ldap://server
ldap_bind: Confidentiality required (13)
additional info: TLS confidentiality required
$ ldapsearch -x -ZZ -H ldap://server
...
# search result
...
On 03/13/2012 12:03 PM, Peter Wood wrote:
>
>
> On Mon, Mar 12, 2012 at 9:41 PM, Quanah Gibson-Mount
> <quanah(a)zimbra.com <mailto:quanah@zimbra.com>> wrote:
>
> --On Monday, March 12, 2012 6:52 PM -0700 Peter Wood
> <peterwood.sd(a)gmail.com <mailto:peterwood.sd@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>
>
>
> 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.
Yes, it is.
>
> 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?
Can you provide the exact command line you are using to test the server
connection? Note that if the client is using regular LDAP and not LDAPS
nor LDAP+startTLS, the olcTLSVerifyClient: demand setting does nothing.
If you are trying to make the client always use SASL/EXTERNAL auth with
a valid client cert, you must first force the server to reject any
non-TLS/SSL connection using the sasl-secprops minssf setting.
>
> Thanks
> Peter
Peter Wood wrote:
>
>
> On Mon, Mar 12, 2012 at 9:41 PM, Quanah Gibson-Mount <quanah(a)zimbra.com
> <mailto:quanah@zimbra.com>> wrote:
>
> --On Monday, March 12, 2012 6:52 PM -0700 Peter Wood
> <peterwood.sd(a)gmail.com <mailto:peterwood.sd@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?
No. StartTLS is an LDAP Request, the client has to ask for it. There is
nothing a server can do to initiate it.
The TLSVerifyClient setting only affects sessions where the client has already
initiated TLS. To force connections to require TLS, look at the olcRequires
and olcSecurity settings in slapd-config(5).
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
>>> Michael Ströder <michael(a)stroeder.com> schrieb am 25.10.2018 um 16:11 in
Nachricht <5ddb70fe-958b-2913-2426-0a7db4a9ef6d(a)stroeder.com>:
> 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.
Hi!
Thanks for the "heads up"; fortunately I have "starttls=critical" for each
syncrepl ;-)
Regards,
Ulrich
Le 2017-08-09 14:13, Michael Ströder a écrit :
> r0m5 wrote:
>
>> So I set up a PKI and now it looks OK regarding syncrepl. So I guess my problem might
>> be related to ITS#8427, which I didn't see before posting here.
>>
>> I still have issues though, with applications randomly failing STARTTLS to my consumers
>
> Many problems like this are caused by not getting the PKI to issue correct public-key
> certs. Especially you should put all DNS names a LDAP client might use to connect to your
> LDAP server in subjectAltName extension.
>
> E.g. ITS#8427 says:
> "Provide the servers with TLS certificates that are correct but do not include
> an address used in syncrepl provider setting."
> What the heck does that mean?!?
>
> Ciao, Michael.
I guess the guy uses in order to reproduce a provider certificate which
is signed by a CA his consumer trusts, but the consumer connects to the
provider using a DNS name different from the certificate CN and not
included in subjectAltName.
The certificate I used when I had the problem was self signed but my
consumer was connecting to a correct DNS name (the CN of the
certificate).
In both cases the certificate is not "valid", but apparently for
different reasons.
Regarding my applications randomly failing STARTTLS to my consumers,
it's not related to the use of a DNS name different from the certificate
CN and not included in subjectAltName. Considering an application using
always the same DNS name to connect to the consumer and connecting to
the same consumer which presents always the same certificate
(self-signed) : most of the time this application succeeds STARTTLS, but
sometimes fails. Log on the consumer :
conn=3232 fd=20 ACCEPT from IP=192.168.74.222:50187 (IP=0.0.0.0:389)
conn=3232 op=0 EXT oid=1.3.6.1.4.1.1466.20037
conn=3232 op=0 STARTTLS
conn=3232 op=0 RESULT oid= err=0 text=
conn=3232 fd=20 TLS established tls_ssf=128 ssf=128
conn=3232 fd=20 closed (connection lost)
I will dig more into it. So far it appears than only PHP applications
fail this way, it seems like there are no probrems with STARTTLS from
freeradius or Apache Basic AuthType with AuthBasicProvider ldap.
