Hello,
After some time dealing with ldap and fedora, I'm stuck with an strange behaviour. I can successfully change the password for a certain user using the ldappasswd command, after this change (either done by the manager of the ldap or the same user) I can successfully ssh to the machine using this password. In this moment if I do slapcat I can see a password with this form:
e01ENX1pMjcvdjYyeEFvNmI4R212YUdQeDZ3PT0=
Instead if I change the password using the password command, I can see passwords much longer than the above one, this is what I can see after changing the passwd. e2NyeXB0fSQxJER1VDNiMEtQJE1GNmQ5UGo4YXhSQXp0RW9VNDVUNDA=
I configured the client to use ldap with this command: authconfig --enableforcelegacy --disablecachecreds --enableldap --enableldapauth --ldapserver=172.19.5.13 --ldapbasedn=dc=linux,dc=imppc,dc=org --disableldaptls --disablefingerprint --disablewinbind --disablewins --disablesssd --disablesssdauth --disablenis --enablecache --enablelocauthorize --usemd5 --updateall
This command takes care of all the pam.d files, and considering that the ssh does work with the password set by the ldappasswd command, where is the problem?
The server is an openldap-2.4.25.
Am I missing something? I though that it was perfectly possible to use passwd instead of ldappasswd. Any help will be extremely appreciated. Thanks a lot, j
Judith Flo Gaya wrote:
Hello,
After some time dealing with ldap and fedora, I'm stuck with an strange behaviour. I can successfully change the password for a certain user using the ldappasswd command, after this change (either done by the manager of the ldap or the same user) I can successfully ssh to the machine using this password. In this moment if I do slapcat I can see a password with this form:
e01ENX1pMjcvdjYyeEFvNmI4R212YUdQeDZ3PT0=
Instead if I change the password using the password command, I can see passwords much longer than the above one, this is what I can see after changing the passwd. e2NyeXB0fSQxJER1VDNiMEtQJE1GNmQ5UGo4YXhSQXp0RW9VNDVUNDA=
You use different password hash algos:
sh-3.2$ echo e01ENX1pMjcvdjYyeEFvNmI4R212YUdQeDZ3PT0= |base64 -d {MD5}i27/v62xAo6b8GmvaGPx6w==sh-3.2$
sh-3.2$ echo e2NyeXB0fSQxJER1VDNiMEtQJE1GNmQ5UGo4YXhSQXp0RW9VNDVUNDA= |base64 -d {crypt}$1$DuT3b0KP$MF6d9Pj8axRAztEoU45T40sh-3.2$
Maybe you should change to {SSHA}.
-- Regards Harry
On Tue, 5 Apr 2011, Judith Flo Gaya wrote:
[with ldappasswd I get]
e01ENX1pMjcvdjYyeEFvNmI4R212YUdQeDZ3PT0=
[but with passwd I get]
e2NyeXB0fSQxJER1VDNiMEtQJE1GNmQ5UGo4YXhSQXp0RW9VNDVUNDA=
[after running]
authconfig --enableforcelegacy --disablecachecreds --enableldap --enableldapauth --ldapserver=172.19.5.13 --ldapbasedn=dc=linux,dc=imppc,dc=org --disableldaptls --disablefingerprint --disablewinbind --disablewins --disablesssd --disablesssdauth --disablenis --enablecache --enablelocauthorize --usemd5 --updateall
This command takes care of all the pam.d files, and considering that the ssh does work with the password set by the ldappasswd command, where is the problem?
I find those hard to read, so:
$ echo e01ENX1pMjcvdjYyeEFvNmI4R212YUdQeDZ3PT0= | openssl enc -d -base64 {MD5}i27/v62xAo6b8GmvaGPx6w==
$ echo e2NyeXB0fSQxJER1VDNiMEtQJE1GNmQ5UGo4YXhSQXp0RW9VNDVUNDA= | openssl enc -d -base64 {crypt}$1$DuT3b0KP$MF6d9Pj8axRAztEoU45T40
So, with ldappasswd you're getting MD5 userPassword values (and you seem to be happy with that), but with passwd you're getting crypt userPassword values (which are not using the MD5 scheme you seem to be happy with).
With that in mind, I'd propose the command that "takes care of all the pam.d files" might not be as complete as you hoped. I'd check the "password" pam stack and make sure that it's configured to generate MD5 passwords or, much better yet, use the LDAP Password Modify operation just as your ldappasswd invocation does.
So your real question going forward is: I've got an OpenLDAP installation that happily uses the {MD5} scheme for userPassword attributes, how do I get passwd(1) to write into that format? The exact methods for this depend on your PAM stack and the available modules; you might be better off asking the Fedora community (assuming they provided you with this "authconfig" command) or the provider(s) of your PAM module(s) and/or your passwd(1) command.
Judith Flo Gaya jflo@imppc.org writes:
Hello,
After some time dealing with ldap and fedora, I'm stuck with an strange behaviour. I can successfully change the password for a certain user using the ldappasswd command, after this change (either done by the manager of the ldap or the same user) I can successfully ssh to the machine using this password. In this moment if I do slapcat I can see a password with this form:
e01ENX1pMjcvdjYyeEFvNmI4R212YUdQeDZ3PT0=
This is {MD5}i27/v62xAo6b8GmvaGPx6w==
Instead if I change the password using the password command, I can see passwords much longer than the above one, this is what I can see after changing the passwd. e2NyeXB0fSQxJER1VDNiMEtQJE1GNmQ5UGo4YXhSQXp0RW9VNDVUNDA=
and this is {crypt}$1$DuT3b0KP$MF6d9Pj8axRAztEoU45T40
That is, you are using different password hash methods
[...]
-Dieter
On 04/06/2011 02:44 PM, Aaron Richton wrote:
On Tue, 5 Apr 2011, Judith Flo Gaya wrote:
[with ldappasswd I get]
e01ENX1pMjcvdjYyeEFvNmI4R212YUdQeDZ3PT0=
[but with passwd I get]
e2NyeXB0fSQxJER1VDNiMEtQJE1GNmQ5UGo4YXhSQXp0RW9VNDVUNDA=
[after running]
authconfig --enableforcelegacy --disablecachecreds --enableldap --enableldapauth --ldapserver=172.19.5.13 --ldapbasedn=dc=linux,dc=imppc,dc=org --disableldaptls --disablefingerprint --disablewinbind --disablewins --disablesssd --disablesssdauth --disablenis --enablecache --enablelocauthorize --usemd5 --updateall
This command takes care of all the pam.d files, and considering that the ssh does work with the password set by the ldappasswd command, where is the problem?
I find those hard to read, so:
$ echo e01ENX1pMjcvdjYyeEFvNmI4R212YUdQeDZ3PT0= | openssl enc -d -base64 {MD5}i27/v62xAo6b8GmvaGPx6w==
$ echo e2NyeXB0fSQxJER1VDNiMEtQJE1GNmQ5UGo4YXhSQXp0RW9VNDVUNDA= | openssl enc -d -base64 {crypt}$1$DuT3b0KP$MF6d9Pj8axRAztEoU45T40
sorry, i should have provide them
So, with ldappasswd you're getting MD5 userPassword values (and you seem to be happy with that), but with passwd you're getting crypt userPassword values (which are not using the MD5 scheme you seem to be happy with).
With that in mind, I'd propose the command that "takes care of all the pam.d files" might not be as complete as you hoped. I'd check the "password" pam stack and make sure that it's configured to generate MD5 passwords or, much better yet, use the LDAP Password Modify operation just as your ldappasswd invocation does.
I did tried to add the md5 variable in the pam stack but unsuccessfully, I also tried to change the authconfig command to generate md5 passwords but they didn't fit the ones in the server. In the end I changed the pam_ldap.conf file with this line: pam_password exop and it worked although I'm not pretty sure what is this option doing (I'm reading the rfc now). I'm also considering changing the encryption in the server side to match this auth protocol.
So your real question going forward is: I've got an OpenLDAP installation that happily uses the {MD5} scheme for userPassword attributes, how do I get passwd(1) to write into that format? The exact methods for this depend on your PAM stack and the available modules; you might be better off asking the Fedora community (assuming they provided you with this "authconfig" command) or the provider(s) of your PAM module(s) and/or your passwd(1) command.
The command wasn't provided by the community, I was just exploring different options to configure the autentication on client side (in an scriptable way) and found this binary that changes all config files instead of editing them all one by one. But sure I can ask them.
Thanks a lot! j
Judith Flo Gaya wrote:
On 04/06/2011 02:44 PM, Aaron Richton wrote:
On Tue, 5 Apr 2011, Judith Flo Gaya wrote:
[with ldappasswd I get]
e01ENX1pMjcvdjYyeEFvNmI4R212YUdQeDZ3PT0=
[but with passwd I get]
e2NyeXB0fSQxJER1VDNiMEtQJE1GNmQ5UGo4YXhSQXp0RW9VNDVUNDA=
[after running]
authconfig --enableforcelegacy --disablecachecreds --enableldap --enableldapauth --ldapserver=172.19.5.13 --ldapbasedn=dc=linux,dc=imppc,dc=org --disableldaptls --disablefingerprint --disablewinbind --disablewins --disablesssd --disablesssdauth --disablenis --enablecache --enablelocauthorize --usemd5 --updateall
This command takes care of all the pam.d files, and considering that the ssh does work with the password set by the ldappasswd command, where is the problem?
I find those hard to read, so:
$ echo e01ENX1pMjcvdjYyeEFvNmI4R212YUdQeDZ3PT0= | openssl enc -d -base64 {MD5}i27/v62xAo6b8GmvaGPx6w==
$ echo e2NyeXB0fSQxJER1VDNiMEtQJE1GNmQ5UGo4YXhSQXp0RW9VNDVUNDA= | openssl enc -d -base64 {crypt}$1$DuT3b0KP$MF6d9Pj8axRAztEoU45T40
sorry, i should have provide them
So, with ldappasswd you're getting MD5 userPassword values (and you seem to be happy with that), but with passwd you're getting crypt userPassword values (which are not using the MD5 scheme you seem to be happy with).
With that in mind, I'd propose the command that "takes care of all the pam.d files" might not be as complete as you hoped. I'd check the "password" pam stack and make sure that it's configured to generate MD5 passwords or, much better yet, use the LDAP Password Modify operation just as your ldappasswd invocation does.
I did tried to add the md5 variable in the pam stack but unsuccessfully,
No, no, $1$ at the beginnig of the password hash indicates, crypt's implementation of md5. And this has nothing to do with MD5 hashes,
I also tried to change the authconfig command to generate md5 passwords but they didn't fit the ones in the server.
A common misunderstanding,
From "man slappasswd"
-c crypt-salt-format Specify the format of the salt passed to crypt(3) when generat‐ ing {CRYPT} passwords. This string needs to be in sprintf(3) format and may include one (and only one) %s conversion. This conversion will be substituted with a string random characters from [A-Za-z0-9./]. For example, ’%.2s’ provides a two charac‐ ter salt and ’$1$%.8s’ tells some versions of crypt(3) to use an MD5 algorithm and provides 8 random characters of salt. The default is ’%s’, which provides 31 characters of salt.
If you set in slapd.conf: password-crypt-salt-format '$1$%.8s'
then the password is stored in crypt's md5 format.
But normaly that is not what you want. Even with md5 is crypt much weaker then ssha. Only if you have really old unices in your network you should use crypt.
On 04/09/2011 05:23 PM, harry.jede@arcor.de wrote:
I find those hard to read, so:
$ echo e01ENX1pMjcvdjYyeEFvNmI4R212YUdQeDZ3PT0= | openssl enc -d -base64 {MD5}i27/v62xAo6b8GmvaGPx6w==
$ echo e2NyeXB0fSQxJER1VDNiMEtQJE1GNmQ5UGo4YXhSQXp0RW9VNDVUNDA= | openssl enc -d -base64 {crypt}$1$DuT3b0KP$MF6d9Pj8axRAztEoU45T40
I did tried to add the md5 variable in the pam stack but unsuccessfully,
No, no, $1$ at the beginnig of the password hash indicates, crypt's implementation of md5. And this has nothing to do with MD5 hashes,
Thanks for the clarification, didn't know it
I also tried to change the authconfig command to generate md5 passwords but they didn't fit the ones in the server.
A common misunderstanding,
From "man slappasswd"
-c crypt-salt-formatSpecify the format of the salt passed to crypt(3) when generat‐ ing {CRYPT} passwords. This string needs to be in sprintf(3) format and may include one (and only one) %s conversion. This conversion will be substituted with a string random characters from [A-Za-z0-9./]. For example, ’%.2s’ provides a two charac‐ ter salt and ’$1$%.8s’ tells some versions of crypt(3) to use an MD5 algorithm and provides 8 random characters of salt. The default is ’%s’, which provides 31 characters of salt.
If you set in slapd.conf: password-crypt-salt-format '$1$%.8s'
then the password is stored in crypt's md5 format.
But normaly that is not what you want. Even with md5 is crypt much weaker then ssha. Only if you have really old unices in your network you should use crypt.
considering your words I will go for ssha passwords, I'll try to figure out how to do it, after all tests I don't know how to change this. At least i could see that the password exop option in the pam_ldap.conf lets the server to apply the security to the password, so I think I can change it within the slapd.conf file. do you suggest to use salt?
Thanks a lot for your help, j
Judith Flo Gaya wrote: ...
At least i could see that the password exop option in the pam_ldap.conf lets the server to apply the security to the password, so I think I can change it within the slapd.conf file.
Yes, and if you don't specify "password-hash" in slapd.conf, ssha is used. It is the default.
do you suggest to use salt?
ssha use salt.
Thanks a lot for your help, j
BTW have you read rfc-3062 ? http://www.faqs.org/rfcs/rfc3062.html
If you configure your clients to use "password exop" you should be sure that the clients use any kind of network protection, TLS or SSL.
TinyCA is a perl based GTK-GUI which may help you to generate certs and keys.
Until you are ready to use TLS/SSL I sugggest that you let the client encrypt the passwords local.
Hello,
On 04/11/2011 01:14 PM, harry.jede@arcor.de wrote:
Judith Flo Gaya wrote: ...
At least i could see that the password exop option in the pam_ldap.conf lets the server to apply the security to the password, so I think I can change it within the slapd.conf file.
Yes, and if you don't specify "password-hash" in slapd.conf, ssha is used. It is the default.
do you suggest to use salt?
ssha use salt.
Thanks a lot for your help, j
BTW have you read rfc-3062 ? http://www.faqs.org/rfcs/rfc3062.html
If you configure your clients to use "password exop" you should be sure that the clients use any kind of network protection, TLS or SSL.
TinyCA is a perl based GTK-GUI which may help you to generate certs and keys.
Until you are ready to use TLS/SSL I sugggest that you let the client encrypt the passwords local.
As I didn't manage to make both client and server hash passwords in the same way, I start creating certificates for clients and servers, but for some reason they aren't able to comunicate. I test the certificate connection and the server answers properly (using openssl_client) both from client to server and from the server to the server. But when I do ldapsearch -x it says ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
In the logs of the server I can see this: slap_listener_activate(7):
slap_listener(ldaps:///)
connection_get(12): got connid=1077 connection_read(12): checking for input on id=1077 TLS trace: SSL_accept:before/accept initialization TLS: can't accept: (unknown). connection_read(12): TLS accept failure error=-1 id=1077, closing connection_close: conn=1077 sd=12
Any idea?
I created the certificates like this: # openssl genrsa 2048 > ca-key.pem # openssl req -new -x509 -nodes -days 1000 -key ca-key.pem > ca-cert.pem # openssl req -newkey rsa:2048 -days 1000 -nodes -keyout server-key.pem
server-req.pem
# openssl x509 -req -in server-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > server-cert.pem
This on the server side, then I scp the ca-cert.pem file to the client (and to the /etc/openldap/cacerts in the same server). For the client I created the certificate like this: # openssl req -newkey rsa:2048 -days 1000 -nodes -keyout client-key.pem
client-req.pem
# openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > client-cert.pem
And then copy those 3 files to the client.
I changed the slapd.conf to have the 3 tls variables with the generated files from the beginning and changed the configuration to connect to the ldaps://server and marked the tls option.
Any hint about the error?
Thanks in advance. j
SOrry I didn't attach the error that appears when the connection is made from another client: slap_listener_activate(7):
slap_listener(ldaps:///)
connection_get(12): got connid=1078 connection_read(12): checking for input on id=1078 TLS trace: SSL_accept:before/accept initialization TLS trace: SSL_accept:SSLv3 read client hello A TLS trace: SSL_accept:SSLv3 write server hello A TLS trace: SSL_accept:SSLv3 write certificate A TLS trace: SSL_accept:SSLv3 write server done A TLS trace: SSL_accept:SSLv3 flush data TLS trace: SSL_accept:error in SSLv3 read client certificate A TLS trace: SSL_accept:error in SSLv3 read client certificate A connection_get(12): got connid=1078 connection_read(12): checking for input on id=1078 TLS trace: SSL3 alert read:fatal:bad certificate TLS trace: SSL_accept:failed in SSLv3 read client certificate A TLS: can't accept: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate. connection_read(12): TLS accept failure error=-1 id=1078, closing connection_close: conn=1078 sd=12
the other one was when running an ldapsearch -x within the server itself.
Hope the information is good enough. Thanks, j
On 04/12/2011 05:33 PM, Judith Flo Gaya wrote:
Hello,
On 04/11/2011 01:14 PM, harry.jede@arcor.de wrote:
Judith Flo Gaya wrote: ...
At least i could see that the password exop option in the pam_ldap.conf lets the server to apply the security to the password, so I think I can change it within the slapd.conf file.
Yes, and if you don't specify "password-hash" in slapd.conf, ssha is used. It is the default.
do you suggest to use salt?
ssha use salt.
Thanks a lot for your help, j
BTW have you read rfc-3062 ? http://www.faqs.org/rfcs/rfc3062.html
If you configure your clients to use "password exop" you should be sure that the clients use any kind of network protection, TLS or SSL.
TinyCA is a perl based GTK-GUI which may help you to generate certs and keys.
Until you are ready to use TLS/SSL I sugggest that you let the client encrypt the passwords local.
As I didn't manage to make both client and server hash passwords in the same way, I start creating certificates for clients and servers, but for some reason they aren't able to comunicate. I test the certificate connection and the server answers properly (using openssl_client) both from client to server and from the server to the server. But when I do ldapsearch -x it says ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
In the logs of the server I can see this: slap_listener_activate(7):
slap_listener(ldaps:///)
connection_get(12): got connid=1077 connection_read(12): checking for input on id=1077 TLS trace: SSL_accept:before/accept initialization TLS: can't accept: (unknown). connection_read(12): TLS accept failure error=-1 id=1077, closing connection_close: conn=1077 sd=12
Any idea?
I created the certificates like this: # openssl genrsa 2048> ca-key.pem # openssl req -new -x509 -nodes -days 1000 -key ca-key.pem> ca-cert.pem # openssl req -newkey rsa:2048 -days 1000 -nodes -keyout server-key.pem
server-req.pem
# openssl x509 -req -in server-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01> server-cert.pem
This on the server side, then I scp the ca-cert.pem file to the client (and to the /etc/openldap/cacerts in the same server). For the client I created the certificate like this: # openssl req -newkey rsa:2048 -days 1000 -nodes -keyout client-key.pem
client-req.pem
# openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01> client-cert.pem
And then copy those 3 files to the client.
I changed the slapd.conf to have the 3 tls variables with the generated files from the beginning and changed the configuration to connect to the ldaps://server and marked the tls option.
Any hint about the error?
Thanks in advance. j
I'm posting all the information together in this e-mail, hope you can help me out, I'm quite desperate at this point.
Following your advise I tried to set TLS in my server and client. I generated the certificates for both client and server (self signed) and sent the cacert file from the server to the clients.
I started the server like this: /usr/local/libexec/slapd -u ldap -h ldaps://curri0.imppc.local:636 -f /usr/local/openldap-2.4.25/etc/openldap/slapd.conf -d 1
( I installed a newer version of openldap in my server as the RH6 uses an old one, I compiled it with tls and openssl)
From the client I do : ldapsearch -x -ZZ -d1 -h curri0.imppc.local:636 ldap_create ldap_url_parse_ext(ldap://curri0.imppc.local:636) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP curri0.imppc.local:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 172.19.5.13:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 3 ldap_result ld 0x1b4c170 msgid 1 wait4msg ld 0x1b4c170 msgid 1 (infinite timeout) wait4msg continue ld 0x1b4c170 msgid 1 all 1 ** ld 0x1b4c170 Connections: * host: curri0.imppc.local port: 636 (default) refcnt: 2 status: Connected last used: Tue Apr 12 18:56:35 2011
** ld 0x1b4c170 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x1b4c170 request count 1 (abandoned 0) ** ld 0x1b4c170 Response Queue: Empty ld 0x1b4c170 response count 0 ldap_chkResponseList ld 0x1b4c170 msgid 1 all 1 ldap_chkResponseList returns ld 0x1b4c170 NULL ldap_int_select read1msg: ld 0x1b4c170 msgid 1 all 1 ber_get_next ldap_err2string ldap_start_tls: Can't contact LDAP server (-1)
And the server shows this:
slap_listener_activate(8):
slap_listener(ldaps://curri0.imppc.local:636)
connection_get(12): got connid=1000 connection_read(12): checking for input on id=1000 TLS trace: SSL_accept:before/accept initialization TLS trace: SSL_accept:error in SSLv2/v3 read client hello A TLS: can't accept: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol. connection_read(12): TLS accept failure error=-1 id=1000, closing connection_close: conn=1000 sd=12
If I do this from the client or the server:
# openssl s_client -connect curri0.imppc.local:636 -showcerts CONNECTED(00000003) (...) verify return:1 --- Certificate chain 0 s:(...) -----BEGIN CERTIFICATE----- (...) -----END CERTIFICATE----- --- Server certificate subject=(...) --- No client certificate CA names sent --- SSL handshake has read 1254 bytes and written 439 bytes --- New, TLSv1/SSLv3, Cipher is AES256-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: zlib compression Expansion: zlib compression SSL-Session: Protocol : TLSv1 Cipher : AES256-SHA Session-ID: (...) Session-ID-ctx: Master-Key: (...) Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None TLS session ticket: (...)
Compression: 1 (zlib compression) Start Time: 1302627455 Timeout : 300 (sec) Verify return code: 18 (self signed certificate)
I get this on server:
slap_listener_activate(8):
slap_listener(ldaps://curri0.imppc.local:636)
connection_get(12): got connid=1002 connection_read(12): checking for input on id=1002 TLS trace: SSL_accept:before/accept initialization TLS trace: SSL_accept:SSLv3 read client hello A TLS trace: SSL_accept:SSLv3 write server hello A TLS trace: SSL_accept:SSLv3 write certificate A TLS trace: SSL_accept:SSLv3 write server done A TLS trace: SSL_accept:SSLv3 flush data TLS trace: SSL_accept:error in SSLv3 read client certificate A TLS trace: SSL_accept:error in SSLv3 read client certificate A connection_get(12): got connid=1002 connection_read(12): checking for input on id=1002 TLS trace: SSL_accept:SSLv3 read client key exchange A TLS trace: SSL_accept:SSLv3 read finished A TLS trace: SSL_accept:SSLv3 write session ticket A TLS trace: SSL_accept:SSLv3 write change cipher spec A TLS trace: SSL_accept:SSLv3 write finished A TLS trace: SSL_accept:SSLv3 flush data connection_read(12): unable to get TLS client DN, error=49 id=1002
I generated the certificates like this: # generate CA openssl genrsa 2048 > ca-key.pem # create certificate openssl req -new -x509 -nodes -days 1000 -key ca-key.pem > ca-cert.pem openssl req -newkey rsa:2048 -days 1000 -nodes -keyout server-key.pem > server-req.pem # self sign the cert openssl x509 -req -in server-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > server-cert.pem
#For the client: # create cert openssl req -newkey rsa:2048 -days 1000 -nodes -keyout client-key.pem > client-req.pem # sign cert openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > client-cert.pem
Here is my slapd.conf tls related
TLSCACertificateFile /usr/local/openldap-2.4.25/etc/openldap/imppccerts/ca-cert.pem TLSCertificateFile /usr/local/openldap-2.4.25/etc/openldap/imppccerts/server-cert.pem TLSCertificateKeyFile /usr/local/openldap-2.4.25/etc/openldap/imppccerts/server-key.pem
Am I missing something?
Thanks a lot in advance for any help, it is very appreciated. j
On 04/11/2011 01:14 PM, harry.jede@arcor.de wrote:
Judith Flo Gaya wrote: ...
At least i could see that the password exop option in the pam_ldap.conf lets the server to apply the security to the password, so I think I can change it within the slapd.conf file.
Yes, and if you don't specify "password-hash" in slapd.conf, ssha is used. It is the default.
do you suggest to use salt?
ssha use salt.
Thanks a lot for your help, j
BTW have you read rfc-3062 ? http://www.faqs.org/rfcs/rfc3062.html
If you configure your clients to use "password exop" you should be sure that the clients use any kind of network protection, TLS or SSL.
TinyCA is a perl based GTK-GUI which may help you to generate certs and keys.
Until you are ready to use TLS/SSL I sugggest that you let the client encrypt the passwords local.
--On Tuesday, April 12, 2011 7:10 PM +0200 Judith Flo Gaya jflo@imppc.org wrote:
I'm posting all the information together in this e-mail, hope you can help me out, I'm quite desperate at this point.
Following your advise I tried to set TLS in my server and client. I generated the certificates for both client and server (self signed) and sent the cacert file from the server to the clients.
I started the server like this: /usr/local/libexec/slapd -u ldap -h ldaps://curri0.imppc.local:636 -f /usr/local/openldap-2.4.25/etc/openldap/slapd.conf -d 1
( I installed a newer version of openldap in my server as the RH6 uses an old one, I compiled it with tls and openssl)
From the client I do : ldapsearch -x -ZZ -d1 -h curri0.imppc.local:636
This is a startTLS request. You are using LDAPS. This will never work.
Try
ldapsearch -x -H ldaps://curri0.imppc.local:636/
instead.
--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
Judith, you are starting the LDAP server as LDAPS (port 636) which doesn't accept START_TLS connections. What is in your /etc/ldap.conf and/or /etc/openldap/ldap.conf files (you may want to run 'find /etc /usr -name ldap.conf -print' in case your system has the ldap.conf file(s) somewhere else. In one (or more) of those files, you most likely have 'ssl start_tls' and this should be just 'ssl on'. Tom Leach leach@coas.oregonstate.edu
On 04/12/2011 10:10 AM, Judith Flo Gaya wrote:
I'm posting all the information together in this e-mail, hope you can help me out, I'm quite desperate at this point.
Following your advise I tried to set TLS in my server and client. I generated the certificates for both client and server (self signed) and sent the cacert file from the server to the clients.
I started the server like this: /usr/local/libexec/slapd -u ldap -h ldaps://curri0.imppc.local:636 -f /usr/local/openldap-2.4.25/etc/openldap/slapd.conf -d 1
( I installed a newer version of openldap in my server as the RH6 uses an old one, I compiled it with tls and openssl)
From the client I do : ldapsearch -x -ZZ -d1 -h curri0.imppc.local:636 ldap_create ldap_url_parse_ext(ldap://curri0.imppc.local:636) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP curri0.imppc.local:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 172.19.5.13:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 3 ldap_result ld 0x1b4c170 msgid 1 wait4msg ld 0x1b4c170 msgid 1 (infinite timeout) wait4msg continue ld 0x1b4c170 msgid 1 all 1 ** ld 0x1b4c170 Connections:
- host: curri0.imppc.local port: 636 (default) refcnt: 2 status: Connected last used: Tue Apr 12 18:56:35 2011
** ld 0x1b4c170 Outstanding Requests:
- msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0
ld 0x1b4c170 request count 1 (abandoned 0) ** ld 0x1b4c170 Response Queue: Empty ld 0x1b4c170 response count 0 ldap_chkResponseList ld 0x1b4c170 msgid 1 all 1 ldap_chkResponseList returns ld 0x1b4c170 NULL ldap_int_select read1msg: ld 0x1b4c170 msgid 1 all 1 ber_get_next ldap_err2string ldap_start_tls: Can't contact LDAP server (-1)
And the server shows this:
slap_listener_activate(8):
slap_listener(ldaps://curri0.imppc.local:636)
connection_get(12): got connid=1000 connection_read(12): checking for input on id=1000 TLS trace: SSL_accept:before/accept initialization TLS trace: SSL_accept:error in SSLv2/v3 read client hello A TLS: can't accept: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol. connection_read(12): TLS accept failure error=-1 id=1000, closing connection_close: conn=1000 sd=12
If I do this from the client or the server:
# openssl s_client -connect curri0.imppc.local:636 -showcerts CONNECTED(00000003) (...) verify return:1
Certificate chain 0 s:(...) -----BEGIN CERTIFICATE----- (...)
-----END CERTIFICATE-----
Server certificate subject=(...)
No client certificate CA names sent
SSL handshake has read 1254 bytes and written 439 bytes
New, TLSv1/SSLv3, Cipher is AES256-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: zlib compression Expansion: zlib compression SSL-Session: Protocol : TLSv1 Cipher : AES256-SHA Session-ID: (...) Session-ID-ctx: Master-Key: (...) Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None TLS session ticket: (...)
Compression: 1 (zlib compression) Start Time: 1302627455 Timeout : 300 (sec) Verify return code: 18 (self signed certificate)I get this on server:
slap_listener_activate(8):
slap_listener(ldaps://curri0.imppc.local:636)
connection_get(12): got connid=1002 connection_read(12): checking for input on id=1002 TLS trace: SSL_accept:before/accept initialization TLS trace: SSL_accept:SSLv3 read client hello A TLS trace: SSL_accept:SSLv3 write server hello A TLS trace: SSL_accept:SSLv3 write certificate A TLS trace: SSL_accept:SSLv3 write server done A TLS trace: SSL_accept:SSLv3 flush data TLS trace: SSL_accept:error in SSLv3 read client certificate A TLS trace: SSL_accept:error in SSLv3 read client certificate A connection_get(12): got connid=1002 connection_read(12): checking for input on id=1002 TLS trace: SSL_accept:SSLv3 read client key exchange A TLS trace: SSL_accept:SSLv3 read finished A TLS trace: SSL_accept:SSLv3 write session ticket A TLS trace: SSL_accept:SSLv3 write change cipher spec A TLS trace: SSL_accept:SSLv3 write finished A TLS trace: SSL_accept:SSLv3 flush data connection_read(12): unable to get TLS client DN, error=49 id=1002
I generated the certificates like this: # generate CA openssl genrsa 2048 > ca-key.pem # create certificate openssl req -new -x509 -nodes -days 1000 -key ca-key.pem > ca-cert.pem openssl req -newkey rsa:2048 -days 1000 -nodes -keyout server-key.pem > server-req.pem # self sign the cert openssl x509 -req -in server-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > server-cert.pem
#For the client: # create cert openssl req -newkey rsa:2048 -days 1000 -nodes -keyout client-key.pem > client-req.pem # sign cert openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > client-cert.pem
Here is my slapd.conf tls related
TLSCACertificateFile /usr/local/openldap-2.4.25/etc/openldap/imppccerts/ca-cert.pem TLSCertificateFile /usr/local/openldap-2.4.25/etc/openldap/imppccerts/server-cert.pem TLSCertificateKeyFile /usr/local/openldap-2.4.25/etc/openldap/imppccerts/server-key.pem
Am I missing something?
Thanks a lot in advance for any help, it is very appreciated. j
On 04/11/2011 01:14 PM, harry.jede@arcor.de wrote:
Judith Flo Gaya wrote: ...
At least i could see that the password exop option in the pam_ldap.conf lets the server to apply the security to the password, so I think I can change it within the slapd.conf file.
Yes, and if you don't specify "password-hash" in slapd.conf, ssha is used. It is the default.
do you suggest to use salt?
ssha use salt.
Thanks a lot for your help, j
BTW have you read rfc-3062 ? http://www.faqs.org/rfcs/rfc3062.html
If you configure your clients to use "password exop" you should be sure that the clients use any kind of network protection, TLS or SSL.
TinyCA is a perl based GTK-GUI which may help you to generate certs and keys.
Until you are ready to use TLS/SSL I sugggest that you let the client encrypt the passwords local.
Hello Quanah,
On 4/12/11 7:28 PM, Quanah Gibson-Mount wrote:
--On Tuesday, April 12, 2011 7:10 PM +0200 Judith Flo Gayajflo@imppc.org wrote:
( I installed a newer version of openldap in my server as the RH6 uses an old one, I compiled it with tls and openssl)
From the client I do : ldapsearch -x -ZZ -d1 -h curri0.imppc.local:636
This is a startTLS request. You are using LDAPS. This will never work.
Try
ldapsearch -x -H ldaps://curri0.imppc.local:636/
It doesn't work either, still complains about not being able to contact the server. But now I see a different error:
ldapsearch -x -H ldaps://curri0.imppc.local:636 -d1 ldap_url_parse_ext(ldaps://curri0.imppc.local:636) ldap_create ldap_url_parse_ext(ldaps://curri0.imppc.local:636/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP curri0.imppc.local:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 172.19.5.13:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 TLS: could not initialize moznss using security dir /etc/openldap/cacerts - error -8174:Unknown code ___f 18. TLS: could not add the certificate (null) - error -8192:Unknown code ___f 0. TLS: error: connect - force handshake failure -1 - error -8054:Unknown code ___f 138 TLS: can't connect: . ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
and this is what the server says: slap_listener_activate(8):
slap_listener(ldaps://curri0.imppc.local:636)
connection_get(12): got connid=1008 connection_read(12): checking for input on id=1008 TLS trace: SSL_accept:before/accept initialization TLS trace: SSL_accept:SSLv3 read client hello A TLS trace: SSL_accept:SSLv3 write server hello A TLS trace: SSL_accept:SSLv3 write certificate A TLS trace: SSL_accept:SSLv3 write server done A TLS trace: SSL_accept:SSLv3 flush data TLS trace: SSL_accept:error in SSLv3 read client certificate A TLS trace: SSL_accept:error in SSLv3 read client certificate A connection_get(12): got connid=1008 connection_read(12): checking for input on id=1008 TLS trace: SSL3 alert read:fatal:bad certificate TLS trace: SSL_accept:failed in SSLv3 read client certificate A TLS: can't accept: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate. connection_read(12): TLS accept failure error=-1 id=1008, closing connection_close: conn=1008 sd=12
any clue? the error on the client side seems to indicate that the client is trying to use the nss from the mozilla but I never meant to this, openssl is installed. Thanks a lot for your help. j
instead.
--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
Hello Tom,
Thanks for your answer.
On 4/12/11 7:29 PM, Tom Leach wrote:
Judith, you are starting the LDAP server as LDAPS (port 636) which doesn't accept START_TLS connections. What is in your /etc/ldap.conf and/or /etc/openldap/ldap.conf files (you may want to run 'find /etc /usr -name ldap.conf -print' in case your system has the ldap.conf file(s) somewhere else.
on the server (RHEL6) side the /etc/openldap/ldap.conf says: # LDAP Defaults #
# See ldap.conf(5) for details # This file should be world readable but not world writable.
BASE dc=linux,dc=imppc,dc=org URI ldaps://curri0.imppc.local
#SIZELIMIT 12 #TIMELIMIT 15 #DEREF never #TLS_CACERTDIR /etc/openldap/cacerts #tls_cacertfile $TLS_CACERTDIR/curri0-client-cert.pem TLS_CACERTDIR /etc/openldap/cacerts
(indeed the certificates are there) there is also another ldap.conf unser /usr/local/openldap-2.4.25/etc/openldap/ldap.conf but I assume that in order to use it being a client, it will use the one from the system, right?
On the rest of the clients (fedora 14) there are two "ldap" files, /etc/openldap/ldap.conf and /etc/pam_ldap.conf the first says: # # LDAP Defaults #
# See ldap.conf(5) for details # This file should be world readable but not world writable.
#BASE dc=example,dc=com #URI ldap://ldap.example.com ldap://ldap-master.example.com:666
#SIZELIMIT 12 #TIMELIMIT 15 #DEREF never TLS_CACERTDIR /etc/openldap/cacerts URI ldaps://curri0.imppc.local BASE dc=linux,dc=imppc,dc=org TLS_REQCERT demand
and pam_ldap.conf # This is the configuration file for the LDAP nameservice # switch library and the LDAP PAM module. # # The man page for this file is pam_ldap(5) # # PADL Software # http://www.padl.com #
# Your LDAP server. Must be resolvable without using LDAP. # Multiple hosts may be specified, each separated by a # space. How long nss_ldap takes to failover depends on # whether your LDAP client library supports configurable # network or connect timeouts (see bind_timelimit). #host 127.0.0.1
# The distinguished name of the search base. base dc=linux,dc=imppc,dc=org
# Another way to specify your LDAP server is to provide an # uri with the server name. This allows to use # Unix Domain Sockets to connect to a local LDAP Server. #uri ldap://127.0.0.1/ #uri ldaps://127.0.0.1/ #uri ldapi://%2fvar%2frun%2fldapi_sock/ # Note: %2f encodes the '/' used as directory separator
# The LDAP version to use (defaults to 3 # if supported by client library) #ldap_version 3
# The distinguished name to bind to the server with. # Optional: default is to bind anonymously. #binddn cn=proxyuser,dc=example,dc=com
# The credentials to bind with. # Optional: default is no credential. #bindpw secret
# The distinguished name to bind to the server with # if the effective user ID is root. Password is # stored in /etc/ldap.secret (mode 600) #rootbinddn cn=manager,dc=example,dc=com
# The port. # Optional: default is 389. #port 389
# The search scope. #scope sub #scope one #scope base
# Search timelimit #timelimit 30
# Bind/connect timelimit #bind_timelimit 30
# Reconnect policy: hard (default) will retry connecting to # the software with exponential backoff, soft will fail # immediately. #bind_policy hard
# Idle timelimit; client will close connections # (nss_ldap only) if the server has not been contacted # for the number of seconds specified below. #idle_timelimit 3600
# Filter to AND with uid=%s #pam_filter objectclass=account
# The user ID attribute (defaults to uid) #pam_login_attribute uid
# Search the root DSE for the password policy (works # with Netscape Directory Server) #pam_lookup_policy yes
# Check the 'host' attribute for access control # Default is no; if set to yes, and user has no # value for the host attribute, and pam_ldap is # configured for account management (authorization) # then the user will not be allowed to login. #pam_check_host_attr yes
# Check the 'authorizedService' attribute for access # control # Default is no; if set to yes, and the user has no # value for the authorizedService attribute, and # pam_ldap is configured for account management # (authorization) then the user will not be allowed # to login. #pam_check_service_attr yes
# Group to enforce membership of #pam_groupdn cn=PAM,ou=Groups,dc=example,dc=com
# Group member attribute #pam_member_attribute uniquemember
# Specify a minium or maximum UID number allowed #pam_min_uid 0 #pam_max_uid 0
# Template login attribute, default template user # (can be overriden by value of former attribute # in user's entry) #pam_login_attribute userPrincipalName #pam_template_login_attribute uid #pam_template_login nobody
# HEADS UP: the pam_crypt, pam_nds_passwd, # and pam_ad_passwd options are no # longer supported. # # Do not hash the password at all; presume # the directory server will do it, if # necessary. This is the default. #pam_password clear
# Hash password locally; required for University of # Michigan LDAP server, and works with Netscape # Directory Server if you're using the UNIX-Crypt # hash mechanism and not using the NT Synchronization # service. #pam_password crypt
# Remove old password first, then update in # cleartext. Necessary for use with Novell # Directory Services (NDS) #pam_password clear_remove_old #pam_password nds
# RACF is an alias for the above. For use with # IBM RACF #pam_password racf
# Update Active Directory password, by # creating Unicode password and updating # unicodePwd attribute. pam_password ad
# Use the OpenLDAP password change # extended operation to update the password. #pam_password exop
# Redirect users to a URL or somesuch on password # changes. #pam_password_prohibit_message Please visit http://internal to change your password.
# RFC2307bis naming contexts # Syntax: # nss_base_XXX base?scope?filter # where scope is {base,one,sub} # and filter is a filter to be &'d with the # default filter. # You can omit the suffix eg: # nss_base_passwd ou=People, # to append the default base DN but this # may incur a small performance impact. #nss_base_passwd ou=People,dc=example,dc=com?one #nss_base_shadow ou=People,dc=example,dc=com?one #nss_base_group ou=Group,dc=example,dc=com?one #nss_base_hosts ou=Hosts,dc=example,dc=com?one #nss_base_services ou=Services,dc=example,dc=com?one #nss_base_networks ou=Networks,dc=example,dc=com?one #nss_base_protocols ou=Protocols,dc=example,dc=com?one #nss_base_rpc ou=Rpc,dc=example,dc=com?one #nss_base_ethers ou=Ethers,dc=example,dc=com?one #nss_base_netmasks ou=Networks,dc=example,dc=com?ne #nss_base_bootparams ou=Ethers,dc=example,dc=com?one #nss_base_aliases ou=Aliases,dc=example,dc=com?one #nss_base_netgroup ou=Netgroup,dc=example,dc=com?one
# attribute/objectclass mapping # Syntax: #nss_map_attribute rfc2307attribute mapped_attribute #nss_map_objectclass rfc2307objectclass mapped_objectclass
# configure --enable-nds is no longer supported. # NDS mappings #nss_map_attribute uniqueMember member
# Services for UNIX 3.5 mappings #nss_map_objectclass posixAccount User #nss_map_objectclass shadowAccount User #nss_map_attribute uid msSFU30Name #nss_map_attribute uniqueMember msSFU30PosixMember #nss_map_attribute userPassword msSFU30Password #nss_map_attribute homeDirectory msSFU30HomeDirectory #nss_map_attribute homeDirectory msSFUHomeDirectory #nss_map_objectclass posixGroup Group #pam_login_attribute msSFU30Name #pam_filter objectclass=User #pam_password ad
# configure --enable-mssfu-schema is no longer supported. # Services for UNIX 2.0 mappings #nss_map_objectclass posixAccount User #nss_map_objectclass shadowAccount user #nss_map_attribute uid msSFUName #nss_map_attribute uniqueMember posixMember #nss_map_attribute userPassword msSFUPassword #nss_map_attribute homeDirectory msSFUHomeDirectory #nss_map_attribute shadowLastChange pwdLastSet #nss_map_objectclass posixGroup Group #nss_map_attribute cn msSFUName #pam_login_attribute msSFUName #pam_filter objectclass=User #pam_password ad
# RFC 2307 (AD) mappings #nss_map_objectclass posixAccount user #nss_map_objectclass shadowAccount user #nss_map_attribute uid sAMAccountName #nss_map_attribute homeDirectory unixHomeDirectory #nss_map_attribute shadowLastChange pwdLastSet #nss_map_objectclass posixGroup group #nss_map_attribute uniqueMember member #pam_login_attribute sAMAccountName #pam_filter objectclass=User #pam_password ad
# configure --enable-authpassword is no longer supported # AuthPassword mappings #nss_map_attribute userPassword authPassword
# AIX SecureWay mappings #nss_map_objectclass posixAccount aixAccount #nss_base_passwd ou=aixaccount,?one #nss_map_attribute uid userName #nss_map_attribute gidNumber gid #nss_map_attribute uidNumber uid #nss_map_attribute userPassword passwordChar #nss_map_objectclass posixGroup aixAccessGroup #nss_base_group ou=aixgroup,?one #nss_map_attribute cn groupName #nss_map_attribute uniqueMember member #pam_login_attribute userName #pam_filter objectclass=aixAccount #pam_password clear
# Netscape SDK LDAPS #ssl on
# Netscape SDK SSL options #sslpath /etc/ssl/certs
# OpenLDAP SSL mechanism # start_tls mechanism uses the normal LDAP port, LDAPS typically 636 #ssl start_tls #ssl on
# OpenLDAP SSL options # Require and verify server certificate (yes/no) # Default is to use libldap's default behavior, which can be configured in # /etc/openldap/ldap.conf using the TLS_REQCERT setting. The default for # OpenLDAP 2.0 and earlier is "no", for 2.1 and later is "yes". tls_checkpeer yes
# CA certificates for server certificate verification # At least one of these are required if tls_checkpeer is "yes" #tls_cacertfile /etc/ssl/ca.cert #tls_cacertdir /etc/ssl/certs
# Seed the PRNG if /dev/urandom is not provided #tls_randfile /var/run/egd-pool
# SSL cipher suite # See man ciphers for syntax #tls_ciphers TLSv1
# Client certificate and key # Use these, if your server requires client authentication. #tls_cert #tls_key
# Disable SASL security layers. This is needed for AD. #sasl_secprops maxssf=0
# Override the default Kerberos ticket cache location. #krb5_ccname FILE:/etc/.ldapcache # SASL mechanism for PAM authentication - use is experimental # at present and does not support password policy control #pam_sasl_mech DIGEST-MD5 uri ldaps://curri0.imppc.local ssl on #ssl start_tls tls_cacertdir /etc/openldap/cacerts pam_password md5
In one (or more) of those files, you most likely have 'ssl start_tls' and this should be just 'ssl on'.
As you can see I made the change you suggest without best luck ;( althought doing this changes, now I face this new error.. # ldapsearch -x -d 1 ldap_create ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP curri0.imppc.local:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 172.19.5.13:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 TLS: could not initialize moznss using security dir /etc/openldap/cacerts - error -8174:Unknown code ___f 18. TLS: could not add the certificate (null) - error -8192:Unknown code ___f 0. TLS: error: connect - force handshake failure -1 - error -8054:Unknown code ___f 138 TLS: can't connect: . ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
Does this shed some light? it is strange that the client tries to use the mozilla nss because openssl is already installed on the system: # rpm -qa|grep openssl openssl-devel-1.0.0a-2.fc14.x86_64 openssl-1.0.0a-2.fc14.x86_64
Is there any way to tell the system not to use the moznss libraries? the certificates were created using openssl commands, so maybe that's the reason for this new error..
Thanks a lot one more time, j
Tom Leach leach@coas.oregonstate.edu
On 04/12/2011 10:10 AM, Judith Flo Gaya wrote:
I'm posting all the information together in this e-mail, hope you can help me out, I'm quite desperate at this point.
Following your advise I tried to set TLS in my server and client. I generated the certificates for both client and server (self signed) and sent the cacert file from the server to the clients.
I started the server like this: /usr/local/libexec/slapd -u ldap -h ldaps://curri0.imppc.local:636 -f /usr/local/openldap-2.4.25/etc/openldap/slapd.conf -d 1
( I installed a newer version of openldap in my server as the RH6 uses an old one, I compiled it with tls and openssl)
From the client I do : ldapsearch -x -ZZ -d1 -h curri0.imppc.local:636 ldap_create ldap_url_parse_ext(ldap://curri0.imppc.local:636) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP curri0.imppc.local:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 172.19.5.13:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 3 ldap_result ld 0x1b4c170 msgid 1 wait4msg ld 0x1b4c170 msgid 1 (infinite timeout) wait4msg continue ld 0x1b4c170 msgid 1 all 1 ** ld 0x1b4c170 Connections:
- host: curri0.imppc.local port: 636 (default) refcnt: 2 status: Connected last used: Tue Apr 12 18:56:35 2011
** ld 0x1b4c170 Outstanding Requests:
- msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0
ld 0x1b4c170 request count 1 (abandoned 0) ** ld 0x1b4c170 Response Queue: Empty ld 0x1b4c170 response count 0 ldap_chkResponseList ld 0x1b4c170 msgid 1 all 1 ldap_chkResponseList returns ld 0x1b4c170 NULL ldap_int_select read1msg: ld 0x1b4c170 msgid 1 all 1 ber_get_next ldap_err2string ldap_start_tls: Can't contact LDAP server (-1)
And the server shows this:
slap_listener_activate(8):
slap_listener(ldaps://curri0.imppc.local:636)
connection_get(12): got connid=1000 connection_read(12): checking for input on id=1000 TLS trace: SSL_accept:before/accept initialization TLS trace: SSL_accept:error in SSLv2/v3 read client hello A TLS: can't accept: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol. connection_read(12): TLS accept failure error=-1 id=1000, closing connection_close: conn=1000 sd=12
If I do this from the client or the server:
# openssl s_client -connect curri0.imppc.local:636 -showcerts CONNECTED(00000003) (...) verify return:1
Certificate chain 0 s:(...) -----BEGIN CERTIFICATE----- (...)
-----END CERTIFICATE-----
Server certificate subject=(...)
No client certificate CA names sent
SSL handshake has read 1254 bytes and written 439 bytes
New, TLSv1/SSLv3, Cipher is AES256-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: zlib compression Expansion: zlib compression SSL-Session: Protocol : TLSv1 Cipher : AES256-SHA Session-ID: (...) Session-ID-ctx: Master-Key: (...) Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None TLS session ticket: (...)
Compression: 1 (zlib compression) Start Time: 1302627455 Timeout : 300 (sec) Verify return code: 18 (self signed certificate)I get this on server:
slap_listener_activate(8):
slap_listener(ldaps://curri0.imppc.local:636)
connection_get(12): got connid=1002 connection_read(12): checking for input on id=1002 TLS trace: SSL_accept:before/accept initialization TLS trace: SSL_accept:SSLv3 read client hello A TLS trace: SSL_accept:SSLv3 write server hello A TLS trace: SSL_accept:SSLv3 write certificate A TLS trace: SSL_accept:SSLv3 write server done A TLS trace: SSL_accept:SSLv3 flush data TLS trace: SSL_accept:error in SSLv3 read client certificate A TLS trace: SSL_accept:error in SSLv3 read client certificate A connection_get(12): got connid=1002 connection_read(12): checking for input on id=1002 TLS trace: SSL_accept:SSLv3 read client key exchange A TLS trace: SSL_accept:SSLv3 read finished A TLS trace: SSL_accept:SSLv3 write session ticket A TLS trace: SSL_accept:SSLv3 write change cipher spec A TLS trace: SSL_accept:SSLv3 write finished A TLS trace: SSL_accept:SSLv3 flush data connection_read(12): unable to get TLS client DN, error=49 id=1002
I generated the certificates like this: # generate CA openssl genrsa 2048> ca-key.pem # create certificate openssl req -new -x509 -nodes -days 1000 -key ca-key.pem> ca-cert.pem openssl req -newkey rsa:2048 -days 1000 -nodes -keyout server-key.pem> server-req.pem # self sign the cert openssl x509 -req -in server-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01> server-cert.pem
#For the client: # create cert openssl req -newkey rsa:2048 -days 1000 -nodes -keyout client-key.pem> client-req.pem # sign cert openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01> client-cert.pem
Here is my slapd.conf tls related
TLSCACertificateFile /usr/local/openldap-2.4.25/etc/openldap/imppccerts/ca-cert.pem TLSCertificateFile /usr/local/openldap-2.4.25/etc/openldap/imppccerts/server-cert.pem TLSCertificateKeyFile /usr/local/openldap-2.4.25/etc/openldap/imppccerts/server-key.pem
Am I missing something?
Thanks a lot in advance for any help, it is very appreciated. j
On 04/11/2011 01:14 PM, harry.jede@arcor.de wrote:
Judith Flo Gaya wrote: ...
At least i could see that the password exop option in the pam_ldap.conf lets the server to apply the security to the password, so I think I can change it within the slapd.conf file.
Yes, and if you don't specify "password-hash" in slapd.conf, ssha is used. It is the default.
do you suggest to use salt?
ssha use salt.
Thanks a lot for your help, j
BTW have you read rfc-3062 ? http://www.faqs.org/rfcs/rfc3062.html
If you configure your clients to use "password exop" you should be sure that the clients use any kind of network protection, TLS or SSL.
TinyCA is a perl based GTK-GUI which may help you to generate certs and keys.
Until you are ready to use TLS/SSL I sugggest that you let the client encrypt the passwords local.
--On Tuesday, April 12, 2011 9:14 PM +0200 Judith Flo Gaya jflo@imppc.org wrote:
Hello Quanah,
ldap_pvt_connect: fd: 3 tm: -1 async: 0 TLS: could not initialize moznss using security dir /etc/openldap/cacerts
It sounds to me like you linked it against MozNSS instead of OpenSSL. I would suggest you rebuild it with --with-tls=openssl
--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
--On Tuesday, April 12, 2011 9:50 PM +0200 Judith Flo Gaya jflo@imppc.org wrote:
I'm using the default version of openldap for the clients : openldap-2.4.22-7.fc14.x86_64 openldap-devel-2.4.22-7.fc14.x86_64 openldap-clients-2.4.22-7.fc14.x86_64
I don't exactly know how to check the way they are compiled..
Use "ldd" on the binary. If they are compiled against MozNSS, you'll probably have better success using your own built binaries against OpenSSL.
--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
On 04/12/2011 01:14 PM, Judith Flo Gaya wrote:
Hello Quanah,
On 4/12/11 7:28 PM, Quanah Gibson-Mount wrote:
--On Tuesday, April 12, 2011 7:10 PM +0200 Judith Flo Gayajflo@imppc.org wrote:
( I installed a newer version of openldap in my server as the RH6 uses an old one, I compiled it with tls and openssl)
From the client I do : ldapsearch -x -ZZ -d1 -h curri0.imppc.local:636
This is a startTLS request. You are using LDAPS. This will never work.
Try
ldapsearch -x -H ldaps://curri0.imppc.local:636/
It doesn't work either, still complains about not being able to contact the server. But now I see a different error:
ldapsearch -x -H ldaps://curri0.imppc.local:636 -d1 ldap_url_parse_ext(ldaps://curri0.imppc.local:636) ldap_create ldap_url_parse_ext(ldaps://curri0.imppc.local:636/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP curri0.imppc.local:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 172.19.5.13:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 TLS: could not initialize moznss using security dir /etc/openldap/cacerts - error -8174:Unknown code ___f 18. TLS: could not add the certificate (null) - error -8192:Unknown code ___f 0. TLS: error: connect - force handshake failure -1 - error -8054:Unknown code ___f 138 TLS: can't connect: . ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
If you are using /usr/bin/ldapsearch on Fedora 14 and later, it is linked with Mozilla NSS instead of openssl. But openldap with moznss works the same as it does with openssl.
Do you have your CA cert on the client machine? If so, did you specify it in /etc/openldap/ldap.conf or ~/.ldaprc? If not, you can also specify it on the command line like this:
LDAPTLS_CACERT=/path/to/ca_cert.pem ldapsearch -x -H ldaps://curri0.imppc.local:636/
See http://www.openldap.org/faq/data/cache/1514.html for information about how to use Mozilla NSS.
and this is what the server says: slap_listener_activate(8):
slap_listener(ldaps://curri0.imppc.local:636)
connection_get(12): got connid=1008 connection_read(12): checking for input on id=1008 TLS trace: SSL_accept:before/accept initialization TLS trace: SSL_accept:SSLv3 read client hello A TLS trace: SSL_accept:SSLv3 write server hello A TLS trace: SSL_accept:SSLv3 write certificate A TLS trace: SSL_accept:SSLv3 write server done A TLS trace: SSL_accept:SSLv3 flush data TLS trace: SSL_accept:error in SSLv3 read client certificate A TLS trace: SSL_accept:error in SSLv3 read client certificate A connection_get(12): got connid=1008 connection_read(12): checking for input on id=1008 TLS trace: SSL3 alert read:fatal:bad certificate TLS trace: SSL_accept:failed in SSLv3 read client certificate A TLS: can't accept: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate. connection_read(12): TLS accept failure error=-1 id=1008, closing connection_close: conn=1008 sd=12
any clue? the error on the client side seems to indicate that the client is trying to use the nss from the mozilla but I never meant to this, openssl is installed. Thanks a lot for your help. j
instead.
--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
T
On 4/12/11 9:33 PM, Quanah Gibson-Mount wrote:
--On Tuesday, April 12, 2011 9:14 PM +0200 Judith Flo Gayajflo@imppc.org wrote:
ldap_pvt_connect: fd: 3 tm: -1 async: 0 TLS: could not initialize moznss using security dir /etc/openldap/cacerts
It sounds to me like you linked it against MozNSS instead of OpenSSL. I would suggest you rebuild it with --with-tls=openssl
That is how I build the server, (from the installation config.log) $ ./configure --prefix=/usr/local/openldap-2.4.25 --enable-slapd --enable-bdb --with-tls=openssl
I'm using the default version of openldap for the clients : openldap-2.4.22-7.fc14.x86_64 openldap-devel-2.4.22-7.fc14.x86_64 openldap-clients-2.4.22-7.fc14.x86_64
I don't exactly know how to check the way they are compiled.. j
--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
I changed the ldap.conf file in the client so instead of TLS_CACERTDIR now I'm using TLC_CACERT <file.pem> and the error now is this one: # ldapsearch -x -d1 #it's the same error if I set -H server ldap_create ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP curri0.imppc.local:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 172.19.5.13:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 TLS: error: connect - force handshake failure -1 - error -8054:Unknown code ___f 138 TLS: can't connect: . ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
and the server says: slap_listener_activate(8):
slap_listener(ldaps://curri0.imppc.local:636)
connection_get(12): got connid=1034 connection_read(12): checking for input on id=1034 TLS trace: SSL_accept:before/accept initialization TLS trace: SSL_accept:SSLv3 read client hello A TLS trace: SSL_accept:SSLv3 write server hello A TLS trace: SSL_accept:SSLv3 write certificate A TLS trace: SSL_accept:SSLv3 write server done A TLS trace: SSL_accept:SSLv3 flush data TLS trace: SSL_accept:error in SSLv3 read client certificate A TLS trace: SSL_accept:error in SSLv3 read client certificate A connection_get(12): got connid=1034 connection_read(12): checking for input on id=1034 TLS trace: SSL3 alert read:fatal:bad certificate TLS trace: SSL_accept:failed in SSLv3 read client certificate A TLS: can't accept: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate. connection_read(12): TLS accept failure error=-1 id=1034, closing connection_close: conn=1034 sd=12
I can't understand why the server complains about a bad certificate, when the client certificate was generated there :O by the openssl libraries.
As said, thanks a lot for your time, j
On 4/12/11 9:33 PM, Quanah Gibson-Mount wrote:
--On Tuesday, April 12, 2011 9:14 PM +0200 Judith Flo Gayajflo@imppc.org wrote:
Hello Quanah, ldap_pvt_connect: fd: 3 tm: -1 async: 0 TLS: could not initialize moznss using security dir /etc/openldap/cacerts
It sounds to me like you linked it against MozNSS instead of OpenSSL. I would suggest you rebuild it with --with-tls=openssl
--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
On 4/12/11 9:44 PM, Quanah Gibson-Mount wrote:
--On Tuesday, April 12, 2011 9:50 PM +0200 Judith Flo Gayajflo@imppc.org wrote:
I'm using the default version of openldap for the clients : openldap-2.4.22-7.fc14.x86_64 openldap-devel-2.4.22-7.fc14.x86_64 openldap-clients-2.4.22-7.fc14.x86_64
I don't exactly know how to check the way they are compiled..
Use "ldd" on the binary. If they are compiled against MozNSS, you'll probably have better success using your own built binaries against OpenSSL.
This is the result # ldd /usr/bin/ldapsearch linux-vdso.so.1 => (0x00007fff71dff000) libldap-2.4.so.2 => /usr/lib64/libldap-2.4.so.2 (0x000000303a400000) liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 (0x000000303ac00000) libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x0000003038000000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x0000003033a00000) libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003023a00000) libssl3.so => /usr/lib64/libssl3.so (0x0000003036a00000) libsmime3.so => /usr/lib64/libsmime3.so (0x0000003036e00000) libnss3.so => /usr/lib64/libnss3.so (0x0000003035200000) libnssutil3.so => /usr/lib64/libnssutil3.so (0x0000003036200000) libplds4.so => /lib64/libplds4.so (0x0000003035a00000) libplc4.so => /lib64/libplc4.so (0x0000003034e00000) libnspr4.so => /lib64/libnspr4.so (0x0000003035e00000) libc.so.6 => /lib64/libc.so.6 (0x0000003021a00000) libdl.so.2 => /lib64/libdl.so.2 (0x0000003022200000) libfreebl3.so => /lib64/libfreebl3.so (0x0000003033e00000) libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003022600000) libz.so.1 => /lib64/libz.so.1 (0x0000003023200000) /lib64/ld-linux-x86-64.so.2 (0x0000003021200000)
As I see libssl3.so... I would say that openssl is used... # rpm -qf /usr/lib64/libnss3.so nss-3.12.7-6.fc14.x86_64 # rpm -qf /usr/lib64/libnssutil3.so nss-util-3.12.7-2.fc14.x86_64
j
--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
--On Tuesday, April 12, 2011 10:02 PM +0200 Judith Flo Gaya jflo@imppc.org wrote:
This is the result # ldd /usr/bin/ldapsearch linux-vdso.so.1 => (0x00007fff71dff000) libldap-2.4.so.2 => /usr/lib64/libldap-2.4.so.2 (0x000000303a400000) liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 (0x000000303ac00000) libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x0000003038000000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x0000003033a00000) libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003023a00000) libssl3.so => /usr/lib64/libssl3.so (0x0000003036a00000) libsmime3.so => /usr/lib64/libsmime3.so (0x0000003036e00000) libnss3.so => /usr/lib64/libnss3.so (0x0000003035200000) libnssutil3.so => /usr/lib64/libnssutil3.so (0x0000003036200000) libplds4.so => /lib64/libplds4.so (0x0000003035a00000) libplc4.so => /lib64/libplc4.so (0x0000003034e00000) libnspr4.so => /lib64/libnspr4.so (0x0000003035e00000) libc.so.6 => /lib64/libc.so.6 (0x0000003021a00000) libdl.so.2 => /lib64/libdl.so.2 (0x0000003022200000) libfreebl3.so => /lib64/libfreebl3.so (0x0000003033e00000) libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003022600000) libz.so.1 => /lib64/libz.so.1 (0x0000003023200000) /lib64/ld-linux-x86-64.so.2 (0x0000003021200000)
As I see libssl3.so... I would say that openssl is used...
Wrong. That's the NSS library.
--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
On 4/12/11 9:49 PM, Rich Megginson wrote:
If you are using /usr/bin/ldapsearch on Fedora 14 and later, it is linked with Mozilla NSS instead of openssl. But openldap with moznss works the same as it does with openssl.
so certificates generated by openssl should work with this settings?
Do you have your CA cert on the client machine?
I copied the ca-cert.pem from the server machine to the client, along with the certificate that I generate for the client itself. I thought that it was this last certificate the one that I should place in the TLS_CACERT (ldap.conf) not the general one.
If so, did you specify it in /etc/openldap/ldap.conf or ~/.ldaprc? If not, you can also specify it on the command line like this:
LDAPTLS_CACERT=/path/to/ca_cert.pem ldapsearch -x -H ldaps://curri0.imppc.local:636/
I made the test and still it does not work ;( # LDAPTLS_CACERT=/etc/openldap/cacerts/ca-cert.pem ldapsearch -x -H ldaps://curri0.imppc.local:636/ -d 1 ldap_url_parse_ext(ldaps://curri0.imppc.local:636/) ldap_create ldap_url_parse_ext(ldaps://curri0.imppc.local:636/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP curri0.imppc.local:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 172.19.5.13:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 TLS certificate verification: subject: -unknown-, issuer: -unknown-, cipher: -unknown-, security level: off, secret key bits: 0, total key bits: 0, cache hits: 0, cache misses: 0, cache not reusable: 0 TLS certificate verification: bad TLS certificate verification: Error, -8182: Unknown code ___f 10 TLS: error: connect - force handshake failure -1 - error -8182:Unknown code ___f 10 TLS: can't connect: . ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
It seems that it doesn't like the certificate.
On the server side it is finally working :) the problem is that all clients are f14
See http://www.openldap.org/faq/data/cache/1514.html for information about how to use Mozilla NSS.
I'll have a look, otherwise, I may compile openldap for the clients and the change all binaries so that they use "my versions of openldap" with openssl instead of the mozz ones... It looks a little mess though ;(
and this is what the server says: slap_listener_activate(8):
slap_listener(ldaps://curri0.imppc.local:636)
connection_get(12): got connid=1008 connection_read(12): checking for input on id=1008 TLS trace: SSL_accept:before/accept initialization TLS trace: SSL_accept:SSLv3 read client hello A TLS trace: SSL_accept:SSLv3 write server hello A TLS trace: SSL_accept:SSLv3 write certificate A TLS trace: SSL_accept:SSLv3 write server done A TLS trace: SSL_accept:SSLv3 flush data TLS trace: SSL_accept:error in SSLv3 read client certificate A TLS trace: SSL_accept:error in SSLv3 read client certificate A connection_get(12): got connid=1008 connection_read(12): checking for input on id=1008 TLS trace: SSL3 alert read:fatal:bad certificate TLS trace: SSL_accept:failed in SSLv3 read client certificate A TLS: can't accept: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate. connection_read(12): TLS accept failure error=-1 id=1008, closing connection_close: conn=1008 sd=12
any clue? the error on the client side seems to indicate that the client is trying to use the nss from the mozilla but I never meant to this, openssl is installed. Thanks a lot for your help. j
instead.
--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
--On Tuesday, April 12, 2011 9:57 PM +0200 Judith Flo Gaya jflo@imppc.org wrote:
I changed the ldap.conf file in the client so instead of TLS_CACERTDIR now I'm using TLC_CACERT <file.pem>
MozNSS can't use pem files. It uses a cert database. So your MozNSS linked clients will never work if you point them at a OpenSSL style pem file.
--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
On 04/12/2011 02:18 PM, Judith Flo Gaya wrote:
On 4/12/11 9:49 PM, Rich Megginson wrote:
If you are using /usr/bin/ldapsearch on Fedora 14 and later, it is linked with Mozilla NSS instead of openssl. But openldap with moznss works the same as it does with openssl.
so certificates generated by openssl should work with this settings?
Yes.
Do you have your CA cert on the client machine?
I copied the ca-cert.pem from the server machine to the client,
Ok.
along with the certificate that I generate for the client itself.
Not sure what you mean by this.
I thought that it was this last certificate the one that I should place in the TLS_CACERT (ldap.conf) not the general one.
Not sure what you mean by this. TLS_CACERT must be the certificate of the CA that issued the server cert.
If so, did you specify it in /etc/openldap/ldap.conf or ~/.ldaprc? If not, you can also specify it on the command line like this:
LDAPTLS_CACERT=/path/to/ca_cert.pem ldapsearch -x -H ldaps://curri0.imppc.local:636/
I made the test and still it does not work ;( # LDAPTLS_CACERT=/etc/openldap/cacerts/ca-cert.pem ldapsearch -x -H ldaps://curri0.imppc.local:636/ -d 1 ldap_url_parse_ext(ldaps://curri0.imppc.local:636/) ldap_create ldap_url_parse_ext(ldaps://curri0.imppc.local:636/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP curri0.imppc.local:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 172.19.5.13:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 TLS certificate verification: subject: -unknown-, issuer: -unknown-, cipher: -unknown-, security level: off, secret key bits: 0, total key bits: 0, cache hits: 0, cache misses: 0, cache not reusable: 0 TLS certificate verification: bad TLS certificate verification: Error, -8182: Unknown code ___f 10 TLS: error: connect - force handshake failure -1 - error -8182:Unknown code ___f 10 TLS: can't connect: . ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
It seems that it doesn't like the certificate.
-8182 is SEC_ERROR_BAD_SIGNATURE. During the TLS/SSL handshake, the client tries to see if the server's cert is correctly signed by the CA cert (the local ca-cert.pem).
On the server side it is finally working :) the problem is that all clients are f14
See http://www.openldap.org/faq/data/cache/1514.html for information about how to use Mozilla NSS.
I'll have a look, otherwise, I may compile openldap for the clients and the change all binaries so that they use "my versions of openldap" with openssl instead of the mozz ones... It looks a little mess though ;(
and this is what the server says: slap_listener_activate(8):
slap_listener(ldaps://curri0.imppc.local:636)
connection_get(12): got connid=1008 connection_read(12): checking for input on id=1008 TLS trace: SSL_accept:before/accept initialization TLS trace: SSL_accept:SSLv3 read client hello A TLS trace: SSL_accept:SSLv3 write server hello A TLS trace: SSL_accept:SSLv3 write certificate A TLS trace: SSL_accept:SSLv3 write server done A TLS trace: SSL_accept:SSLv3 flush data TLS trace: SSL_accept:error in SSLv3 read client certificate A TLS trace: SSL_accept:error in SSLv3 read client certificate A connection_get(12): got connid=1008 connection_read(12): checking for input on id=1008 TLS trace: SSL3 alert read:fatal:bad certificate TLS trace: SSL_accept:failed in SSLv3 read client certificate A TLS: can't accept: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate. connection_read(12): TLS accept failure error=-1 id=1008, closing connection_close: conn=1008 sd=12
any clue? the error on the client side seems to indicate that the client is trying to use the nss from the mozilla but I never meant to this, openssl is installed. Thanks a lot for your help. j
instead.
--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
On 04/12/2011 02:20 PM, Quanah Gibson-Mount wrote:
--On Tuesday, April 12, 2011 9:57 PM +0200 Judith Flo Gaya jflo@imppc.org wrote:
I changed the ldap.conf file in the client so instead of TLS_CACERTDIR now I'm using TLC_CACERT <file.pem>
MozNSS can't use pem files. It uses a cert database. So your MozNSS linked clients will never work if you point them at a OpenSSL style pem file.
It can and does use PEM files. Everything in http://www.openldap.org/faq/data/cache/185.html also applies to using openldap with Mozilla NSS.
Note that http://www.openldap.org/faq/index.cgi?file=1514 describes how to use openldap with the native MozNSS key/cert database. It works with both PEM files and key/cert dbs.
--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
On 4/12/11 9:49 PM, Rich Megginson wrote:
If you are using /usr/bin/ldapsearch on Fedora 14 and later, it is linked with Mozilla NSS instead of openssl. But openldap with moznss works the same as it does with openssl.
so certificates generated by openssl should work with this settings?
Yes.
Do you have your CA cert on the client machine?
I copied the ca-cert.pem from the server machine to the client,
Ok.
along with the certificate that I generate for the client itself.
Not sure what you mean by this.
I created a certificate for the client, signed by the server, I thought that the procedure of the certificate file wasn't only about creating a ca-cert.pem file and propagate it trought all clients, but create a certificate for each client signed by the same ca-cert. I don't know if I made myself clear, I followed (between others) this howto: http://www.openldap.org/pub/ksoper/OpenLDAP_TLS.html look at pint 4.3, it creates a certificate file for each client, isn't it? maybe i didn't understand it quite well
I thought that it was this last certificate the one that I should place in the TLS_CACERT (ldap.conf) not the general one.
Not sure what you mean by this. TLS_CACERT must be the certificate of the CA that issued the server cert.
If so, did you specify it in /etc/openldap/ldap.conf or ~/.ldaprc? If not, you can also specify it on the command line like this:
LDAPTLS_CACERT=/path/to/ca_cert.pem ldapsearch -x -H ldaps://curri0.imppc.local:636/
I made the test and still it does not work ;( # LDAPTLS_CACERT=/etc/openldap/cacerts/ca-cert.pem ldapsearch -x -H ldaps://curri0.imppc.local:636/ -d 1 ldap_url_parse_ext(ldaps://curri0.imppc.local:636/) ldap_create ldap_url_parse_ext(ldaps://curri0.imppc.local:636/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP curri0.imppc.local:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 172.19.5.13:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 TLS certificate verification: subject: -unknown-, issuer: -unknown-, cipher: -unknown-, security level: off, secret key bits: 0, total key bits: 0, cache hits: 0, cache misses: 0, cache not reusable: 0 TLS certificate verification: bad TLS certificate verification: Error, -8182: Unknown code ___f 10 TLS: error: connect - force handshake failure -1 - error -8182:Unknown code ___f 10 TLS: can't connect: . ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
It seems that it doesn't like the certificate.
-8182 is SEC_ERROR_BAD_SIGNATURE. During the TLS/SSL handshake, the client tries to see if the server's cert is correctly signed by the CA cert (the local ca-cert.pem).
the server says:
slap_listener_activate(8):
slap_listener(ldaps://curri0.imppc.local:636)
connection_get(12): got connid=1023 connection_read(12): checking for input on id=1023 TLS trace: SSL_accept:before/accept initialization TLS trace: SSL_accept:SSLv3 read client hello A TLS trace: SSL_accept:SSLv3 write server hello A TLS trace: SSL_accept:SSLv3 write certificate A TLS trace: SSL_accept:SSLv3 write server done A TLS trace: SSL_accept:SSLv3 flush data TLS trace: SSL_accept:error in SSLv3 read client certificate A TLS trace: SSL_accept:error in SSLv3 read client certificate A connection_get(12): got connid=1023 connection_read(12): checking for input on id=1023 TLS trace: SSL3 alert read:fatal:bad certificate TLS trace: SSL_accept:failed in SSLv3 read client certificate A TLS: can't accept: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate. connection_read(12): TLS accept failure error=-1 id=1023, closing connection_close: conn=1023 sd=12
I assure you that both ca-cert.pem files from server and client are the sames, as I create it and send it throught scp.. j
On 04/12/2011 03:01 PM, Judith Flo Gaya wrote:
On 4/12/11 9:49 PM, Rich Megginson wrote:
If you are using /usr/bin/ldapsearch on Fedora 14 and later, it is linked with Mozilla NSS instead of openssl. But openldap with moznss works the same as it does with openssl.
so certificates generated by openssl should work with this settings?
Yes.
Do you have your CA cert on the client machine?
I copied the ca-cert.pem from the server machine to the client,
Ok.
along with the certificate that I generate for the client itself.
Not sure what you mean by this.
I created a certificate for the client, signed by the server, I thought that the procedure of the certificate file wasn't only about creating a ca-cert.pem file and propagate it trought all clients, but create a certificate for each client signed by the same ca-cert. I don't know if I made myself clear, I followed (between others) this howto: http://www.openldap.org/pub/ksoper/OpenLDAP_TLS.html look at pint 4.3, it creates a certificate file for each client, isn't it? maybe i didn't understand it quite well
Yes. Looks like it creates client (i.e user) certificates.
I'm not sure what the problem is. If you think the problem is with moznss, find an ldapsearch client built with openssl (Fedora 13 or earlier if you have access).
I thought that it was this last certificate the one that I should place in the TLS_CACERT (ldap.conf) not the general one.
Not sure what you mean by this. TLS_CACERT must be the certificate of the CA that issued the server cert.
If so, did you specify it in /etc/openldap/ldap.conf or ~/.ldaprc? If not, you can also specify it on the command line like this:
LDAPTLS_CACERT=/path/to/ca_cert.pem ldapsearch -x -H ldaps://curri0.imppc.local:636/
I made the test and still it does not work ;( # LDAPTLS_CACERT=/etc/openldap/cacerts/ca-cert.pem ldapsearch -x -H ldaps://curri0.imppc.local:636/ -d 1 ldap_url_parse_ext(ldaps://curri0.imppc.local:636/) ldap_create ldap_url_parse_ext(ldaps://curri0.imppc.local:636/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP curri0.imppc.local:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 172.19.5.13:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 TLS certificate verification: subject: -unknown-, issuer: -unknown-, cipher: -unknown-, security level: off, secret key bits: 0, total key bits: 0, cache hits: 0, cache misses: 0, cache not reusable: 0 TLS certificate verification: bad TLS certificate verification: Error, -8182: Unknown code ___f 10 TLS: error: connect - force handshake failure -1 - error -8182:Unknown code ___f 10 TLS: can't connect: . ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
It seems that it doesn't like the certificate.
-8182 is SEC_ERROR_BAD_SIGNATURE. During the TLS/SSL handshake, the client tries to see if the server's cert is correctly signed by the CA cert (the local ca-cert.pem).
the server says:
slap_listener_activate(8):
slap_listener(ldaps://curri0.imppc.local:636)
connection_get(12): got connid=1023 connection_read(12): checking for input on id=1023 TLS trace: SSL_accept:before/accept initialization TLS trace: SSL_accept:SSLv3 read client hello A TLS trace: SSL_accept:SSLv3 write server hello A TLS trace: SSL_accept:SSLv3 write certificate A TLS trace: SSL_accept:SSLv3 write server done A TLS trace: SSL_accept:SSLv3 flush data TLS trace: SSL_accept:error in SSLv3 read client certificate A TLS trace: SSL_accept:error in SSLv3 read client certificate A connection_get(12): got connid=1023 connection_read(12): checking for input on id=1023 TLS trace: SSL3 alert read:fatal:bad certificate TLS trace: SSL_accept:failed in SSLv3 read client certificate A TLS: can't accept: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate. connection_read(12): TLS accept failure error=-1 id=1023, closing connection_close: conn=1023 sd=12
I assure you that both ca-cert.pem files from server and client are the sames, as I create it and send it throught scp.. j
Hello again,
On 4/12/11 10:20 PM, Quanah Gibson-Mount wrote:
--On Tuesday, April 12, 2011 9:57 PM +0200 Judith Flo Gayajflo@imppc.org wrote:
I changed the ldap.conf file in the client so instead of TLS_CACERTDIR now I'm using TLC_CACERT<file.pem>
MozNSS can't use pem files. It uses a cert database. So your MozNSS linked clients will never work if you point them at a OpenSSL style pem file.
aparently they should be able to work, according to what Rich Meggison sent me: http://www.openldap.org/faq/data/cache/1514.html I'm reading a little but i'm also compiling openldap in the client side so that it works with-tls=openssl and then remove the openldap rpm packages or have them available in the path before the previous ones.
Thank you one more time. j
--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
Hello both,
Finally I compiled and linked all binaries so that they can be found in the path before the installed ones. In the ldap.conf file for the client I set TLS_CACERT to the certificate that I create for the client in the server and it worked. So, now ldapsearch does work, but looks like the local auth system is unable to query for users... when I set the authconfig, the server says:
slap_listener(ldaps://curri0.imppc.local:636)
connection_get(12): got connid=1097 (this number keeps growing) connection_read(12): checking for input on id=1097 TLS trace: SSL_accept:before/accept initialization TLS: can't accept: (unknown). connection_read(12): TLS accept failure error=-1 id=1097, closing connection_close: conn=1097 sd=12
many times. Without TLS it did work before, also it has something to do with the new installation of the openldap... Thanks for all your help, j
On 4/12/11 11:01 PM, Rich Megginson wrote:
On 04/12/2011 03:01 PM, Judith Flo Gaya wrote:
On 4/12/11 9:49 PM, Rich Megginson wrote:
If you are using /usr/bin/ldapsearch on Fedora 14 and later, it is linked with Mozilla NSS instead of openssl. But openldap with moznss works the same as it does with openssl.
so certificates generated by openssl should work with this settings?
Yes.
Do you have your CA cert on the client machine?
I copied the ca-cert.pem from the server machine to the client,
Ok.
along with the certificate that I generate for the client itself.
Not sure what you mean by this.
I created a certificate for the client, signed by the server, I thought that the procedure of the certificate file wasn't only about creating a ca-cert.pem file and propagate it trought all clients, but create a certificate for each client signed by the same ca-cert. I don't know if I made myself clear, I followed (between others) this howto: http://www.openldap.org/pub/ksoper/OpenLDAP_TLS.html look at pint 4.3, it creates a certificate file for each client, isn't it? maybe i didn't understand it quite well
Yes. Looks like it creates client (i.e user) certificates.
I'm not sure what the problem is. If you think the problem is with moznss, find an ldapsearch client built with openssl (Fedora 13 or earlier if you have access).
I thought that it was this last certificate the one that I should place in the TLS_CACERT (ldap.conf) not the general one.
Not sure what you mean by this. TLS_CACERT must be the certificate of the CA that issued the server cert.
If so, did you specify it in /etc/openldap/ldap.conf or ~/.ldaprc? If not, you can also specify it on the command line like this:
LDAPTLS_CACERT=/path/to/ca_cert.pem ldapsearch -x -H ldaps://curri0.imppc.local:636/
I made the test and still it does not work ;( # LDAPTLS_CACERT=/etc/openldap/cacerts/ca-cert.pem ldapsearch -x -H ldaps://curri0.imppc.local:636/ -d 1 ldap_url_parse_ext(ldaps://curri0.imppc.local:636/) ldap_create ldap_url_parse_ext(ldaps://curri0.imppc.local:636/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP curri0.imppc.local:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 172.19.5.13:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 TLS certificate verification: subject: -unknown-, issuer: -unknown-, cipher: -unknown-, security level: off, secret key bits: 0, total key bits: 0, cache hits: 0, cache misses: 0, cache not reusable: 0 TLS certificate verification: bad TLS certificate verification: Error, -8182: Unknown code ___f 10 TLS: error: connect - force handshake failure -1 - error -8182:Unknown code ___f 10 TLS: can't connect: . ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
It seems that it doesn't like the certificate.
-8182 is SEC_ERROR_BAD_SIGNATURE. During the TLS/SSL handshake, the client tries to see if the server's cert is correctly signed by the CA cert (the local ca-cert.pem).
the server says:
slap_listener_activate(8):
slap_listener(ldaps://curri0.imppc.local:636)
connection_get(12): got connid=1023 connection_read(12): checking for input on id=1023 TLS trace: SSL_accept:before/accept initialization TLS trace: SSL_accept:SSLv3 read client hello A TLS trace: SSL_accept:SSLv3 write server hello A TLS trace: SSL_accept:SSLv3 write certificate A TLS trace: SSL_accept:SSLv3 write server done A TLS trace: SSL_accept:SSLv3 flush data TLS trace: SSL_accept:error in SSLv3 read client certificate A TLS trace: SSL_accept:error in SSLv3 read client certificate A connection_get(12): got connid=1023 connection_read(12): checking for input on id=1023 TLS trace: SSL3 alert read:fatal:bad certificate TLS trace: SSL_accept:failed in SSLv3 read client certificate A TLS: can't accept: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate. connection_read(12): TLS accept failure error=-1 id=1023, closing connection_close: conn=1023 sd=12
I assure you that both ca-cert.pem files from server and client are the sames, as I create it and send it throught scp.. j
Judith Flo Gaya wrote:
On 4/12/11 9:44 PM, Quanah Gibson-Mount wrote:
--On Tuesday, April 12, 2011 9:50 PM +0200 Judith Flo Gayajflo@imppc.org
wrote:
I'm using the default version of openldap for the clients : openldap-2.4.22-7.fc14.x86_64 openldap-devel-2.4.22-7.fc14.x86_64 openldap-clients-2.4.22-7.fc14.x86_64
What means this?
Are you using these packages on Client-PCs? Do you also use these packages on your openldap server?
I don't exactly know how to check the way they are compiled..
Use "ldd" on the binary. If they are compiled against MozNSS, you'll probably have better success using your own built binaries against OpenSSL.
And don't forget: you should never never mix (openldap) packages from two different builds on one machine. Such a setup can work well, but it is for power users :-) .
I have no experience with fedora, so I can not really help you. But in general, you may do it like this:
1. Check the packages meta information to find from which source package they are build. 2. Download these source packages 3. Downlod the developer packages which are needed to build your package 4. Download the openssl developer package 5. Change the config from moznss to openssl 6. Build the new packages 7. Test them on one or two machines 8. Distribute them to all your Fedora machines
This is the result # ldd /usr/bin/ldapsearch linux-vdso.so.1 => (0x00007fff71dff000) libldap-2.4.so.2 => /usr/lib64/libldap-2.4.so.2 (0x000000303a400000) liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 (0x000000303ac00000) libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x0000003038000000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x0000003033a00000) libresolv.so.2 => /lib64/libresolv.so.2
(0x0000003023a00000) libssl3.so => /usr/lib64/libssl3.so
May be this is a mozilla ssl library.
an openssl library looks so: libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0x00007f48c1dc4000)
this is a gnutls library: libgnutls.so.26 => /usr/lib/libgnutls.so.26 (0x00007f6a525ce000)
(0x0000003036a00000) libsmime3.so => /usr/lib64/libsmime3.so (0x0000003036e00000) libnss3.so => /usr/lib64/libnss3.so (0x0000003035200000) libnssutil3.so => /usr/lib64/libnssutil3.so (0x0000003036200000) libplds4.so => /lib64/libplds4.so (0x0000003035a00000) libplc4.so => /lib64/libplc4.so (0x0000003034e00000) libnspr4.so => /lib64/libnspr4.so (0x0000003035e00000) libc.so.6 => /lib64/libc.so.6 (0x0000003021a00000) libdl.so.2 => /lib64/libdl.so.2 (0x0000003022200000) libfreebl3.so => /lib64/libfreebl3.so (0x0000003033e00000) libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003022600000) libz.so.1 => /lib64/libz.so.1 (0x0000003023200000) /lib64/ld-linux-x86-64.so.2 (0x0000003021200000)
As I see libssl3.so... I would say that openssl is used... # rpm -qf /usr/lib64/libnss3.so nss-3.12.7-6.fc14.x86_64 # rpm -qf /usr/lib64/libnssutil3.so nss-util-3.12.7-2.fc14.x86_64
j
--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
Hi Harry,
On 04/13/2011 09:06 AM, harry.jede@arcor.de wrote:
Judith Flo Gaya wrote:
On 4/12/11 9:44 PM, Quanah Gibson-Mount wrote:
--On Tuesday, April 12, 2011 9:50 PM +0200 Judith Flo Gayajflo@imppc.org
wrote:
I'm using the default version of openldap for the clients : openldap-2.4.22-7.fc14.x86_64 openldap-devel-2.4.22-7.fc14.x86_64 openldap-clients-2.4.22-7.fc14.x86_64
What means this?
Are you using these packages on Client-PCs?
a priori I was doing it, now I compiled from source the same version of openldap, so now both server and clients have the same openldap
Do you also use these packages on your openldap server?
The versions on the server side were old and I was suggested to update to a newer version, so I compiled it.
I don't exactly know how to check the way they are compiled..
Use "ldd" on the binary. If they are compiled against MozNSS, you'll probably have better success using your own built binaries against OpenSSL.
And don't forget: you should never never mix (openldap) packages from two different builds on one machine. Such a setup can work well, but it is for power users :-) .
Yes, my idea was to get rid of the rpm packages after installing the source one, but I can get rid of the openldap-$version because it has plenty of dependencies, so I linked to /usr/local so that libraries and binaries can be found by the system before the rpm ones. One of the packages that uses these libraries is nss_pam_ldapd, maybe that's why now the ldapsearch is working but the authentication is not
I can't do id <user>, it complains about a TLS negotiation problem : Apr 13 09:55:25 curri0 slapd[2025]: conn=1063 fd=39 ACCEPT from IP=<client_ip>:44725 (IP=0.0.0.0:636) Apr 13 09:55:25 curri0 slapd[2025]: conn=1063 fd=39 closed (TLS negotiation failure) Apr 13 09:55:25 curri0 slapd[2025]: connection_read(39): no connection! Apr 13 09:55:25 curri0 slapd[2025]: connection_read(39): no connection!
I have no experience with fedora, so I can not really help you. But in general, you may do it like this:
- Check the packages meta information to find from which source package
they are build. 2. Download these source packages 3. Downlod the developer packages which are needed to build your package 4. Download the openssl developer package 5. Change the config from moznss to openssl 6. Build the new packages 7. Test them on one or two machines 8. Distribute them to all your Fedora machines
The devel packages and the openssl were already installed and the make depend worked without problem, so I only download, configure (with-tls=openssl) and installed this newer version, but still it doesn't work ;( I'll try to link the ldap libraries under /usr/lib64 to the new ones and see if I can fool the system to use mines.
I'm told that I can also manage to make the openldap rpm version that uses the moznss library to accept a .pem file, I thought that in this way it would be much easier, but now I'm no longer sure...
Thanks for your help! j
This is the result # ldd /usr/bin/ldapsearch linux-vdso.so.1 => (0x00007fff71dff000) libldap-2.4.so.2 => /usr/lib64/libldap-2.4.so.2 (0x000000303a400000) liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 (0x000000303ac00000) libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x0000003038000000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x0000003033a00000) libresolv.so.2 => /lib64/libresolv.so.2
(0x0000003023a00000) libssl3.so => /usr/lib64/libssl3.so
May be this is a mozilla ssl library.
an openssl library looks so: libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0x00007f48c1dc4000)
this is a gnutls library: libgnutls.so.26 => /usr/lib/libgnutls.so.26 (0x00007f6a525ce000)
(0x0000003036a00000) libsmime3.so => /usr/lib64/libsmime3.so (0x0000003036e00000) libnss3.so => /usr/lib64/libnss3.so (0x0000003035200000) libnssutil3.so => /usr/lib64/libnssutil3.so (0x0000003036200000) libplds4.so => /lib64/libplds4.so (0x0000003035a00000) libplc4.so => /lib64/libplc4.so (0x0000003034e00000) libnspr4.so => /lib64/libnspr4.so (0x0000003035e00000) libc.so.6 => /lib64/libc.so.6 (0x0000003021a00000) libdl.so.2 => /lib64/libdl.so.2 (0x0000003022200000) libfreebl3.so => /lib64/libfreebl3.so (0x0000003033e00000) libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003022600000) libz.so.1 => /lib64/libz.so.1 (0x0000003023200000) /lib64/ld-linux-x86-64.so.2 (0x0000003021200000)
As I see libssl3.so... I would say that openssl is used... # rpm -qf /usr/lib64/libnss3.so nss-3.12.7-6.fc14.x86_64 # rpm -qf /usr/lib64/libnssutil3.so nss-util-3.12.7-2.fc14.x86_64
j
--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
Judith Flo Gaya wrote:
Hi Harry,
On 04/13/2011 09:06 AM, harry.jede@arcor.de wrote:
Judith Flo Gaya wrote:
On 4/12/11 9:44 PM, Quanah Gibson-Mount wrote:
--On Tuesday, April 12, 2011 9:50 PM +0200 Judith Flo Gayajflo@imppc.org
wrote:
I'm using the default version of openldap for the clients : openldap-2.4.22-7.fc14.x86_64 openldap-devel-2.4.22-7.fc14.x86_64 openldap-clients-2.4.22-7.fc14.x86_64
What means this?
Are you using these packages on Client-PCs?
a priori I was doing it, now I compiled from source the same version of openldap, so now both server and clients have the same openldap
fine
Do you also use these packages on your openldap server?
The versions on the server side were old and I was suggested to update to a newer version, so I compiled it.
I don't exactly know how to check the way they are compiled..
Use "ldd" on the binary. If they are compiled against MozNSS, you'll probably have better success using your own built binaries against OpenSSL.
And don't forget: you should never never mix (openldap) packages from two different builds on one machine. Such a setup can work well, but it is for power users :-) .
Yes, my idea was to get rid of the rpm packages after installing the source one, but I can get rid of the openldap-$version because it has plenty of dependencies, so I linked to /usr/local so that libraries and binaries can be found by the system before the rpm ones. One of the packages that uses these libraries is nss_pam_ldapd, maybe that's why now the ldapsearch is working but the authentication is not
ldapsearch works now with TLS and/or SSL. That's also fine.
I can't do id <user>, it complains about a TLS negotiation problem : Apr 13 09:55:25 curri0 slapd[2025]: conn=1063 fd=39 ACCEPT from IP=<client_ip>:44725 (IP=0.0.0.0:636) Apr 13 09:55:25 curri0 slapd[2025]: conn=1063 fd=39 closed (TLS negotiation failure) Apr 13 09:55:25 curri0 slapd[2025]: connection_read(39): no connection! Apr 13 09:55:25 curri0 slapd[2025]: connection_read(39): no connection!
So, the nss_pam_ldapd needs also recompiling !?
I have no experience with fedora, so I can not really help you. But in general, you may do it like this:
- Check the packages meta information to find from which source
package they are build. 2. Download these source packages 3. Downlod the developer packages which are needed to build your package 4. Download the openssl developer package 5. Change the config from moznss to openssl 6. Build the new packages 7. Test them on one or two machines 8. Distribute them to all your Fedora machines
The devel packages and the openssl were already installed and the make depend worked without problem, so I only download, configure (with-tls=openssl) and installed this newer version, but still it doesn't work ;( I'll try to link the ldap libraries under /usr/lib64 to the new ones and see if I can fool the system to use mines.
I'm told that I can also manage to make the openldap rpm version that uses the moznss library to accept a .pem file, I thought that in this way it would be much easier, but now I'm no longer sure...
Before you recompile all packages which depend on moznss, I suggest that you try this option, as Rich suggest.
If I remember correctly, one of yor previous mails, you have had a wrong setup. You have used TLS on client side, and SSL on serverside.
Try to recompile all openldap related packages with moznss and an uptodate openldap source. Use the config from fedora source.
Then run the tests again.
If this does not work, you may go with openssl and recompile all packages you need.
An other way to get it: change to a distribution which use openssl. Debian and derivates uses gnutls, so avoid them.
On 04/13/2011 11:16 AM, harry.jede@arcor.de wrote:
Judith Flo Gaya wrote:
Hi Harry,
a priori I was doing it, now I compiled from source the same version of openldap, so now both server and clients have the same openldap
fine
Do you also use these packages on your openldap server?
The versions on the server side were old and I was suggested to update to a newer version, so I compiled it.
I don't exactly know how to check the way they are compiled..
Use "ldd" on the binary. If they are compiled against MozNSS, you'll probably have better success using your own built binaries against OpenSSL.
And don't forget: you should never never mix (openldap) packages from two different builds on one machine. Such a setup can work well, but it is for power users :-) .
Yes, my idea was to get rid of the rpm packages after installing the source one, but I can get rid of the openldap-$version because it has plenty of dependencies, so I linked to /usr/local so that libraries and binaries can be found by the system before the rpm ones. One of the packages that uses these libraries is nss_pam_ldapd, maybe that's why now the ldapsearch is working but the authentication is not
ldapsearch works now with TLS and/or SSL. That's also fine.
well if users can't authenticate against the server is kind of not fine ;) but yes, it's an improvement :)
I can't do id<user>, it complains about a TLS negotiation problem : Apr 13 09:55:25 curri0 slapd[2025]: conn=1063 fd=39 ACCEPT from IP=<client_ip>:44725 (IP=0.0.0.0:636) Apr 13 09:55:25 curri0 slapd[2025]: conn=1063 fd=39 closed (TLS negotiation failure) Apr 13 09:55:25 curri0 slapd[2025]: connection_read(39): no connection! Apr 13 09:55:25 curri0 slapd[2025]: connection_read(39): no connection!
So, the nss_pam_ldapd needs also recompiling !?
To recompile nss libraries and change the whole bunch of libraries that this means, looks like more tricky than I can do...
I have no experience with fedora, so I can not really help you. But in general, you may do it like this:
- Check the packages meta information to find from which source
package they are build. 2. Download these source packages 3. Downlod the developer packages which are needed to build your package 4. Download the openssl developer package 5. Change the config from moznss to openssl 6. Build the new packages 7. Test them on one or two machines 8. Distribute them to all your Fedora machines
The devel packages and the openssl were already installed and the make depend worked without problem, so I only download, configure (with-tls=openssl) and installed this newer version, but still it doesn't work ;( I'll try to link the ldap libraries under /usr/lib64 to the new ones and see if I can fool the system to use mines.
I'm told that I can also manage to make the openldap rpm version that uses the moznss library to accept a .pem file, I thought that in this way it would be much easier, but now I'm no longer sure...
Before you recompile all packages which depend on moznss, I suggest that you try this option, as Rich suggest.
I will also try to recompile the server so that it works with moznss instead of openssl, having the same type of tls encryption looks like it will make the communication easier (you know, speaking the same language (excuse my english btw)).
By the moment I did try to set the certificates in a moznss format (and they are there) but now I'm trying to find out how to set the ldap.conf file from the client to work with the certdb instead of the .pem file, but the mozilla web doesn't explain how to do it, I'try to find more information about that.
If I remember correctly, one of yor previous mails, you have had a wrong setup. You have used TLS on client side, and SSL on serverside.
Try to recompile all openldap related packages with moznss and an uptodate openldap source. Use the config from fedora source.
Then run the tests again.
I will.
If this does not work, you may go with openssl and recompile all packages you need.
a lot of work by maybe necessary, I'll see
An other way to get it: change to a distribution which use openssl. Debian and derivates uses gnutls, so avoid them.
I will consider it my last option...
Thanks to all, j
Hello Rich,
On 04/12/2011 10:24 PM, Rich Megginson wrote:
On 04/12/2011 02:18 PM, Judith Flo Gaya wrote:
ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 172.19.5.13:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 TLS certificate verification: subject: -unknown-, issuer: -unknown-, cipher: -unknown-, security level: off, secret key bits: 0, total key bits: 0, cache hits: 0, cache misses: 0, cache not reusable: 0 TLS certificate verification: bad TLS certificate verification: Error, -8182: Unknown code ___f 10 TLS: error: connect - force handshake failure -1 - error -8182:Unknown code ___f 10 TLS: can't connect: . ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
It seems that it doesn't like the certificate.
-8182 is SEC_ERROR_BAD_SIGNATURE. During the TLS/SSL handshake, the client tries to see if the server's cert is correctly signed by the CA cert (the local ca-cert.pem).
Now I have the same error but using the moznss certs, the certificate was copied from the server and the cert command confirms the status of the certificate (so it's not bad...
# ldapsearch -x -d1 ldap_create ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP server:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying ip:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 TLS: using moznss security dir /etc/openldap/cacerts. TLS certificate verification: subject: -unknown-, issuer: -unknown-, cipher: -unknown-, security level: off, secret key bits: 0, total key bits: 0, cache hits: 0, cache misses: 0, cache not reusable: 0 TLS certificate verification: bad TLS certificate verification: Error, -8182: Unknown code ___f 10 TLS: error: connect - force handshake failure -1 - error -8182:Unknown code ___f 10 TLS: can't connect: . ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) [root@curri2 ~]# certutil -d /etc/openldap/cacerts/ -L "name cert"
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
name cert CTu,u,u
# certutil -V -u V -d /etc/openldap/cacerts/ -n "name cert" certutil: certificate is valid
The server just complains about the tls communication: (TLS negotiation failure)
Do you think it is necessary to recompile the server so that the tls is done by moznss in both sides...
Thanks for your help, j
On 04/13/2011 04:01 AM, Judith Flo Gaya wrote:
On 04/13/2011 11:16 AM, harry.jede@arcor.de wrote:
Judith Flo Gaya wrote:
Hi Harry,
a priori I was doing it, now I compiled from source the same version of openldap, so now both server and clients have the same openldap
fine
Do you also use these packages on your openldap server?
The versions on the server side were old and I was suggested to update to a newer version, so I compiled it.
> I don't exactly know how to check the way they are compiled..
Use "ldd" on the binary. If they are compiled against MozNSS, you'll probably have better success using your own built binaries against OpenSSL.
And don't forget: you should never never mix (openldap) packages from two different builds on one machine. Such a setup can work well, but it is for power users :-) .
Yes, my idea was to get rid of the rpm packages after installing the source one, but I can get rid of the openldap-$version because it has plenty of dependencies, so I linked to /usr/local so that libraries and binaries can be found by the system before the rpm ones. One of the packages that uses these libraries is nss_pam_ldapd, maybe that's why now the ldapsearch is working but the authentication is not
ldapsearch works now with TLS and/or SSL. That's also fine.
well if users can't authenticate against the server is kind of not fine ;) but yes, it's an improvement :)
I can't do id<user>, it complains about a TLS negotiation problem : Apr 13 09:55:25 curri0 slapd[2025]: conn=1063 fd=39 ACCEPT from IP=<client_ip>:44725 (IP=0.0.0.0:636) Apr 13 09:55:25 curri0 slapd[2025]: conn=1063 fd=39 closed (TLS negotiation failure) Apr 13 09:55:25 curri0 slapd[2025]: connection_read(39): no connection! Apr 13 09:55:25 curri0 slapd[2025]: connection_read(39): no connection!
So, the nss_pam_ldapd needs also recompiling !?
To recompile nss libraries and change the whole bunch of libraries that this means, looks like more tricky than I can do...
I have no experience with fedora, so I can not really help you. But in general, you may do it like this:
- Check the packages meta information to find from which source
package they are build. 2. Download these source packages 3. Downlod the developer packages which are needed to build your package 4. Download the openssl developer package 5. Change the config from moznss to openssl 6. Build the new packages 7. Test them on one or two machines 8. Distribute them to all your Fedora machines
The devel packages and the openssl were already installed and the make depend worked without problem, so I only download, configure (with-tls=openssl) and installed this newer version, but still it doesn't work ;( I'll try to link the ldap libraries under /usr/lib64 to the new ones and see if I can fool the system to use mines.
I'm told that I can also manage to make the openldap rpm version that uses the moznss library to accept a .pem file, I thought that in this way it would be much easier, but now I'm no longer sure...
Before you recompile all packages which depend on moznss, I suggest that you try this option, as Rich suggest.
I will also try to recompile the server so that it works with moznss instead of openssl, having the same type of tls encryption looks like it will make the communication easier (you know, speaking the same language (excuse my english btw)).
By the moment I did try to set the certificates in a moznss format (and they are there) but now I'm trying to find out how to set the ldap.conf file from the client to work with the certdb instead of the .pem file, but the mozilla web doesn't explain how to do it,
You don't need to do that. You can just use PEM files. If the problem really is a BAD_SIGNATURE, then using moznss cert db vs. PEM won't make any difference (and neither will switching to openssl . . .).
If you really want to use moznss cert/key db with openldap, see http://www.openldap.org/faq/index.cgi?file=1514 - note that this information is specific to openldap and won't be found on any of the mozilla web sites.
I'try to find more information about that.
If I remember correctly, one of yor previous mails, you have had a wrong setup. You have used TLS on client side, and SSL on serverside.
Try to recompile all openldap related packages with moznss and an uptodate openldap source. Use the config from fedora source.
Then run the tests again.
I will.
If this does not work, you may go with openssl and recompile all packages you need.
a lot of work by maybe necessary, I'll see
An other way to get it: change to a distribution which use openssl. Debian and derivates uses gnutls, so avoid them.
I will consider it my last option...
Thanks to all, j
On 04/13/2011 05:02 AM, Judith Flo Gaya wrote:
Hello Rich,
On 04/12/2011 10:24 PM, Rich Megginson wrote:
On 04/12/2011 02:18 PM, Judith Flo Gaya wrote:
ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 172.19.5.13:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 TLS certificate verification: subject: -unknown-, issuer: -unknown-, cipher: -unknown-, security level: off, secret key bits: 0, total key bits: 0, cache hits: 0, cache misses: 0, cache not reusable: 0 TLS certificate verification: bad TLS certificate verification: Error, -8182: Unknown code ___f 10 TLS: error: connect - force handshake failure -1 - error -8182:Unknown code ___f 10 TLS: can't connect: . ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
It seems that it doesn't like the certificate.
-8182 is SEC_ERROR_BAD_SIGNATURE. During the TLS/SSL handshake, the client tries to see if the server's cert is correctly signed by the CA cert (the local ca-cert.pem).
Now I have the same error but using the moznss certs, the certificate was copied from the server and the cert command confirms the status of the certificate (so it's not bad...
# ldapsearch -x -d1 ldap_create ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP server:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying ip:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 TLS: using moznss security dir /etc/openldap/cacerts. TLS certificate verification: subject: -unknown-, issuer: -unknown-, cipher: -unknown-, security level: off, secret key bits: 0, total key bits: 0, cache hits: 0, cache misses: 0, cache not reusable: 0 TLS certificate verification: bad TLS certificate verification: Error, -8182: Unknown code ___f 10 TLS: error: connect - force handshake failure -1 - error -8182:Unknown code ___f 10 TLS: can't connect: . ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) [root@curri2 ~]# certutil -d /etc/openldap/cacerts/ -L "name cert"
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
name cert CTu,u,u
# certutil -V -u V -d /etc/openldap/cacerts/ -n "name cert" certutil: certificate is valid
please post the output of certutil -L -d /etc/openldap/cacerts -n "name cert"
Also post the output of openssl x509 -in /path/to/the/server-cert.pem -text
The server just complains about the tls communication: (TLS negotiation failure)
Do you think it is necessary to recompile the server so that the tls is done by moznss in both sides...
No. That is not the problem.
Thanks for your help, j
here it is, thanks!
# certutil -d /etc/openldap/cacerts/ -L "name cert"
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
name cert CTu,u,u
# certutil -V -u V -d /etc/openldap/cacerts/ -n "name cert" certutil: certificate is valid
please post the output of certutil -L -d /etc/openldap/cacerts -n "name cert"
# certutil -L -d /etc/openldap/cacerts -n "server cert" Certificate: Data: Version: 3 (0x2) Serial Number: 00:af:0e:09:e3:b5:c0:13:3f Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption Issuer: "E=jflo@imppc.org,CN=server.fdqn,OU=linux,O=company,L=Ba dalona,ST=Barcelona,C=ES" Validity: Not Before: Tue Apr 12 15:44:55 2011 Not After : Mon Jan 06 15:44:55 2014 Subject: "E=jflo@imppc.org,CN=server.fdqn,OU=linux,O=company,L=B adalona,ST=Barcelona,C=ES" Subject Public Key Info: Public Key Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: b8:53:e1:82:9d:af:b9:0c:33:95:a6:5f:b2:bc:9b:5c: 38:e9:f9:8a:64:48:fd:61:ee:93:65:f1:d0:61:9e:c7: 0f:b6:c5:9a:77:36:5a:c1:b9:cb:2e:bf:21:a8:bd:81: 68:98:fa:60:77:8a:9b:9b:73:24:2a:9b:9b:c4:53:0c: cb:44:83:d4:bd:2c:8c:19:7c:e4:c8:24:e4:bf:e7:ff: b6:1f:fe:71:eb:00:d7:c4:22:1a:f3:9a:30:5c:85:90: 08:05:c0:7d:a3:73:7c:6e:3f:60:73:ad:84:bf:82:c7: fe:b9:20:66:2a:44:88:38:20:e6:50:70:cd:5f:a9:5f: 75:59:30:3d:c4:83:06:11:12:b3:1e:dc:5c:a9:75:f0: b8:45:17:99:c9:c8:0e:94:19:a2:e4:bb:da:15:6d:77: 99:3a:f2:77:74:09:c1:6b:ef:5d:68:51:91:90:45:13: 12:51:88:11:7a:51:3d:7d:fa:1f:f4:d7:be:2e:68:9f: d7:5b:d8:ee:eb:5d:b2:1a:34:3e:2f:1d:26:89:03:46: fd:b7:70:c0:b5:30:81:77:c6:12:42:8d:d9:b1:86:b1: eb:cd:ac:88:15:8a:c2:c5:99:a2:1d:c0:59:6b:49:81: 9f:7e:06:bc:b2:64:a5:ad:08:c8:8c:79:a7:7a:df:87 Exponent: 65537 (0x10001) Signed Extensions: Name: Certificate Subject Key ID Data: c4:a3:f8:6c:51:45:55:07:46:19:c5:f1:ed:12:42:c5: 58:93:df:e3
Name: Certificate Authority Key Identifier Key ID: c4:a3:f8:6c:51:45:55:07:46:19:c5:f1:ed:12:42:c5: 58:93:df:e3
Name: Certificate Basic Constraints Data: Is a CA with no maximum path length.
Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption Signature: 1d:12:4c:2a:2b:0d:8d:a3:ae:b6:88:7f:84:e8:50:d6: b4:92:d0:50:ea:85:9a:d8:b5:5f:c1:02:ff:16:00:e7: ca:bd:2c:00:a6:a1:61:d1:3f:ff:06:34:e4:0a:31:49: 05:b4:f6:fd:2a:40:84:8a:72:f7:cc:f7:ee:23:5f:b8: 35:18:32:25:e2:6a:3b:51:e2:08:7e:37:1b:99:4d:12: bc:9d:b0:fd:89:41:9e:33:31:17:e8:cf:bb:c4:f3:f2: 5a:c9:88:f4:cb:cb:79:70:af:7d:6e:0e:59:ca:cc:7f: a6:4e:7d:2c:b1:04:a7:90:1a:08:7d:74:4d:5c:6b:71: 13:ec:e7:54:e0:b8:16:2f:19:e7:d6:bf:27:30:3e:30: 15:56:ed:08:76:cb:b5:22:78:fb:96:62:22:da:d8:67: ad:69:92:83:56:89:39:09:f0:a1:da:cd:70:aa:c1:f3: 9a:9c:6a:d8:a3:72:13:2f:a2:6d:18:5f:9e:e5:82:e9: 8a:57:1b:8f:d9:f7:6c:78:3a:3f:92:61:15:1c:df:4e: ae:d9:9e:62:29:00:cf:71:31:70:18:1b:05:24:4b:cf: 9f:62:30:1d:38:9a:e6:a9:e5:0a:f3:fb:8e:5a:fc:20: a5:81:c9:b7:0c:a3:8c:a2:e5:31:e2:43:03:ca:a8:ba Fingerprint (MD5): 93:AB:C5:56:6F:59:06:1A:49:8D:A4:71:40:25:D1:7E Fingerprint (SHA1): 34:45:77:64:9F:4F:7B:90:27:23:CC:B8:0A:97:E2:BF:95:01:B6:3B
Certificate Trust Flags: SSL Flags: Valid CA Trusted CA User Trusted Client CA Email Flags: User Object Signing Flags: User
Also post the output of openssl x509 -in /path/to/the/server-cert.pem -text
# # openssl x509 -in /etc/openldap/cacerts/curri3-cert.pem -text Certificate: Data: Version: 1 (0x0) Serial Number: 1 (0x1) Signature Algorithm: sha1WithRSAEncryption Issuer: C=ES, ST=Barcelona, L=Badalona, O=company, OU=linux, CN=server.fdqn/emailAddress=jflo@imppc.org Validity Not Before: Apr 12 15:55:56 2011 GMT Not After : Jan 6 15:55:56 2014 GMT Subject: C=ES, ST=Barcelona, L=Badalona, O=company, OU=linux, CN=client.fdqn/emailAddress=jflo@imppc.org Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:cc:d8:b1:b4:fa:48:96:d8:60:8a:40:91:48:1b: f8:27:8c:f0:d8:d7:6e:73:7a:6d:15:fa:75:11:24: d4:a1:b7:7f:10:7e:cf:76:93:31:02:46:07:74:ab: 28:5b:6a:5b:87:d9:27:73:2a:9c:21:25:c9:79:df: 40:47:15:53:c9:b3:db:f4:b4:b6:38:34:c5:5c:f1: 97:7b:a4:ff:19:7d:aa:4c:f0:7e:18:0b:be:57:c6: 17:b5:0b:84:f6:4e:6e:98:8d:7e:39:20:b9:f7:b5: 2a:03:66:d7:06:25:9f:19:a6:fe:12:86:24:b6:21: 25:62:90:88:ea:8b:62:db:e7:41:15:93:36:01:e4: 09:f7:08:ea:6e:32:e2:68:79:ec:0d:ff:d0:9e:7c: b1:b3:da:13:3a:c0:58:dc:6a:f2:28:d2:ca:cf:44: e6:af:71:0a:57:e7:eb:39:3a:ea:70:cb:ed:86:6d: 06:c9:d7:78:ab:63:5f:3a:89:67:bc:39:ed:e8:f7: 43:6a:5e:92:78:c1:00:e3:2b:0c:7f:cb:3c:5c:b9: 07:ae:31:9b:ef:b2:eb:5c:70:63:f8:5c:22:6b:ed: bc:69:e5:6b:19:18:51:f2:73:72:4c:9e:47:f1:f2: d7:38:3b:52:18:81:ef:c9:72:50:83:08:38:38:6b: ce:73 Exponent: 65537 (0x10001) Signature Algorithm: sha1WithRSAEncryption 83:ed:11:d4:08:2a:f6:10:41:c9:01:30:b1:60:2d:ed:1f:12: 80:b9:b4:d3:98:f9:a4:ea:42:ac:89:b2:db:a1:98:77:54:82: 86:17:fa:06:db:9d:db:41:f2:24:cf:b8:08:67:de:b5:d1:c2: 7d:94:06:ef:74:57:9d:7a:f8:a8:62:d2:4d:71:11:e6:07:bd: b1:18:fa:c4:d7:3b:a6:57:42:fc:65:a5:27:e4:64:51:66:83: 22:33:4f:6b:ee:b3:8d:9f:29:a4:af:e9:5e:e8:91:79:d6:bd: 8f:4d:b6:d6:74:ea:96:c4:75:ea:3c:c5:71:9b:28:4d:00:93: 2d:02:38:03:d4:84:f2:af:73:d3:fd:f7:31:2f:33:2b:d3:ac: 47:68:9d:48:2f:5d:a0:6d:6d:8a:73:c7:c9:3e:4d:ad:5f:ef: 07:39:20:1e:1f:46:f7:7c:4b:e1:5e:7d:3d:4d:a2:7f:6e:f0: c4:c2:8d:90:5d:cf:77:52:a7:33:f4:e8:97:c8:da:1b:73:ea: c9:50:2c:ed:6d:2f:db:1d:02:f3:0d:a8:d0:df:d1:3e:8f:15: db:53:4d:4d:85:5f:a4:c8:80:68:b7:ed:d2:f2:07:a0:e4:12: d1:95:36:8b:81:53:d3:82:9d:46:d6:6e:77:6b:6e:bb:6f:62: d0:ba:28:32 -----BEGIN CERTIFICATE----- MIIDljCCAn4CAQEwDQYJKoZIhvcNAQEFBQAwgZAxCzAJBgNVBAYTAkVTMRIwEAYD VQQIDAlCYXJjZWxvbmExETAPBgNVBAcMCEJhZGFsb25hMQ4wDAYDVQQKDAVJTVBQ QzEOMAwGA1UECwwFbGludXgxGzAZBgNVBAMMEmN1cnJpMC5pbXBwYy5sb2NhbDEd MBsGCSqGSIb3DQEJARYOamZsb0BpbXBwYy5vcmcwHhcNMTEwNDEyMTU1NTU2WhcN MTQwMTA2MTU1NTU2WjCBkDELMAkGA1UEBhMCRVMxEjAQBgNVBAgMCUJhcmNlbG9u YTERMA8GA1UEBwwIQmFkYWxvbmExDjAMBgNVBAoMBUlNUFBDMQ4wDAYDVQQLDAVs aW51eDEbMBkGA1UEAwwSY3VycmkzLmltcHBjLmxvY2FsMR0wGwYJKoZIhvcNAQkB Fg5qZmxvQGltcHBjLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMzYsbT6SJbYYIpAkUgb+CeM8NjXbnN6bRX6dREk1KG3fxB+z3aTMQJGB3SrKFtq W4fZJ3MqnCElyXnfQEcVU8mz2/S0tjg0xVzxl3uk/xl9qkzwfhgLvlfGF7ULhPZO bpiNfjkgufe1KgNm1wYlnxmm/hKGJLYhJWKQiOqLYtvnQRWTNgHkCfcI6m4y4mh5 7A3/0J58sbPaEzrAWNxq8ijSys9E5q9xClfn6zk66nDL7YZtBsnXeKtjXzqJZ7w5 7ej3Q2peknjBAOMrDH/LPFy5B64xm++y61xwY/hcImvtvGnlaxkYUfJzckyeR/Hy 1zg7UhiB78lyUIMIODhrznMCAwEAATANBgkqhkiG9w0BAQUFAAOCAQEAg+0R1Agq 9hBByQEwsWAt7R8SgLm005j5pOpCrImy26GYd1SChhf6Btud20HyJM+4CGfetdHC fZQG73RXnXr4qGLSTXER5ge9sRj6xNc7pldC/GWlJ+RkUWaDIjNPa+6zjZ8ppK/p XuiReda9j0221nTqlsR16jzFcZsoTQCTLQI4A9SE8q9z0/33MS8zK9OsR2idSC9d oG1tinPHyT5NrV/vBzkgHh9G93xL4V59PU2if27wxMKNkF3Pd1KnM/Tol8jaG3Pq yVAs7W0v2x0C8w2o0N/RPo8V21NNTYVfpMiAaLft0vIHoOQS0ZU2i4FT04KdRtZu d2tuu29i0LooMg== -----END CERTIFICATE-----
The server just complains about the tls communication: (TLS negotiation failure)
Do you think it is necessary to recompile the server so that the tls is done by moznss in both sides...
No. That is not the problem.
Thanks for your help, j
On 04/13/2011 08:27 AM, Judith Flo Gaya wrote:
here it is, thanks!
# certutil -d /etc/openldap/cacerts/ -L "name cert"
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
name cert CTu,u,u
# certutil -V -u V -d /etc/openldap/cacerts/ -n "name cert" certutil: certificate is valid
please post the output of certutil -L -d /etc/openldap/cacerts -n "name cert"
# certutil -L -d /etc/openldap/cacerts -n "server cert" Certificate: Data: Version: 3 (0x2) Serial Number: 00:af:0e:09:e3:b5:c0:13:3f Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption Issuer: "E=jflo@imppc.org,CN=server.fdqn,OU=linux,O=company,L=Ba dalona,ST=Barcelona,C=ES" Validity: Not Before: Tue Apr 12 15:44:55 2011 Not After : Mon Jan 06 15:44:55 2014 Subject: "E=jflo@imppc.org,CN=server.fdqn,OU=linux,O=company,L=B adalona,ST=Barcelona,C=ES" Subject Public Key Info: Public Key Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: b8:53:e1:82:9d:af:b9:0c:33:95:a6:5f:b2:bc:9b:5c: 38:e9:f9:8a:64:48:fd:61:ee:93:65:f1:d0:61:9e:c7: 0f:b6:c5:9a:77:36:5a:c1:b9:cb:2e:bf:21:a8:bd:81: 68:98:fa:60:77:8a:9b:9b:73:24:2a:9b:9b:c4:53:0c: cb:44:83:d4:bd:2c:8c:19:7c:e4:c8:24:e4:bf:e7:ff: b6:1f:fe:71:eb:00:d7:c4:22:1a:f3:9a:30:5c:85:90: 08:05:c0:7d:a3:73:7c:6e:3f:60:73:ad:84:bf:82:c7: fe:b9:20:66:2a:44:88:38:20:e6:50:70:cd:5f:a9:5f: 75:59:30:3d:c4:83:06:11:12:b3:1e:dc:5c:a9:75:f0: b8:45:17:99:c9:c8:0e:94:19:a2:e4:bb:da:15:6d:77: 99:3a:f2:77:74:09:c1:6b:ef:5d:68:51:91:90:45:13: 12:51:88:11:7a:51:3d:7d:fa:1f:f4:d7:be:2e:68:9f: d7:5b:d8:ee:eb:5d:b2:1a:34:3e:2f:1d:26:89:03:46: fd:b7:70:c0:b5:30:81:77:c6:12:42:8d:d9:b1:86:b1: eb:cd:ac:88:15:8a:c2:c5:99:a2:1d:c0:59:6b:49:81: 9f:7e:06:bc:b2:64:a5:ad:08:c8:8c:79:a7:7a:df:87 Exponent: 65537 (0x10001) Signed Extensions: Name: Certificate Subject Key ID Data: c4:a3:f8:6c:51:45:55:07:46:19:c5:f1:ed:12:42:c5: 58:93:df:e3
Name: Certificate Authority Key Identifier Key ID: c4:a3:f8:6c:51:45:55:07:46:19:c5:f1:ed:12:42:c5: 58:93:df:e3 Name: Certificate Basic Constraints Data: Is a CA with no maximum path length. Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption Signature: 1d:12:4c:2a:2b:0d:8d:a3:ae:b6:88:7f:84:e8:50:d6: b4:92:d0:50:ea:85:9a:d8:b5:5f:c1:02:ff:16:00:e7: ca:bd:2c:00:a6:a1:61:d1:3f:ff:06:34:e4:0a:31:49: 05:b4:f6:fd:2a:40:84:8a:72:f7:cc:f7:ee:23:5f:b8: 35:18:32:25:e2:6a:3b:51:e2:08:7e:37:1b:99:4d:12: bc:9d:b0:fd:89:41:9e:33:31:17:e8:cf:bb:c4:f3:f2: 5a:c9:88:f4:cb:cb:79:70:af:7d:6e:0e:59:ca:cc:7f: a6:4e:7d:2c:b1:04:a7:90:1a:08:7d:74:4d:5c:6b:71: 13:ec:e7:54:e0:b8:16:2f:19:e7:d6:bf:27:30:3e:30: 15:56:ed:08:76:cb:b5:22:78:fb:96:62:22:da:d8:67: ad:69:92:83:56:89:39:09:f0:a1:da:cd:70:aa:c1:f3: 9a:9c:6a:d8:a3:72:13:2f:a2:6d:18:5f:9e:e5:82:e9: 8a:57:1b:8f:d9:f7:6c:78:3a:3f:92:61:15:1c:df:4e: ae:d9:9e:62:29:00:cf:71:31:70:18:1b:05:24:4b:cf: 9f:62:30:1d:38:9a:e6:a9:e5:0a:f3:fb:8e:5a:fc:20: a5:81:c9:b7:0c:a3:8c:a2:e5:31:e2:43:03:ca:a8:ba Fingerprint (MD5): 93:AB:C5:56:6F:59:06:1A:49:8D:A4:71:40:25:D1:7E Fingerprint (SHA1): 34:45:77:64:9F:4F:7B:90:27:23:CC:B8:0A:97:E2:BF:95:01:B6:3B Certificate Trust Flags: SSL Flags: Valid CA Trusted CA User Trusted Client CA Email Flags: User Object Signing Flags: UserAlso post the output of openssl x509 -in /path/to/the/server-cert.pem -text
# # openssl x509 -in /etc/openldap/cacerts/curri3-cert.pem -text Certificate: Data: Version: 1 (0x0) Serial Number: 1 (0x1) Signature Algorithm: sha1WithRSAEncryption Issuer: C=ES, ST=Barcelona, L=Badalona, O=company, OU=linux, CN=server.fdqn/emailAddress=jflo@imppc.org Validity Not Before: Apr 12 15:55:56 2011 GMT Not After : Jan 6 15:55:56 2014 GMT Subject: C=ES, ST=Barcelona, L=Badalona, O=company, OU=linux, CN=client.fdqn/emailAddress=jflo@imppc.org
I notice that the format of the Issuer here does not match the format of the Subject, but that may be just a difference in the way moznss and openssl handle the "/emailAddress=...". You could confirm by doing openssl x509 -in /path/to/cacert.pem -text
I don't know - I don't see anything obviously wrong here.
If you think this is a problem with openldap+moznss (that is, if you can get it to work with openldap+openssl), please file a bug/its.
Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:cc:d8:b1:b4:fa:48:96:d8:60:8a:40:91:48:1b: f8:27:8c:f0:d8:d7:6e:73:7a:6d:15:fa:75:11:24: d4:a1:b7:7f:10:7e:cf:76:93:31:02:46:07:74:ab: 28:5b:6a:5b:87:d9:27:73:2a:9c:21:25:c9:79:df: 40:47:15:53:c9:b3:db:f4:b4:b6:38:34:c5:5c:f1: 97:7b:a4:ff:19:7d:aa:4c:f0:7e:18:0b:be:57:c6: 17:b5:0b:84:f6:4e:6e:98:8d:7e:39:20:b9:f7:b5: 2a:03:66:d7:06:25:9f:19:a6:fe:12:86:24:b6:21: 25:62:90:88:ea:8b:62:db:e7:41:15:93:36:01:e4: 09:f7:08:ea:6e:32:e2:68:79:ec:0d:ff:d0:9e:7c: b1:b3:da:13:3a:c0:58:dc:6a:f2:28:d2:ca:cf:44: e6:af:71:0a:57:e7:eb:39:3a:ea:70:cb:ed:86:6d: 06:c9:d7:78:ab:63:5f:3a:89:67:bc:39:ed:e8:f7: 43:6a:5e:92:78:c1:00:e3:2b:0c:7f:cb:3c:5c:b9: 07:ae:31:9b:ef:b2:eb:5c:70:63:f8:5c:22:6b:ed: bc:69:e5:6b:19:18:51:f2:73:72:4c:9e:47:f1:f2: d7:38:3b:52:18:81:ef:c9:72:50:83:08:38:38:6b: ce:73 Exponent: 65537 (0x10001) Signature Algorithm: sha1WithRSAEncryption 83:ed:11:d4:08:2a:f6:10:41:c9:01:30:b1:60:2d:ed:1f:12: 80:b9:b4:d3:98:f9:a4:ea:42:ac:89:b2:db:a1:98:77:54:82: 86:17:fa:06:db:9d:db:41:f2:24:cf:b8:08:67:de:b5:d1:c2: 7d:94:06:ef:74:57:9d:7a:f8:a8:62:d2:4d:71:11:e6:07:bd: b1:18:fa:c4:d7:3b:a6:57:42:fc:65:a5:27:e4:64:51:66:83: 22:33:4f:6b:ee:b3:8d:9f:29:a4:af:e9:5e:e8:91:79:d6:bd: 8f:4d:b6:d6:74:ea:96:c4:75:ea:3c:c5:71:9b:28:4d:00:93: 2d:02:38:03:d4:84:f2:af:73:d3:fd:f7:31:2f:33:2b:d3:ac: 47:68:9d:48:2f:5d:a0:6d:6d:8a:73:c7:c9:3e:4d:ad:5f:ef: 07:39:20:1e:1f:46:f7:7c:4b:e1:5e:7d:3d:4d:a2:7f:6e:f0: c4:c2:8d:90:5d:cf:77:52:a7:33:f4:e8:97:c8:da:1b:73:ea: c9:50:2c:ed:6d:2f:db:1d:02:f3:0d:a8:d0:df:d1:3e:8f:15: db:53:4d:4d:85:5f:a4:c8:80:68:b7:ed:d2:f2:07:a0:e4:12: d1:95:36:8b:81:53:d3:82:9d:46:d6:6e:77:6b:6e:bb:6f:62: d0:ba:28:32-----BEGIN CERTIFICATE----- MIIDljCCAn4CAQEwDQYJKoZIhvcNAQEFBQAwgZAxCzAJBgNVBAYTAkVTMRIwEAYD VQQIDAlCYXJjZWxvbmExETAPBgNVBAcMCEJhZGFsb25hMQ4wDAYDVQQKDAVJTVBQ QzEOMAwGA1UECwwFbGludXgxGzAZBgNVBAMMEmN1cnJpMC5pbXBwYy5sb2NhbDEd MBsGCSqGSIb3DQEJARYOamZsb0BpbXBwYy5vcmcwHhcNMTEwNDEyMTU1NTU2WhcN MTQwMTA2MTU1NTU2WjCBkDELMAkGA1UEBhMCRVMxEjAQBgNVBAgMCUJhcmNlbG9u YTERMA8GA1UEBwwIQmFkYWxvbmExDjAMBgNVBAoMBUlNUFBDMQ4wDAYDVQQLDAVs aW51eDEbMBkGA1UEAwwSY3VycmkzLmltcHBjLmxvY2FsMR0wGwYJKoZIhvcNAQkB Fg5qZmxvQGltcHBjLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMzYsbT6SJbYYIpAkUgb+CeM8NjXbnN6bRX6dREk1KG3fxB+z3aTMQJGB3SrKFtq W4fZJ3MqnCElyXnfQEcVU8mz2/S0tjg0xVzxl3uk/xl9qkzwfhgLvlfGF7ULhPZO bpiNfjkgufe1KgNm1wYlnxmm/hKGJLYhJWKQiOqLYtvnQRWTNgHkCfcI6m4y4mh5 7A3/0J58sbPaEzrAWNxq8ijSys9E5q9xClfn6zk66nDL7YZtBsnXeKtjXzqJZ7w5 7ej3Q2peknjBAOMrDH/LPFy5B64xm++y61xwY/hcImvtvGnlaxkYUfJzckyeR/Hy 1zg7UhiB78lyUIMIODhrznMCAwEAATANBgkqhkiG9w0BAQUFAAOCAQEAg+0R1Agq 9hBByQEwsWAt7R8SgLm005j5pOpCrImy26GYd1SChhf6Btud20HyJM+4CGfetdHC fZQG73RXnXr4qGLSTXER5ge9sRj6xNc7pldC/GWlJ+RkUWaDIjNPa+6zjZ8ppK/p XuiReda9j0221nTqlsR16jzFcZsoTQCTLQI4A9SE8q9z0/33MS8zK9OsR2idSC9d oG1tinPHyT5NrV/vBzkgHh9G93xL4V59PU2if27wxMKNkF3Pd1KnM/Tol8jaG3Pq yVAs7W0v2x0C8w2o0N/RPo8V21NNTYVfpMiAaLft0vIHoOQS0ZU2i4FT04KdRtZu d2tuu29i0LooMg== -----END CERTIFICATE-----
The server just complains about the tls communication: (TLS negotiation failure)
Do you think it is necessary to recompile the server so that the tls is done by moznss in both sides...
No. That is not the problem.
Thanks for your help, j
On 04/13/2011 04:37 PM, Rich Megginson wrote:
Also post the output of openssl x509 -in /path/to/the/server-cert.pem -text
# # openssl x509 -in /etc/openldap/cacerts/curri3-cert.pem -text Certificate: Data: Version: 1 (0x0) Serial Number: 1 (0x1) Signature Algorithm: sha1WithRSAEncryption Issuer: C=ES, ST=Barcelona, L=Badalona, O=company, OU=linux, CN=server.fdqn/emailAddress=jflo@imppc.org Validity Not Before: Apr 12 15:55:56 2011 GMT Not After : Jan 6 15:55:56 2014 GMT Subject: C=ES, ST=Barcelona, L=Badalona, O=company, OU=linux, CN=client.fdqn/emailAddress=jflo@imppc.org
I notice that the format of the Issuer here does not match the format of the Subject, but that may be just a difference in the way moznss and openssl handle the "/emailAddress=...". You could confirm by doing openssl x509 -in /path/to/cacert.pem -text
I don't know - I don't see anything obviously wrong here.
I'm just following the steps, I no longer know what to do, but I'm afraid that I'm kind of stuck. As the server is a rhel6 its openldap is compiled against openssl, the clients are using openldap with moznss, so it looks like I'll be forced to recompile everything to either moznss or openssl but it looks very very complicated. I will try to make the setup from fedora to fedora with certificates and see if the tls communication is easier. if that works I think that I will abandon the setup with rh, I can afford spending more time on this, specially if you (that know a lot more than me) think that there's nothing wrong..
If you think this is a problem with openldap+moznss (that is, if you can get it to work with openldap+openssl), please file a bug/its.
if I can give it a try later on, I'll do it. Thanks, j
On Wed, 13 Apr 2011, Judith Flo Gaya wrote:
As the server is a rhel6 its openldap is compiled against openssl, the clients are using openldap with moznss, so it looks like I'll be forced to recompile everything to either moznss or openssl but it looks very very complicated.
My experience differs. I know that I have F14 clients (and probably others; clients are largely out of my scope) using NSS, even though I don't have NSS on the servers. I'm not sure if somewhere in this thread you mentioned that you were (or weren't) using generally-respected commercial CAs? We do, and a working F14 client has:
[/etc/openldap/ldap.conf says] TLS_CACERT /etc/pki/tls/cert.pem
and /etc/pki/tls/cert.pem is a symlink to "certs/ca-bundle.crt" which has, unsurprisingly, a bunch of CA certs--I note no base64 encoding. Apparently these are both provided by a Fedora "ca-certificates" package.
All this is to say...I've seen the OpenLDAP NSS client work at least once, via ldapsearch(1), even though it's not the TLS implementation on the server side.
On 4/13/11 8:00 PM, Aaron Richton wrote:
On Wed, 13 Apr 2011, Judith Flo Gaya wrote:
As the server is a rhel6 its openldap is compiled against openssl, the clients are using openldap with moznss, so it looks like I'll be forced to recompile everything to either moznss or openssl but it looks very very complicated.
My experience differs. I know that I have F14 clients (and probably others; clients are largely out of my scope) using NSS, even though I don't have NSS on the servers. I'm not sure if somewhere in this thread you mentioned that you were (or weren't) using generally-respected commercial CAs? We do, and a working F14 client has:
[/etc/openldap/ldap.conf says] TLS_CACERT /etc/pki/tls/cert.pem
and /etc/pki/tls/cert.pem is a symlink to "certs/ca-bundle.crt" which has, unsurprisingly, a bunch of CA certs--I note no base64 encoding. Apparently these are both provided by a Fedora "ca-certificates" package.
I see, I also have those files that you mention... I created my own CA as lots of tutorials explain.. Then I transmitted it to the clients and used it in the ldap.conf file. Do you suggest me to send those to the server and use them instead of the ones I generated with openssl? What's your server?
All this is to say...I've seen the OpenLDAP NSS client work at least once, via ldapsearch(1), even though it's not the TLS implementation on the server side.
Well my final problem were not ldapsearch but the user autenticacion. The ldapsaerch showed the whole ldap definitions but if I try to ssh with an ldap user to the machine, I get some TLS negotiation problem ;( That's when I was told that the problem may be caused by the implementation of the ldap client (with moznss support).
Thanks a lot for your comments, looks like I'm definitely doing something wrong although I can't find out what ;(
On Wed, 13 Apr 2011, Judith Flo Gaya wrote:
I see, I also have those files that you mention... I created my own CA as lots of tutorials explain.. Then I transmitted it to the clients and used it in the ldap.conf file. Do you suggest me to send those to the server and use them instead of the ones I generated with openssl?
Well, you'll need the CA on the client to match the CA that signed the server's certificate. In other words...if you generated your own CA for both the client and the server, trust issues would be completely expected...
What's your server?
OpenLDAP software is on both sides of the equation; it's just that some clients are NSS, some clients are OpenSSL, some clients are GnuTLS, while ALL servers are OpenSSL.
Well my final problem were not ldapsearch but the user autenticacion. The ldapsaerch showed the whole ldap definitions but if I try to ssh with an ldap user to the machine, I get some TLS negotiation problem ;( That's when I was told that the problem may be caused by the implementation of the ldap client (with moznss support).
Well, when troubleshooting, it's often easiest to look with a narrow scope. Using OpenLDAP software, such as ldapsearch(1) and ldapwhoami(1), will probably offer a better debugging platform than an ssh implementation? One step at a time...
Hello Aaron,
On 04/13/2011 09:07 PM, Aaron Richton wrote:
On Wed, 13 Apr 2011, Judith Flo Gaya wrote:
I see, I also have those files that you mention... I created my own CA as lots of tutorials explain.. Then I transmitted it to the clients and used it in the ldap.conf file. Do you suggest me to send those to the server and use them instead of the ones I generated with openssl?
Well, you'll need the CA on the client to match the CA that signed the server's certificate. In other words...if you generated your own CA for both the client and the server, trust issues would be completely expected...
I don't know if I understood you or I didn't make myself clear on that point. I created a CA in the server and the copied the file to the client, is that wrong?
What's your server?
OpenLDAP software is on both sides of the equation; it's just that some clients are NSS, some clients are OpenSSL, some clients are GnuTLS, while ALL servers are OpenSSL.
I was talking about the operating system, for some reason I think that having red hat (with openldap compiled using openssl) and clients with fedora (openldap compiled against moznss) created my problems. Now that you said that this is your case (I think) then it may be something related to... I don't know what.
Well my final problem were not ldapsearch but the user autenticacion. The ldapsaerch showed the whole ldap definitions but if I try to ssh with an ldap user to the machine, I get some TLS negotiation problem ;( That's when I was told that the problem may be caused by the implementation of the ldap client (with moznss support).
Well, when troubleshooting, it's often easiest to look with a narrow scope. Using OpenLDAP software, such as ldapsearch(1) and ldapwhoami(1), will probably offer a better debugging platform than an ssh implementation? One step at a time...
Yes, I totally agree, that's why I setup my own openldap installation and only care about ldapsearch working, then when ldapsearch finally worked, then I start looking at the user auth part, changing passw, etc.. as this part wasn't working and it appear to be a moznss problem, I got stuck... until you arrived, I will try what you suggest about using the pki certs instead of the openssl ones..
Thanks a lot for the suggestion, hope this finally fix the issue. j
Hello,
After doing all you suggest with the pki keys I'm stuck in the very same place, the system is able to do ldapsearch but all user auth is not working, I do this in order to configure the auth in the clients # authconfig --disablecachecreds --enableldaps --enableldapauth --ldapserver=ldaps://server.fdqn --ldapbasedn=dc=linux,dc=imppc,dc=org --disablefingerprint --disablewinbind --disablewins --disablesssd --disablesssdauth --disablenis --enablecache --enablelocauthorize --disablemd5 --passalgo=sha512 --updateall
The pam.d files look ok:
# cat /etc/pam.d/system-auth #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_ldap.so use_first_pass auth required pam_deny.so
account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_ldap.so account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3 type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_ldap.so use_authtok password required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_ldap.so
This is the message in ldap server when I do id <ldap_user> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 ACCEPT from IP=[::1]:36208 (IP=[::]:636) Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 TLS established tls_ssf=256 ssf=256 Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 STARTTLS Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 RESULT oid= err=1 text=TLS already started Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=1 UNBIND Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 closed
Aparently is ok but the id is not known Any ideas? Thanks a lot! j
On 04/14/2011 05:44 PM, Judith Flo Gaya wrote:
Hello Aaron,
On 04/13/2011 09:07 PM, Aaron Richton wrote:
On Wed, 13 Apr 2011, Judith Flo Gaya wrote:
I see, I also have those files that you mention... I created my own CA as lots of tutorials explain.. Then I transmitted it to the clients and used it in the ldap.conf file. Do you suggest me to send those to the server and use them instead of the ones I generated with openssl?
Well, you'll need the CA on the client to match the CA that signed the server's certificate. In other words...if you generated your own CA for both the client and the server, trust issues would be completely expected...
I don't know if I understood you or I didn't make myself clear on that point. I created a CA in the server and the copied the file to the client, is that wrong?
What's your server?
OpenLDAP software is on both sides of the equation; it's just that some clients are NSS, some clients are OpenSSL, some clients are GnuTLS, while ALL servers are OpenSSL.
I was talking about the operating system, for some reason I think that having red hat (with openldap compiled using openssl) and clients with fedora (openldap compiled against moznss) created my problems. Now that you said that this is your case (I think) then it may be something related to... I don't know what.
Well my final problem were not ldapsearch but the user autenticacion. The ldapsaerch showed the whole ldap definitions but if I try to ssh with an ldap user to the machine, I get some TLS negotiation problem ;( That's when I was told that the problem may be caused by the implementation of the ldap client (with moznss support).
Well, when troubleshooting, it's often easiest to look with a narrow scope. Using OpenLDAP software, such as ldapsearch(1) and ldapwhoami(1), will probably offer a better debugging platform than an ssh implementation? One step at a time...
Yes, I totally agree, that's why I setup my own openldap installation and only care about ldapsearch working, then when ldapsearch finally worked, then I start looking at the user auth part, changing passw, etc.. as this part wasn't working and it appear to be a moznss problem, I got stuck... until you arrived, I will try what you suggest about using the pki certs instead of the openssl ones..
Thanks a lot for the suggestion, hope this finally fix the issue. j
On Thu, 14 Apr 2011, Judith Flo Gaya wrote:
Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 ACCEPT from IP=[::1]:36208 (IP=[::]:636) Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 TLS established tls_ssf=256 ssf=256 Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 STARTTLS Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 RESULT oid= err=1 text=TLS already started Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=1 UNBIND Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 closed
So you're trying to issue a StartTLS operation over an implicit SSL connection? There's no point to starting encryption on a connection that's already encrypted (hence the error). Either combine:
a cleartext port (i.e. 389) with the StartTLS operation
or
an SSL port (i.e. 636) with NO StartTLS operation.
I came in late on this thread, so disregard if this has already been said or is not applicable. Also, we use standard RH packages, so if you are building your own, this may not be any use to you.
We have a few RH6 boxes authenticating against our ldap servers. It's been awhile, but in addition to the CA certs being copied to the clients and the correct perms assigned we had come success enabling legacy mode in RH6 when running authconfig to set up the box. If I recall, in legacy mode sssd does not run and it uses a more RH5 way of authenticating clients. Unfortunately, I don't have a RH6 box in front of me, but you can edit /etc/sysconfig/authconfig to set legacy mode. Then run your authconfig command to set up the box. Also, look at /etc/pam_ldap.conf if you decide to try to authenticate in this manner. The settings in there are like they were in /etc/ldap.conf, RH5. Your system-auth file looks like ours does as far as I can remember.
Just something else you may want to try if you haven't already.
On Thu, 14 Apr 2011 18:55 +0200, "Judith Flo Gaya" jflo@imppc.org wrote:
Hello,
After doing all you suggest with the pki keys I'm stuck in the very same place, the system is able to do ldapsearch but all user auth is not working, I do this in order to configure the auth in the clients # authconfig --disablecachecreds --enableldaps --enableldapauth --ldapserver=ldaps://server.fdqn --ldapbasedn=dc=linux,dc=imppc,dc=org --disablefingerprint --disablewinbind --disablewins --disablesssd --disablesssdauth --disablenis --enablecache --enablelocauthorize --disablemd5 --passalgo=sha512 --updateall
The pam.d files look ok:
# cat /etc/pam.d/system-auth #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_ldap.so use_first_pass auth required pam_deny.so
account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_ldap.so account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3 type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_ldap.so use_authtok password required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_ldap.so
This is the message in ldap server when I do id <ldap_user> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 ACCEPT from IP=[::1]:36208 (IP=[::]:636) Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 TLS established tls_ssf=256 ssf=256 Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 EXT oid=1">oid=1.3.6.1.4.1.1466.20037 Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 STARTTLS Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 RESULT oid= err=1 text=TLS already started Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=1 UNBIND Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 closed
Aparently is ok but the id is not known Any ideas? Thanks a lot! j
On 04/14/2011 05:44 PM, Judith Flo Gaya wrote:
Hello Aaron,
On 04/13/2011 09:07 PM, Aaron Richton wrote:
On Wed, 13 Apr 2011, Judith Flo Gaya wrote:
I see, I also have those files that you mention... I created my own CA as lots of tutorials explain.. Then I transmitted it to the clients and used it in the ldap.conf file. Do you suggest me to send those to the server and use them instead of the ones I generated with openssl?
Well, you'll need the CA on the client to match the CA that signed the server's certificate. In other words...if you generated your own CA for both the client and the server, trust issues would be completely expected...
I don't know if I understood you or I didn't make myself clear on that point. I created a CA in the server and the copied the file to the client, is that wrong?
What's your server?
OpenLDAP software is on both sides of the equation; it's just that some clients are NSS, some clients are OpenSSL, some clients are GnuTLS, while ALL servers are OpenSSL.
I was talking about the operating system, for some reason I think that having red hat (with openldap compiled using openssl) and clients with fedora (openldap compiled against moznss) created my problems. Now that you said that this is your case (I think) then it may be something related to... I don't know what.
Well my final problem were not ldapsearch but the user autenticacion. The ldapsaerch showed the whole ldap definitions but if I try to ssh with an ldap user to the machine, I get some TLS negotiation problem ;( That's when I was told that the problem may be caused by the implementation of the ldap client (with moznss support).
Well, when troubleshooting, it's often easiest to look with a narrow scope. Using OpenLDAP software, such as ldapsearch(1) and ldapwhoami(1), will probably offer a better debugging platform than an ssh implementation? One step at a time...
Yes, I totally agree, that's why I setup my own openldap installation and only care about ldapsearch working, then when ldapsearch finally worked, then I start looking at the user auth part, changing passw, etc.. as this part wasn't working and it appear to be a moznss problem, I got stuck... until you arrived, I will try what you suggest about using the pki certs instead of the openssl ones..
Thanks a lot for the suggestion, hope this finally fix the issue. j
-- Judith Flo Gaya Systems Administrator IMPPC e-mail: jflo@imppc.org Tel (+34) 93 554-3079 Fax (+34) 93 465-1472
Institut de Medicina Predictiva i Personalitzada del Càncer Crta Can Ruti, Camí de les Escoles s/n 08916 Badalona, Barcelona, Spain http://www.imppc.org
Hello Aaron, I already changed the parameter in the pam_ldap.conf and in the nslcd.conf ssl on instead of ssl start_tls
Anywhere else? Thanks for the advice, I thought I had fixed it... and in fact ldapsearch -x -H ldaps://server does work, the problem is within pam, it seems to be stucked using start_tls...
On 04/14/2011 07:08 PM, Aaron Richton wrote:
On Thu, 14 Apr 2011, Judith Flo Gaya wrote:
Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 ACCEPT from IP=[::1]:36208 (IP=[::]:636) Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 TLS established tls_ssf=256 ssf=256 Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 STARTTLS Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 RESULT oid= err=1 text=TLS already started Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=1 UNBIND Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 closed
So you're trying to issue a StartTLS operation over an implicit SSL connection? There's no point to starting encryption on a connection that's already encrypted (hence the error). Either combine:
a cleartext port (i.e. 389) with the StartTLS operation
or
an SSL port (i.e. 636) with NO StartTLS operation.
Hello ldap,
In fact in my authconfig instruction I have --enableforcelegacy, but this only works on my f14 clients, rh refuses to accept this option, but I already set the forcelegacy=yes in my /etc/sysconfig/authconfig. At the very beginning sssd was a little crazy... but I have learnt to get rid of it.
How do you set your authconfig system? right now is the only missing part of the puzzle ;(
On 04/14/2011 07:40 PM, ldap@mm.st wrote:
I came in late on this thread, so disregard if this has already been said or is not applicable. Also, we use standard RH packages, so if you are building your own, this may not be any use to you.
We have a few RH6 boxes authenticating against our ldap servers. It's been awhile, but in addition to the CA certs being copied to the clients and the correct perms assigned we had come success enabling legacy mode in RH6 when running authconfig to set up the box. If I recall, in legacy mode sssd does not run and it uses a more RH5 way of authenticating clients. Unfortunately, I don't have a RH6 box in front of me, but you can edit /etc/sysconfig/authconfig to set legacy mode. Then run your authconfig command to set up the box. Also, look at /etc/pam_ldap.conf if you decide to try to authenticate in this manner. The settings in there are like they were in /etc/ldap.conf, RH5. Your system-auth file looks like ours does as far as I can remember.
Just something else you may want to try if you haven't already.
On Thu, 14 Apr 2011 18:55 +0200, "Judith Flo Gaya"jflo@imppc.org wrote:
Hello,
After doing all you suggest with the pki keys I'm stuck in the very same place, the system is able to do ldapsearch but all user auth is not working, I do this in order to configure the auth in the clients # authconfig --disablecachecreds --enableldaps --enableldapauth --ldapserver=ldaps://server.fdqn --ldapbasedn=dc=linux,dc=imppc,dc=org --disablefingerprint --disablewinbind --disablewins --disablesssd --disablesssdauth --disablenis --enablecache --enablelocauthorize --disablemd5 --passalgo=sha512 --updateall
The pam.d files look ok:
# cat /etc/pam.d/system-auth #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid>= 500 quiet auth sufficient pam_ldap.so use_first_pass auth required pam_deny.so
account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid< 500 quiet account [default=bad success=ok user_unknown=ignore] pam_ldap.so account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3 type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_ldap.so use_authtok password required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_ldap.so
This is the message in ldap server when I do id<ldap_user> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 ACCEPT from IP=[::1]:36208 (IP=[::]:636) Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 TLS established tls_ssf=256 ssf=256 Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 EXT oid=1">oid=1.3.6.1.4.1.1466.20037 Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 STARTTLS Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 RESULT oid= err=1 text=TLS already started Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=1 UNBIND Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 closed
Aparently is ok but the id is not known Any ideas? Thanks a lot! j
On 04/14/2011 05:44 PM, Judith Flo Gaya wrote:
Hello Aaron,
On 04/13/2011 09:07 PM, Aaron Richton wrote:
On Wed, 13 Apr 2011, Judith Flo Gaya wrote:
I see, I also have those files that you mention... I created my own CA as lots of tutorials explain.. Then I transmitted it to the clients and used it in the ldap.conf file. Do you suggest me to send those to the server and use them instead of the ones I generated with openssl?
Well, you'll need the CA on the client to match the CA that signed the server's certificate. In other words...if you generated your own CA for both the client and the server, trust issues would be completely expected...
I don't know if I understood you or I didn't make myself clear on that point. I created a CA in the server and the copied the file to the client, is that wrong?
What's your server?
OpenLDAP software is on both sides of the equation; it's just that some clients are NSS, some clients are OpenSSL, some clients are GnuTLS, while ALL servers are OpenSSL.
I was talking about the operating system, for some reason I think that having red hat (with openldap compiled using openssl) and clients with fedora (openldap compiled against moznss) created my problems. Now that you said that this is your case (I think) then it may be something related to... I don't know what.
Well my final problem were not ldapsearch but the user autenticacion. The ldapsaerch showed the whole ldap definitions but if I try to ssh with an ldap user to the machine, I get some TLS negotiation problem ;( That's when I was told that the problem may be caused by the implementation of the ldap client (with moznss support).
Well, when troubleshooting, it's often easiest to look with a narrow scope. Using OpenLDAP software, such as ldapsearch(1) and ldapwhoami(1), will probably offer a better debugging platform than an ssh implementation? One step at a time...
Yes, I totally agree, that's why I setup my own openldap installation and only care about ldapsearch working, then when ldapsearch finally worked, then I start looking at the user auth part, changing passw, etc.. as this part wasn't working and it appear to be a moznss problem, I got stuck... until you arrived, I will try what you suggest about using the pki certs instead of the openssl ones..
Thanks a lot for the suggestion, hope this finally fix the issue. j
-- Judith Flo Gaya Systems Administrator IMPPC e-mail: jflo@imppc.org Tel (+34) 93 554-3079 Fax (+34) 93 465-1472
Institut de Medicina Predictiva i Personalitzada del Càncer Crta Can Ruti, Camí de les Escoles s/n 08916 Badalona, Barcelona, Spain http://www.imppc.org
Hello,
Finally find out in the pam.d files that the passwd file contained this: -password optional pam_gnome_keyring.so use_authtok after removing the use_authtok parameter, the user was able to login, and in general be found by the system.
Changing the password with the passwd command has to be done using the pam_password exop option in the pam_ldap.conf, it's not the best but it works.
Thanks to all for your help, j
On 04/15/2011 11:23 AM, Judith Flo Gaya wrote:
Hello ldap,
In fact in my authconfig instruction I have --enableforcelegacy, but this only works on my f14 clients, rh refuses to accept this option, but I already set the forcelegacy=yes in my /etc/sysconfig/authconfig. At the very beginning sssd was a little crazy... but I have learnt to get rid of it.
How do you set your authconfig system? right now is the only missing part of the puzzle ;(
On 04/14/2011 07:40 PM, ldap@mm.st wrote:
I came in late on this thread, so disregard if this has already been said or is not applicable. Also, we use standard RH packages, so if you are building your own, this may not be any use to you.
We have a few RH6 boxes authenticating against our ldap servers. It's been awhile, but in addition to the CA certs being copied to the clients and the correct perms assigned we had come success enabling legacy mode in RH6 when running authconfig to set up the box. If I recall, in legacy mode sssd does not run and it uses a more RH5 way of authenticating clients. Unfortunately, I don't have a RH6 box in front of me, but you can edit /etc/sysconfig/authconfig to set legacy mode. Then run your authconfig command to set up the box. Also, look at /etc/pam_ldap.conf if you decide to try to authenticate in this manner. The settings in there are like they were in /etc/ldap.conf, RH5. Your system-auth file looks like ours does as far as I can remember.
Just something else you may want to try if you haven't already.
On Thu, 14 Apr 2011 18:55 +0200, "Judith Flo Gaya"jflo@imppc.org wrote:
Hello,
After doing all you suggest with the pki keys I'm stuck in the very same place, the system is able to do ldapsearch but all user auth is not working, I do this in order to configure the auth in the clients # authconfig --disablecachecreds --enableldaps --enableldapauth --ldapserver=ldaps://server.fdqn --ldapbasedn=dc=linux,dc=imppc,dc=org --disablefingerprint --disablewinbind --disablewins --disablesssd --disablesssdauth --disablenis --enablecache --enablelocauthorize --disablemd5 --passalgo=sha512 --updateall
The pam.d files look ok:
# cat /etc/pam.d/system-auth #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid>= 500 quiet auth sufficient pam_ldap.so use_first_pass auth required pam_deny.so
account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid< 500 quiet account [default=bad success=ok user_unknown=ignore] pam_ldap.so account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3 type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_ldap.so use_authtok password required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_ldap.so
This is the message in ldap server when I do id<ldap_user> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 ACCEPT from IP=[::1]:36208 (IP=[::]:636) Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 TLS established tls_ssf=256 ssf=256 Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 EXT oid=1">oid=1.3.6.1.4.1.1466.20037 Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 STARTTLS Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 RESULT oid= err=1 text=TLS already started Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=1 UNBIND Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 closed
Aparently is ok but the id is not known Any ideas? Thanks a lot! j
On 04/14/2011 05:44 PM, Judith Flo Gaya wrote:
Hello Aaron,
On 04/13/2011 09:07 PM, Aaron Richton wrote:
On Wed, 13 Apr 2011, Judith Flo Gaya wrote:
I see, I also have those files that you mention... I created my own CA as lots of tutorials explain.. Then I transmitted it to the clients and used it in the ldap.conf file. Do you suggest me to send those to the server and use them instead of the ones I generated with openssl?
Well, you'll need the CA on the client to match the CA that signed the server's certificate. In other words...if you generated your own CA for both the client and the server, trust issues would be completely expected...
I don't know if I understood you or I didn't make myself clear on that point. I created a CA in the server and the copied the file to the client, is that wrong?
What's your server?
OpenLDAP software is on both sides of the equation; it's just that some clients are NSS, some clients are OpenSSL, some clients are GnuTLS, while ALL servers are OpenSSL.
I was talking about the operating system, for some reason I think that having red hat (with openldap compiled using openssl) and clients with fedora (openldap compiled against moznss) created my problems. Now that you said that this is your case (I think) then it may be something related to... I don't know what.
Well my final problem were not ldapsearch but the user autenticacion. The ldapsaerch showed the whole ldap definitions but if I try to ssh with an ldap user to the machine, I get some TLS negotiation problem ;( That's when I was told that the problem may be caused by the implementation of the ldap client (with moznss support).
Well, when troubleshooting, it's often easiest to look with a narrow scope. Using OpenLDAP software, such as ldapsearch(1) and ldapwhoami(1), will probably offer a better debugging platform than an ssh implementation? One step at a time...
Yes, I totally agree, that's why I setup my own openldap installation and only care about ldapsearch working, then when ldapsearch finally worked, then I start looking at the user auth part, changing passw, etc.. as this part wasn't working and it appear to be a moznss problem, I got stuck... until you arrived, I will try what you suggest about using the pki certs instead of the openssl ones..
Thanks a lot for the suggestion, hope this finally fix the issue. j
-- Judith Flo Gaya Systems Administrator IMPPC e-mail: jflo@imppc.org Tel (+34) 93 554-3079 Fax (+34) 93 465-1472
Institut de Medicina Predictiva i Personalitzada del Càncer Crta Can Ruti, Camí de les Escoles s/n 08916 Badalona, Barcelona, Spain http://www.imppc.org
Have you tried to use the "tls_reqcert never" directive in nslcd.conf (may not apply in your case ?). I wouldn't run this way, just for troubleshooting. Also, in nslcd.conf did I see that you changed "ssl start_tls" to something else. We use "ssl start_tls" in our RH6 boxes. Also, in nslcd.conf we found success using these directives for RH6 (RH5 uses "nss_base_passwd" type directives):
scope one base group ou=Group,o=example.com base passwd ou=People,o=example.com base shadow ou=People,o=example.com
Finally, I'm sure you checked it but with the error below, you should verify you do not have "uri ldaps://ldap.server.com/" (trailing slash important) in any of your client config files since you are using start_tls..
On Fri, 15 Apr 2011 11:23 +0200, "Judith Flo Gaya" jflo@imppc.org wrote:
Hello ldap,
In fact in my authconfig instruction I have --enableforcelegacy, but this only works on my f14 clients, rh refuses to accept this option, but I already set the forcelegacy=yes in my /etc/sysconfig/authconfig. At the very beginning sssd was a little crazy... but I have learnt to get rid of it.
How do you set your authconfig system? right now is the only missing part of the puzzle ;(
On 04/14/2011 07:40 PM, ldap@mm.st wrote:
I came in late on this thread, so disregard if this has already been said or is not applicable. Also, we use standard RH packages, so if you are building your own, this may not be any use to you.
We have a few RH6 boxes authenticating against our ldap servers. It's been awhile, but in addition to the CA certs being copied to the clients and the correct perms assigned we had come success enabling legacy mode in RH6 when running authconfig to set up the box. If I recall, in legacy mode sssd does not run and it uses a more RH5 way of authenticating clients. Unfortunately, I don't have a RH6 box in front of me, but you can edit /etc/sysconfig/authconfig to set legacy mode. Then run your authconfig command to set up the box. Also, look at /etc/pam_ldap.conf if you decide to try to authenticate in this manner. The settings in there are like they were in /etc/ldap.conf, RH5. Your system-auth file looks like ours does as far as I can remember.
Just something else you may want to try if you haven't already.
On Thu, 14 Apr 2011 18:55 +0200, "Judith Flo Gaya"jflo@imppc.org wrote:
Hello,
After doing all you suggest with the pki keys I'm stuck in the very same place, the system is able to do ldapsearch but all user auth is not working, I do this in order to configure the auth in the clients # authconfig --disablecachecreds --enableldaps --enableldapauth --ldapserver=ldaps://server.fdqn --ldapbasedn=dc=linux,dc=imppc,dc=org --disablefingerprint --disablewinbind --disablewins --disablesssd --disablesssdauth --disablenis --enablecache --enablelocauthorize --disablemd5 --passalgo=sha512 --updateall
The pam.d files look ok:
# cat /etc/pam.d/system-auth #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid>= 500 quiet auth sufficient pam_ldap.so use_first_pass auth required pam_deny.so
account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid< 500 quiet account [default=bad success=ok user_unknown=ignore] pam_ldap.so account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3 type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_ldap.so use_authtok password required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_ldap.so
This is the message in ldap server when I do id<ldap_user> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 ACCEPT from IP=[::1]:36208 (IP=[::]:636) Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 TLS established tls_ssf=256 ssf=256 Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 EXT oid=1">oid=1.3.6.1.4.1.1466.20037 Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 STARTTLS Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 RESULT oid= err=1 text=TLS already started Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=1 UNBIND Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 closed
Aparently is ok but the id is not known Any ideas? Thanks a lot! j
On 04/14/2011 05:44 PM, Judith Flo Gaya wrote:
Hello Aaron,
On 04/13/2011 09:07 PM, Aaron Richton wrote:
On Wed, 13 Apr 2011, Judith Flo Gaya wrote:
I see, I also have those files that you mention... I created my own CA as lots of tutorials explain.. Then I transmitted it to the clients and used it in the ldap.conf file. Do you suggest me to send those to the server and use them instead of the ones I generated with openssl?
Well, you'll need the CA on the client to match the CA that signed the server's certificate. In other words...if you generated your own CA for both the client and the server, trust issues would be completely expected...
I don't know if I understood you or I didn't make myself clear on that point. I created a CA in the server and the copied the file to the client, is that wrong?
What's your server?
OpenLDAP software is on both sides of the equation; it's just that some clients are NSS, some clients are OpenSSL, some clients are GnuTLS, while ALL servers are OpenSSL.
I was talking about the operating system, for some reason I think that having red hat (with openldap compiled using openssl) and clients with fedora (openldap compiled against moznss) created my problems. Now that you said that this is your case (I think) then it may be something related to... I don't know what.
Well my final problem were not ldapsearch but the user autenticacion. The ldapsaerch showed the whole ldap definitions but if I try to ssh with an ldap user to the machine, I get some TLS negotiation problem ;( That's when I was told that the problem may be caused by the implementation of the ldap client (with moznss support).
Well, when troubleshooting, it's often easiest to look with a narrow scope. Using OpenLDAP software, such as ldapsearch(1) and ldapwhoami(1), will probably offer a better debugging platform than an ssh implementation? One step at a time...
Yes, I totally agree, that's why I setup my own openldap installation and only care about ldapsearch working, then when ldapsearch finally worked, then I start looking at the user auth part, changing passw, etc.. as this part wasn't working and it appear to be a moznss problem, I got stuck... until you arrived, I will try what you suggest about using the pki certs instead of the openssl ones..
Thanks a lot for the suggestion, hope this finally fix the issue. j
-- Judith Flo Gaya Systems Administrator IMPPC e-mail: jflo@imppc.org Tel (+34) 93 554-3079 Fax (+34) 93 465-1472
Institut de Medicina Predictiva i Personalitzada del Càncer Crta Can Ruti, Camí de les Escoles s/n 08916 Badalona, Barcelona, Spain http://www.imppc.org
-- Judith Flo Gaya Systems Administrator IMPPC e-mail: jflo@imppc.org Tel (+34) 93 554-3079 Fax (+34) 93 465-1472
Institut de Medicina Predictiva i Personalitzada del Càncer Crta Can Ruti, Camí de les Escoles s/n 08916 Badalona, Barcelona, Spain http://www.imppc.org
openldap-technical@openldap.org
-
Aaron Richton -
Dieter Kluenter -
harry.jede＠arcor.de -
Judith Flo Gaya -
ldap＠mm.st -
Quanah Gibson-Mount -
Rich Megginson -
Tom Leach