Hi everybody,
I try to setup a slapd with TLS. ldd /usr/sbin/slapd returns gnutls.so as waited.
I generated a self-signed certificate with these options : certtool --generate-privkey --outfile /etc/ldap/ssl/mykey.key certtool --generate-request --load-privkey /etc/ldap/ssl/mykey.key --outfile /etc/ldap/ssl/mycsr.csr
Basic Constraints (critical): Certificate Authority (CA): TRUE Key Purpose (not critical): TLS WWW Client. TLS WWW Server. Code signing. OCSP signing. Time stamping. Key Usage (critical): Digital signature. Key encipherment. Certificate signing. CRL signing.
My slapd start but when I try a debug I have : # gnutls-cli-debug -p 636 myip Checking for TLS 1.1 support... no Checking fallback from TLS 1.1 to... failed Checking for TLS 1.0 support... no Checking for SSL 3.0 support... no
Server does not support any of SSL 3.0, TLS 1.0 and TLS 1.1
Here is my slapd conf : olcTLSVerifyClient: demand olcTLSCertificateFile: /etc/ldap/ssl/mycsr.csr olcTLSCertificateKeyFile: /etc/ldap/ssl/mykey.key
Any help would be appreciate
On Friday, 20 May 2011 11:50:05 David Dumortier wrote:
Hi everybody,
I try to setup a slapd with TLS.
Do you mean START_TLS on ldap://, or ldaps:// ? I don't think you can test START_TLS on ldap:// with gnutls-cli-debug.
ldd /usr/sbin/slapd returns gnutls.so as waited.
I generated a self-signed certificate with these options : certtool --generate-privkey --outfile /etc/ldap/ssl/mykey.key certtool --generate-request --load-privkey /etc/ldap/ssl/mykey.key --outfile /etc/ldap/ssl/mycsr.csr
Basic Constraints (critical): Certificate Authority (CA): TRUE Key Purpose (not critical): TLS WWW Client. TLS WWW Server. Code signing. OCSP signing. Time stamping. Key Usage (critical): Digital signature. Key encipherment. Certificate signing. CRL signing.My slapd start
With what command-line arguments/options (specifically, what values provided to -h option)?
but when I try a debug I have : # gnutls-cli-debug -p 636 myip Checking for TLS 1.1 support... no Checking fallback from TLS 1.1 to... failed Checking for TLS 1.0 support... no Checking for SSL 3.0 support... no
Server does not support any of SSL 3.0, TLS 1.0 and TLS 1.1
Before doing this, did you verify that slapd is actually listening for ldaps on port 636?
I suspect you are running ldap:// on port 636.
Here is my slapd conf : olcTLSVerifyClient: demand olcTLSCertificateFile: /etc/ldap/ssl/mycsr.csr olcTLSCertificateKeyFile: /etc/ldap/ssl/mykey.key
Regards, Buchan
Le ven. mai 20 2011 � 01:04:52 +0200, Buchan Milne dit :
On Friday, 20 May 2011 11:50:05 David Dumortier wrote:
Hi everybody,
I try to setup a slapd with TLS.
Do you mean START_TLS on ldap://, or ldaps:// ? I don't think you can test START_TLS on ldap:// with gnutls-cli-debug.
ldaps:/// netstat -lataupe : tcp 0 0 0.0.0.0:636 0.0.0.0:* LISTEN 0 264360 29866/slapd
[...]
With what command-line arguments/options (specifically, what values provided to -h option)?
cat /etc/default/slapd : SLAPD_SERVICES="ldapi:/// ldaps:///"
but when I try a debug I have : # gnutls-cli-debug -p 636 myip Checking for TLS 1.1 support... no Checking fallback from TLS 1.1 to... failed Checking for TLS 1.0 support... no Checking for SSL 3.0 support... no
Server does not support any of SSL 3.0, TLS 1.0 and TLS 1.1
Before doing this, did you verify that slapd is actually listening for ldaps on port 636?
I suspect you are running ldap:// on port 636.
ldapsearch -W -H ldap://myip:636/ ldap_result: Can't contact LDAP server (-1)
ldapsearch -W -H ldaps://myip/ TLS: can't connect: Error in the push function.. ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
ldapsearch -ZZW -H ldaps://myip/ TLS: can't connect: Error in the push function.. ldap_start_tls: Can't contact LDAP server (-1) additional info: Error in the push function.
Here is my slapd conf : olcTLSVerifyClient: demand olcTLSCertificateFile: /etc/ldap/ssl/mycsr.csr olcTLSCertificateKeyFile: /etc/ldap/ssl/mykey.key
Regards, Buchan
On Fri, May 20, 2011 at 8:40 AM, David Dumortier d.dumortier@free.fr wrote:
With what command-line arguments/options (specifically, what values provided to -h option)?
cat /etc/default/slapd : SLAPD_SERVICES="ldapi:/// ldaps:///"
Thist enable only SSL port (636), TLS on 389 isn't available.
Before doing this, did you verify that slapd is actually listening for ldaps on port 636?
I suspect you are running ldap:// on port 636.
ldapsearch -W -H ldap://myip:636/ ldap_result: Can't contact LDAP server (-1)
No, -H ldaps://myip:636/ (to SSL/ldaps).
ldapsearch -W -H ldaps://myip/ TLS: can't connect: Error in the push function.. ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
No, this will connect on default port 389 with SSL/ldaps, isn't what you want.
ldapsearch -ZZW -H ldaps://myip/ TLS: can't connect: Error in the push function.. ldap_start_tls: Can't contact LDAP server (-1) additional info: Error in the push function.
No, this you need choose TLS (-Z) ou SSL (-H ldaps://...), not both.
ldapsearch -W -H ldaps://myip/ TLS: can't connect: Error in the push function.. ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
No, this will connect on default port 389 with SSL/ldaps, isn't what you want.
a small correction. specifying an uri with a scheme of ldaps will implicitly define that port 636 is used, as it should be, since port 636 is for ldaps. ldapsearch -W -H ldaps://myip/ will not result in port 389 being used, but rather, is the same as ldapsearch -W -H ldaps://myip:636/
ldapsearch -d -1 -H 'ldaps://localhost/'
ldap_url_parse_ext(ldaps://localhost/) ldap_create ldap_url_parse_ext(ldaps://localhost:636/??base) ldap_pvt_sasl_getmech ldap_search put_filter: "(objectclass=*)" put_filter: simple put_simple_filter: "objectclass=*" ldap_build_search_req ATTRS: supportedSASLMechanisms ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP localhost:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying ::1 636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 tls_write: want=93, written=93
Le ven. mai 20 2011 � 02:48:22 -0300, Reinaldo de Carvalho dit :
On Fri, May 20, 2011 at 8:40 AM, David Dumortier d.dumortier@free.fr wrote:
With what command-line arguments/options (specifically, what values provided to -h option)?
cat /etc/default/slapd : SLAPD_SERVICES="ldapi:/// ldaps:///"
Thist enable only SSL port (636), TLS on 389 isn't available.
It is what I want.
Before doing this, did you verify that slapd is actually listening for ldaps on port 636?
I suspect you are running ldap:// on port 636.
ldapsearch -W -H ldap://myip:636/ ldap_result: Can't contact LDAP server (-1)
No, -H ldaps://myip:636/ (to SSL/ldaps).
Tried it with same result :-(
[...]
-- Reinaldo de Carvalho http://korreio.sf.net http://python-cyrus.sf.net
"While not fully understand a software, don't try to adapt this software to the way you work, but rather yourself to the way the software works" (myself)
On Sat, May 21, 2011 at 12:04 PM, David Dumortier d.dumortier@free.fr wrote:
I suspect you are running ldap:// on port 636.
ldapsearch -W -H ldap://myip:636/ ldap_result: Can't contact LDAP server (-1)
No, -H ldaps://myip:636/ (to SSL/ldaps).
Tried it with same result :-(
You're really using a Certificate file (and not a CSR)?
Ldap client will validade the server certificate, you should especify TLS_CACERT /to/file or TLS_REQCERT never on /etc/ldap/ldap.conf
Hello,
Le sam. mai 21 2011 � 12:55:03 -0300, Reinaldo de Carvalho dit :
On Sat, May 21, 2011 at 12:04 PM, David Dumortier d.dumortier@free.fr wrote:
I suspect you are running ldap:// on port 636.
ldapsearch -W -H ldap://myip:636/ ldap_result: Can't contact LDAP server (-1)
No, -H ldaps://myip:636/ (to SSL/ldaps).
Tried it with same result :-(
You're really using a Certificate file (and not a CSR)?
Ldap client will validade the server certificate, you should especify TLS_CACERT /to/file or TLS_REQCERT never on /etc/ldap/ldap.conf
I used this page to generate a self-signed certificate : https://help.ubuntu.com/community/GnuTLS Perhaps a step for a certificate missed. Anyway I tried TLS_REQCERT never with the same result.
-- Reinaldo de Carvalho http://korreio.sf.net http://python-cyrus.sf.net
Le sam. mai 21 2011 � 12:55:03 -0300, Reinaldo de Carvalho dit :
On Sat, May 21, 2011 at 12:04 PM, David Dumortier d.dumortier@free.fr wrote:
I suspect you are running ldap:// on port 636.
ldapsearch -W -H ldap://myip:636/ ldap_result: Can't contact LDAP server (-1)
No, -H ldaps://myip:636/ (to SSL/ldaps).
Tried it with same result :-(
You're really using a Certificate file (and not a CSR)?
Ldap client will validade the server certificate, you should especify TLS_CACERT /to/file or TLS_REQCERT never on /etc/ldap/ldap.conf
You are right, I modified TLS_REQCERT in slapd conf but not on /etc/ldap/ldap.conf.
It works. Thank you everybody. I don't understand everything, especially the fact that gnutls-cli work so I'll try to reinstall all, and see if I'll find the same error.
-- Reinaldo de Carvalho http://korreio.sf.net http://python-cyrus.sf.net
"While not fully understand a software, don't try to adapt this software to the way you work, but rather yourself to the way the software works" (myself)
On 05/23/2011 08:39 AM, David Dumortier wrote:
Le sam. mai 21 2011 � 12:55:03 -0300, Reinaldo de Carvalho dit :
On Sat, May 21, 2011 at 12:04 PM, David Dumortierd.dumortier@free.fr wrote:
I suspect you are running ldap:// on port 636.
ldapsearch -W -H ldap://myip:636/ ldap_result: Can't contact LDAP server (-1)
No, -H ldaps://myip:636/ (to SSL/ldaps).
Tried it with same result :-(
You're really using a Certificate file (and not a CSR)?
Ldap client will validade the server certificate, you should especify TLS_CACERT /to/file or TLS_REQCERT never on /etc/ldap/ldap.conf
You are right, I modified TLS_REQCERT in slapd conf but not on /etc/ldap/ldap.conf.
I can not believe this. That's absolutely wrong. Why use certificates, when client is setup to ignore them? Correct solution is to add Your certificatin authority to trusted cert store. Since on debian, openldap is compiled with gnutls, this lines from manual apply: man ldap.conf:
TLS_CACERT <filename> Specifies the file that contains certificates for all of the Certificate Authorities the client will recognize. TLS_CACERTDIR <path> Specifies the path of a directory that contains Certifi‐ cate Authority certificates in separate individual files. The TLS_CACERT is always used before TLS_CACERTDIR. This parameter is ignored with GNUtls. On Debian openldap is linked against GNUtls.
So, just put Your authority cert to some file, point TLS_CACERT to it and it should work. One more thing, when using SSL/TLS it is necessary to use FQDN of the server, which must be same as CN of certificate. (or storing server's IP as CN, not too portable). so this is wrong: ldapsearch -W -H ldaps://192.168.0.1:636/ and this is correct: ldapsearch -W -H ldaps://myserver.mydomain.com:636/
I never tried using wildcard certs with LDAP, nor using SubjectAlternativeName field, but I have feeling that not all clients are capable of using it.
Setting TLS_REQCERT to never is only good for debugging, I discourage using it even for testing since You could end up with insecure installation. For production use TLS_REQCERT should be set to demand, otherwise there is no point in using certs - there is always MITM attack possibility (that is especially true, if password in clear text flows thru LDAP connections, which happens often when user changes his password).
Matej Zagiba
It works. Thank you everybody. I don't understand everything, especially the fact that gnutls-cli work so I'll try to reinstall all, and see if I'll find the same error.
Just a few lines added :
Le ven. mai 20 2011 � 11:50:05 +0200, David Dumortier dit :
Hi everybody,
I generated a self-signed certificate with these options : certtool --generate-privkey --outfile /etc/ldap/ssl/mykey.key certtool --generate-request --load-privkey /etc/ldap/ssl/mykey.key --outfile /etc/ldap/ssl/mycsr.csr
It is certtool --generate-self-signed otherwise slapd doesn't start
On Fri, May 20, 2011 at 6:50 AM, David Dumortier d.dumortier@free.fr wrote: [...]
I generated a self-signed certificate with these options : certtool --generate-privkey --outfile /etc/ldap/ssl/mykey.key certtool --generate-request --load-privkey /etc/ldap/ssl/mykey.key --outfile /etc/ldap/ssl/mycsr.csr
[..]
Here is my slapd conf : olcTLSVerifyClient: demand olcTLSCertificateFile: /etc/ldap/ssl/mycsr.csr olcTLSCertificateKeyFile: /etc/ldap/ssl/mykey.key
CSR = Certificate signing request [1]
# Create a private key and a self-signed certificate (public key inside). $ openssl req -x509 -newkey rsa:2048 -nodes -key Example_CA.key -out Example_CA.cer -days 7305
[1] http://en.wikipedia.org/wiki/Certificate_signing_request
Hello,
Le ven. mai 20 2011 � 02:43:46 -0300, Reinaldo de Carvalho dit :
On Fri, May 20, 2011 at 6:50 AM, David Dumortier d.dumortier@free.fr wrote: [...]
I generated a self-signed certificate with these options : certtool --generate-privkey --outfile /etc/ldap/ssl/mykey.key certtool --generate-request --load-privkey /etc/ldap/ssl/mykey.key --outfile /etc/ldap/ssl/mycsr.csr
[..]
Here is my slapd conf : olcTLSVerifyClient: demand olcTLSCertificateFile: /etc/ldap/ssl/mycsr.csr olcTLSCertificateKeyFile: /etc/ldap/ssl/mykey.key
CSR = Certificate signing request [1]
# Create a private key and a self-signed certificate (public key inside). $ openssl req -x509 -newkey rsa:2048 -nodes -key Example_CA.key -out Example_CA.cer -days 7305
As I mentioned it is a gnutls version of slapd (Debian specific compilation) As far as I know (I'm not a expert in certificat), the certtool option is --generate-self-signed to obtain the same result as your command. I start to believe I'll have to compile my own version of openldap with openSSL support :-)
[1] http://en.wikipedia.org/wiki/Certificate_signing_request
Thank you for the pointer I understand a little more certificates.
-- Reinaldo de Carvalho http://korreio.sf.net http://python-cyrus.sf.net
"While not fully understand a software, don't try to adapt this software to the way you work, but rather yourself to the way the software works" (myself)
Wise sentence :-)
openldap-technical@openldap.org
-
ben thielsen -
Buchan Milne -
David Dumortier -
Matej Zagiba -
Reinaldo de Carvalho