Hi I am new to OpenLDAP and have to configure and LDAP Proxy in one project. Thanks to the mailing lists I managed to setup and configure the Ldap Proxy an get it working one 389 .
One of the next requirenents is to secure the outside connection with SSL. So I have to configure LDAP over SSL .. I am using openldap 2.3.43-12.el5 on Redhat EL 5.5 (Tikanga)
I created the certificates with openssl 0.9.8e-12.el5_4.6 and configured the slapd.conf
part of slapd.conf # The next three lines allow use of TLS for encrypting connections using a # dummy test certificate which you can generate by changing to # /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on # slapd.pem so that the ldap user or group can read it. Your client software # may balk at self-signed certificates, however.
TLSCACertificateFile /etc/openldap/ssl/VordelCA.crt TLSCertificateFile /etc/openldap/ssl/VordelDevInt.crt TLSCertificateKeyFile /etc/openldap/ssl/VordelDev.key TLSCipherSuite HIGH:MEDUIM:!SSLv2 TLSVerifyClient never
... ######
server got up on 636 but when I try to connect I get SSL handshake error ...
when I test on the server itself .. 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:
I got this one ...
any idea whats my problem ?
regards Axel
On 2013.10.02 07.29, Axel Grosse wrote:
when I test on the server itself .. 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:
ldaps [port 636] is deprecated. use starttls with the standard port [389]. to test, just use ldapsearch [see the reference to -Z in the man page]
-ben
btb wrote:
On 2013.10.02 07.29, Axel Grosse wrote:
when I test on the server itself .. 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:
ldaps [port 636] is deprecated. use starttls with the standard port [389]. to test, just use ldapsearch [see the reference to -Z in the man page]
This is nonsense.
From a security perspective there's no reason not to use LDAPS. Well, I'd even recommend LDAPS since SSL/TLS handshake is done *before* a client can send an LDAP PDU. With my deployments I always enable both but prefer LDAPS.
I cannot imagine that any LDAP server or client will ever drop support for LDAPS since this would immediately rule out this implementation from broader market share.
Ciao, Michael.
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 ?
AXEL GROSSE Principal Solution Architect, Sales Solution Center, Axway P: +61-405-995-768 828 Pacific Highway Gordon, 2072 NSW agrosse@axway.com http://www.axway.com
-----Original Message----- From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of btb Sent: Wednesday, 2 October 2013 10:57 PM To: openldap-technical@openldap.org Subject: Re: Openldap server with TLS not working
On 2013.10.02 07.29, Axel Grosse wrote:
when I test on the server itself .. 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:
ldaps [port 636] is deprecated. use starttls with the standard port [389]. to test, just use ldapsearch [see the reference to -Z in the man page]
-ben
On Oct 2, 2013, at 20.16, Axel Grosse agrosse@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 Oct 2, 2013, at 11.47, Michael Ströder michael@stroeder.com wrote:
btb wrote:
On 2013.10.02 07.29, Axel Grosse wrote:
when I test on the server itself .. 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:
ldaps [port 636] is deprecated. use starttls with the standard port [389]. to test, just use ldapsearch [see the reference to -Z in the man page]
This is nonsense.
From a security perspective there's no reason not to use LDAPS. Well, I'd even recommend LDAPS since SSL/TLS handshake is done *before* a client can send an LDAP PDU. With my deployments I always enable both but prefer LDAPS.
I cannot imagine that any LDAP server or client will ever drop support for LDAPS since this would immediately rule out this implementation from broader market share.
i'm not sure what exactly you mean by "this is nonsense". ldaps was never offered as a formal specification, and *is* deprecated. that isn't nonsense. that's a fact: http://www.openldap.org/faq/data/cache/605.html . ldaps may well be in continued use even given its deprecation, but no one is debating that, and it's continued use in light of being deprecated does not change that it's deprecated. we all know it's still heavily used, and probably will continue to be for, at the very least, quite some time.
-ben
Am Thu, 3 Oct 2013 00:16:28 +0000 schrieb Axel Grosse agrosse@axway.com:
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 ?
AXEL GROSSE Principal Solution Architect, Sales Solution Center, Axway P: +61-405-995-768 828 Pacific Highway Gordon, 2072 NSW agrosse@axway.com http://www.axway.com
-----Original Message----- From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of btb Sent: Wednesday, 2 October 2013 10:57 PM To: openldap-technical@openldap.org Subject: Re: Openldap server with TLS not working
On 2013.10.02 07.29, Axel Grosse wrote:
when I test on the server itself .. 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:
ldaps [port 636] is deprecated. use starttls with the standard port [389]. to test, just use ldapsearch [see the reference to -Z in the man page]
You are connnecting to port 389, but s_client is not able to initiate a LDAP startTLS session (only SMTP and IMAP), so you have to connect ldaps and port 636.
-Dieter
On Oct 3, 2013, at 04.46, Dieter Klünter dieter@dkluenter.de wrote:
You are connnecting to port 389, but s_client is not able to initiate a LDAP startTLS session (only SMTP and IMAP), so you have to connect ldaps and port 636.
s_client does support starttls for other protocols aside from smtp and imap [pop3, ftp, xmpp]. just not ldap.
-ben
Hi Ben, Dieter can we focus on LDAPS because TLS1 is not an option and even if LDAPS is deprecated I should be able to configure it ..
TLSCACertificateFile /etc/openldap/ssl/VordelCA.crt TLSCertificateFile /etc/openldap/ssl/VordelDev.crt TLSCertificateKeyFile /etc/openldap/ssl/VordelDev.key TLSVerifyClient never
are this entries in the slapd.conf sutable for LDAPS ? if not whats missing ?
start the server with /usr/sbin/slapd -h ldap://192.168.30.169:636 -u ldap
thanks a lot Axel
AXEL GROSSE Principal Solution Architect, Sales Solution Center, Axway P: +61-405-995-768 828 Pacific Highway Gordon, 2072 NSW agrosse@axway.com http://www.axway.com
-----Original Message----- From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Dieter Klünter Sent: Thursday, 3 October 2013 6:46 PM To: openldap-technical@openldap.org Subject: Re: Openldap server with TLS not working
Am Thu, 3 Oct 2013 00:16:28 +0000 schrieb Axel Grosse agrosse@axway.com:
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 ?
AXEL GROSSE Principal Solution Architect, Sales Solution Center, Axway P: +61-405-995-768 828 Pacific Highway Gordon, 2072 NSW agrosse@axway.com http://www.axway.com
-----Original Message----- From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of btb Sent: Wednesday, 2 October 2013 10:57 PM To: openldap-technical@openldap.org Subject: Re: Openldap server with TLS not working
On 2013.10.02 07.29, Axel Grosse wrote:
when I test on the server itself .. 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:
ldaps [port 636] is deprecated. use starttls with the standard port [389]. to test, just use ldapsearch [see the reference to -Z in the man page]
You are connnecting to port 389, but s_client is not able to initiate a LDAP startTLS session (only SMTP and IMAP), so you have to connect ldaps and port 636.
-Dieter
Hi,
On Thu, 3 Oct 2013, Axel Grosse wrote:
Hi Ben, Dieter can we focus on LDAPS because TLS1 is not an option and even if LDAPS is deprecated I should be able to configure it ..
TLSCACertificateFile /etc/openldap/ssl/VordelCA.crt TLSCertificateFile /etc/openldap/ssl/VordelDev.crt TLSCertificateKeyFile /etc/openldap/ssl/VordelDev.key TLSVerifyClient never
are this entries in the slapd.conf sutable for LDAPS ? if not whats missing ?
start the server with /usr/sbin/slapd -h ldap://192.168.30.169:636 -u ldap
in that case you need ldaps:// and not ldap:/ in the url. Now you are starting plaintext ldap on port 636.
Please just start slapd without any host specification and test using openssl s_client connect target:636
After that works start trimming down the ports slapd binds to.
Greetings Christian
thanks a lot Axel
AXEL GROSSE Principal Solution Architect, Sales Solution Center, Axway P: +61-405-995-768 828 Pacific Highway Gordon, 2072 NSW agrosse@axway.com http://www.axway.com
-----Original Message----- From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Dieter Klünter Sent: Thursday, 3 October 2013 6:46 PM To: openldap-technical@openldap.org Subject: Re: Openldap server with TLS not working
Am Thu, 3 Oct 2013 00:16:28 +0000 schrieb Axel Grosse agrosse@axway.com:
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 ?
AXEL GROSSE Principal Solution Architect, Sales Solution Center, Axway P: +61-405-995-768 828 Pacific Highway Gordon, 2072 NSW agrosse@axway.com http://www.axway.com
-----Original Message----- From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of btb Sent: Wednesday, 2 October 2013 10:57 PM To: openldap-technical@openldap.org Subject: Re: Openldap server with TLS not working
On 2013.10.02 07.29, Axel Grosse wrote:
when I test on the server itself .. 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:
ldaps [port 636] is deprecated. use starttls with the standard port [389]. to test, just use ldapsearch [see the reference to -Z in the man page]
You are connnecting to port 389, but s_client is not able to initiate a LDAP startTLS session (only SMTP and IMAP), so you have to connect ldaps and port 636.
-Dieter
2013/10/3 Axel Grosse agrosse@axway.com
Hi Ben, Dieter can we focus on LDAPS because TLS1 is not an option and even if LDAPS is deprecated I should be able to configure it ..
TLSCACertificateFile /etc/openldap/ssl/VordelCA.crt TLSCertificateFile /etc/openldap/ssl/VordelDev.crt TLSCertificateKeyFile /etc/openldap/ssl/VordelDev.key TLSVerifyClient never
are this entries in the slapd.conf sutable for LDAPS ? if not whats missing ?
start the server with /usr/sbin/slapd -h ldap://192.168.30.169:636 -u ldap
Use "-h ldaps://192.168.30.169 " in slapd start command.
Clément.
btb@bitrate.net wrote:
On Oct 2, 2013, at 11.47, Michael Ströder michael@stroeder.com wrote:
btb wrote:
On 2013.10.02 07.29, Axel Grosse wrote:
when I test on the server itself .. 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:
ldaps [port 636] is deprecated. use starttls with the standard port [389]. to test, just use ldapsearch [see the reference to -Z in the man page]
This is nonsense.
From a security perspective there's no reason not to use LDAPS. Well, I'd even recommend LDAPS since SSL/TLS handshake is done *before* a client can send an LDAP PDU. With my deployments I always enable both but prefer LDAPS.
I cannot imagine that any LDAP server or client will ever drop support for LDAPS since this would immediately rule out this implementation from broader market share.
i'm not sure what exactly you mean by "this is nonsense". ldaps was never offered as a formal specification, and *is* deprecated.
I don't know of any document forbidding use of LDAPS. I don't know any server which implements StartTLS which is not capable of LDAPS (despite configuration choice).
that's a fact: http://www.openldap.org/faq/data/cache/605.html .
FAQ entries are no formal specification. But you should read all of the FAQ:
"Although there is no technical specification for ldaps:// it is widely used."
ldaps may well be in continued use even given its deprecation, but no one is debating that, and it's continued use in light of being deprecated does not change that it's deprecated. we all know it's still heavily used, and probably will continue to be for, at the very least, quite some time.
And because it's heavily used it's nonsense to teach everybody this pseudo argument about "deprecated". And as said I find it even to be more secure.
Ciao, Michael.
On 2013.10.03 08.22, Axel Grosse wrote:
-----Original Message-----
From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Dieter Klünter Sent: Thursday, 3 October 2013 6:46 PM To: openldap-technical@openldap.org Subject: Re: Openldap server with TLS not working
Am Thu, 3 Oct 2013 00:16:28 +0000 schrieb Axel Grosse agrosse@axway.com:
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 ?
-----Original Message----- From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of btb Sent: Wednesday, 2 October 2013 10:57 PM To: openldap-technical@openldap.org Subject: Re: Openldap server with TLS not working
On 2013.10.02 07.29, Axel Grosse wrote:
when I test on the server itself .. 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:
ldaps [port 636] is deprecated. use starttls with the standard port [389]. to test, just use ldapsearch [see the reference to -Z in the man page]
You are connnecting to port 389, but s_client is not able to initiate a LDAP startTLS session (only SMTP and IMAP), so you have to connect ldaps and port 636.
-Dieter
Hi Ben, Dieter can we focus on LDAPS because TLS1 is not an option and even if LDAPS is deprecated I should be able to configure it ..
TLSCACertificateFile /etc/openldap/ssl/VordelCA.crt TLSCertificateFile /etc/openldap/ssl/VordelDev.crt TLSCertificateKeyFile /etc/openldap/ssl/VordelDev.key TLSVerifyClient never
are this entries in the slapd.conf sutable for LDAPS ? if not whats missing ?
nothing more is required
start the server with /usr/sbin/slapd -h ldap://192.168.30.169:636 -u ldap
/usr/sbin/slapd -h 'ldaps:///' [...]
you must specify ldaps, and you do not need to explicitly specify the port. 636 is the default. see man 8 slapd for details.
On 2013.10.03 12.13, Michael Ströder wrote:
btb@bitrate.net wrote:
On Oct 2, 2013, at 11.47, Michael Ströder michael@stroeder.com wrote:
btb wrote:
On 2013.10.02 07.29, Axel Grosse wrote:
when I test on the server itself .. 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:
ldaps [port 636] is deprecated. use starttls with the standard port [389]. to test, just use ldapsearch [see the reference to -Z in the man page]
This is nonsense.
From a security perspective there's no reason not to use LDAPS. Well, I'd even recommend LDAPS since SSL/TLS handshake is done *before* a client can send an LDAP PDU. With my deployments I always enable both but prefer LDAPS.
I cannot imagine that any LDAP server or client will ever drop support for LDAPS since this would immediately rule out this implementation from broader market share.
i'm not sure what exactly you mean by "this is nonsense". ldaps was never offered as a formal specification, and *is* deprecated.
I don't know of any document forbidding use of LDAPS. I don't know any server which implements StartTLS which is not capable of LDAPS (despite configuration choice).
deprecated != forbidden. no has has claimed there are any servers which only implement starttls.
that's a fact: http://www.openldap.org/faq/data/cache/605.html .
FAQ entries are no formal specification. But you should read all of the FAQ:
i guess you could take that up with the author of the faq entry - but you're right about formal specifications being important ;) . it's probably also worth noting that there are other quite well recognized protocols which have deprecated and/or abandoned their "tunneled" counterparts, some quite formally so - smtp, imap, and xmpp are a few which come to mind.
"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.
ldaps may well be in continued use even given its deprecation, but no one is debating that, and it's continued use in light of being deprecated does not change that it's deprecated. we all know it's still heavily used, and probably will continue to be for, at the very least, quite some time.
And because it's heavily used it's nonsense to teach everybody this pseudo argument about "deprecated". And as said I find it even to be more secure.
you're welcome to find ldaps more secure than starttls. plenty of others don't.
this has probably veered off topic enough at this point. over and out.
-ben
Hi all, Ben, Dieter, thank you for your help ... got it working on ldaps without TLS :-))
we can close that thread
cheers Axel
AXEL GROSSE Principal Solution Architect, Sales Solution Center, Axway P: +61-405-995-768 828 Pacific Highway Gordon, 2072 NSW agrosse@axway.com http://www.axway.com
-----Original Message----- From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of btb Sent: Friday, 4 October 2013 6:20 AM To: openldap-technical@openldap.org Subject: Re: Openldap server with TLS not working
On 2013.10.03 08.22, Axel Grosse wrote:
-----Original Message-----
From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Dieter Klünter Sent: Thursday, 3 October 2013 6:46 PM To: openldap-technical@openldap.org Subject: Re: Openldap server with TLS not working
Am Thu, 3 Oct 2013 00:16:28 +0000 schrieb Axel Grosse agrosse@axway.com:
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 ?
-----Original Message----- From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of btb Sent: Wednesday, 2 October 2013 10:57 PM To: openldap-technical@openldap.org Subject: Re: Openldap server with TLS not working
On 2013.10.02 07.29, Axel Grosse wrote:
when I test on the server itself .. 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:
ldaps [port 636] is deprecated. use starttls with the standard port [389]. to test, just use ldapsearch [see the reference to -Z in the man page]
You are connnecting to port 389, but s_client is not able to initiate a LDAP startTLS session (only SMTP and IMAP), so you have to connect ldaps and port 636.
-Dieter
Hi Ben, Dieter can we focus on LDAPS because TLS1 is not an option and even if LDAPS > is deprecated I should be able to configure it ..
TLSCACertificateFile /etc/openldap/ssl/VordelCA.crt > TLSCertificateFile /etc/openldap/ssl/VordelDev.crt > TLSCertificateKeyFile /etc/openldap/ssl/VordelDev.key > TLSVerifyClient never > > > are this entries in the slapd.conf sutable for LDAPS ? if not whats missing ?
nothing more is required
start the server with /usr/sbin/slapd -h ldap://192.168.30.169:636 -u ldap
/usr/sbin/slapd -h 'ldaps:///' [...]
you must specify ldaps, and you do not need to explicitly specify the port. 636 is the default. see man 8 slapd for details.
On Oct 3, 2013, at 17.46, Axel Grosse agrosse@axway.com wrote:
Hi all, Ben, Dieter, thank you for your help ... got it working on ldaps without TLS :-))
we can close that thread
glad you had success. a note of pedantry - just because ldaps was used doesn't mean tls was not. those two concepts are orthogonal. [e.g. starttls and tls are two different things]. in fact, tls should be [and probably is] used with your ldaps connection. ssl should not be, having been replaced by tls.
-ben
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.
openldap-technical@openldap.org