Hello,
I have configured an openSUSE 11.0 (x86_64) with openldap- server. Also the TLS is activated. All clients are set to "TLS_REQCERT demand" and is working. Then I created client certificates by using the servers Yast2 CA- management. I copied teh client certificates and also the servers "cacert" into the "/etc/openldap/" directory on client computer. With "TLSVerifyClient allow" clients can login, but if I activate the "TLSVerifyClient demand" option in servers slapd.conf no user can perform an login and it causes errors in /var/log/messages: ----------------/var/log/messages---------------- Feb 22 18:50:01 lmvserver slapd[7093]: slap_listener_activate(8): Feb 22 18:50:01 lmvserver slapd[7093]: >>> slap_listener(ldap://) Feb 22 18:50:01 lmvserver slapd[7093]: connection_get(14) Feb 22 18:50:01 lmvserver slapd[7093]: connection_get(14): got connid=107 Feb 22 18:50:01 lmvserver slapd[7093]: connection_read(14): checking for input on id=107 Feb 22 18:50:01 lmvserver slapd[7093]: conn=107 op=0 do_extended Feb 22 18:50:01 lmvserver slapd[7093]: do_extended: oid=1.3.6.1.4.1.1466.20037 Feb 22 18:50:01 lmvserver slapd[7093]: send_ldap_extended: err=0 oid= len=0 Feb 22 18:50:01 lmvserver slapd[7093]: send_ldap_response: msgid=1 tag=120 err=0 Feb 22 18:50:01 lmvserver slapd[7093]: connection_get(14) Feb 22 18:50:01 lmvserver slapd[7093]: connection_get(14): got connid=107 Feb 22 18:50:01 lmvserver slapd[7093]: connection_read(14): checking for input on id=107 Feb 22 18:50:01 lmvserver slapd[7093]: connection_get(14) Feb 22 18:50:01 lmvserver slapd[7093]: connection_get(14): got connid=107 Feb 22 18:50:01 lmvserver slapd[7093]: connection_read(14): checking for input on id=107 Feb 22 18:50:01 lmvserver slapd[7093]: connection_read(14): TLS accept failure error=-1 id=107, closing Feb 22 18:50:01 lmvserver slapd[7093]: connection_closing: readying conn=107 sd=14 for close Feb 22 18:50:01 lmvserver slapd[7093]: connection_close: conn=107 sd=14 Feb 22 18:50:01 lmvserver slapd[7093]: slap_listener_activate(8): Feb 22 18:50:01 lmvserver slapd[7093]: >>> slap_listener(ldap://) Feb 22 18:50:01 lmvserver slapd[7093]: connection_get(14) Feb 22 18:50:01 lmvserver slapd[7093]: connection_get(14): got connid=108 Feb 22 18:50:01 lmvserver slapd[7093]: connection_read(14): checking for input on id=108 Feb 22 18:50:01 lmvserver slapd[7093]: conn=108 op=0 do_extended Feb 22 18:50:01 lmvserver slapd[7093]: do_extended: oid=1.3.6.1.4.1.1466.20037 Feb 22 18:50:01 lmvserver slapd[7093]: send_ldap_extended: err=0 oid= len=0 Feb 22 18:50:01 lmvserver slapd[7093]: send_ldap_response: msgid=1 tag=120 err=0 Feb 22 18:50:01 lmvserver slapd[7093]: connection_get(14) Feb 22 18:50:01 lmvserver slapd[7093]: connection_get(14): got connid=108 Feb 22 18:50:01 lmvserver slapd[7093]: connection_read(14): checking for input on id=108 Feb 22 18:50:01 lmvserver slapd[7093]: connection_get(14) Feb 22 18:50:01 lmvserver slapd[7093]: connection_get(14): got connid=108 Feb 22 18:50:01 lmvserver slapd[7093]: connection_read(14): checking for input on id=108 Feb 22 18:50:01 lmvserver slapd[7093]: connection_read(14): TLS accept failure error=-1 id=108, closing Feb 22 18:50:01 lmvserver slapd[7093]: connection_closing: readying conn=108 sd=14 for close Feb 22 18:50:01 lmvserver slapd[7093]: connection_close: conn=108 sd=14 Feb 22 18:50:01 lmvserver slapd[7093]: slap_listener_activate(8): Feb 22 18:50:01 lmvserver slapd[7093]: >>> slap_listener(ldap://) Feb 22 18:50:01 lmvserver slapd[7093]: connection_get(14) Feb 22 18:50:01 lmvserver slapd[7093]: connection_get(14): got connid=109 Feb 22 18:50:01 lmvserver slapd[7093]: connection_read(14): checking for input on id=109 Feb 22 18:50:01 lmvserver slapd[7093]: conn=109 op=0 do_extended Feb 22 18:50:01 lmvserver slapd[7093]: do_extended: oid=1.3.6.1.4.1.1466.20037 Feb 22 18:50:01 lmvserver slapd[7093]: send_ldap_extended: err=0 oid= len=0 Feb 22 18:50:01 lmvserver slapd[7093]: send_ldap_response: msgid=1 tag=120 err=0 Feb 22 18:50:01 lmvserver slapd[7093]: connection_get(14) Feb 22 18:50:01 lmvserver slapd[7093]: connection_get(14): got connid=109 Feb 22 18:50:01 lmvserver slapd[7093]: connection_read(14): checking for input on id=109 Feb 22 18:50:01 lmvserver slapd[7093]: connection_get(14) Feb 22 18:50:01 lmvserver slapd[7093]: connection_get(14): got connid=109 Feb 22 18:50:01 lmvserver slapd[7093]: connection_read(14): checking for input on id=109 Feb 22 18:50:01 lmvserver slapd[7093]: connection_read(14): TLS accept failure error=-1 id=109, closing Feb 22 18:50:01 lmvserver slapd[7093]: connection_closing: readying conn=109 sd=14 for close Feb 22 18:50:01 lmvserver slapd[7093]: connection_close: conn=109 sd=14 ----------------/var/log/messages---------------- slapd.conf: ---------------/etc/openldap/slapd.conf-------- # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/yast.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/collective.schema include /etc/openldap/schema/dnszone.schema include /etc/openldap/schema/duaconf.schema include /etc/openldap/schema/dyngroup.schema include /etc/openldap/schema/samba3.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/nis.schema # Define global ACLs to disable default read access. pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args # Directives needed to implement policy: access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read
access to attrs=userPassword,userPKCS12 by self write by * auth
access to attrs=shadowLastChange by self write by * read
access to * by * read
####################################################################### # BDB database definitions #######################################################################
loglevel 5 TLSCertificateFile /etc/openldap/servercert.pem TLSCACertificateFile /etc/openldap/cacert.pem TLSCertificateKeyFile /etc/openldap/serverkey.pem TLSVerifyClient demand database bdb suffix "dc=lmv,dc=lmv" rootdn "cn=ldaproot,dc=lmv,dc=lmv" rootpw "???????" directory /mnt/lvm/ldap/ checkpoint 1024 5 cachesize 10000 index objectClass,uidNumber,gidNumber eq index member,mail eq,pres index cn,displayname,uid,sn,givenname sub,eq,pres database monitor ---------------/etc/openldap/slapd.conf-------- ldap.conf (client): --------------/etc/openldap/slapd.conf--------- # # LDAP Defaults # #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never TLS_CACERT /etc/openldap/cacert.pem TLS_CERT /etc/openldap/clientcert_205.pem TLS_KEY /etc/openldap/clientkey_205.pem TLS_REQCERT demand host 192.168.0.201 base dc=lmv,dc=lmv --------------/etc/openldap/slapd.conf---------
What is wrong? The clients certificate "common name" is set to the clients hostname. Is this ok?
Sebastian Reinhardt snr@lmv-hartmannsdorf.de writes:
Hello,
I have configured an openSUSE 11.0 (x86_64) with openldap- server. Also the TLS is activated. All clients are set to "TLS_REQCERT demand" and is working. Then I created client certificates by using the servers Yast2 CA- management. I copied teh client certificates and also the servers "cacert" into the "/etc/openldap/" directory on client computer. With "TLSVerifyClient allow" clients can login, but if I activate the "TLSVerifyClient demand" option in servers slapd.conf no user can perform an login and it causes errors in /var/log/messages:
[...]
What is wrong? The clients certificate "common name" is set to the clients hostname. Is this ok?
Clients don't read slapd.conf(5) but only ldap.conf(5), run slapd with debug level 3 to analyse the tls session.
-Dieter
Dieter Kluenter schrieb:
Sebastian Reinhardt snr@lmv-hartmannsdorf.de writes:
Hello,
I have configured an openSUSE 11.0 (x86_64) with openldap- server. Also the TLS is activated. All clients are set to "TLS_REQCERT demand" and is working. Then I created client certificates by using the servers Yast2 CA- management. I copied teh client certificates and also the servers "cacert" into the "/etc/openldap/" directory on client computer. With "TLSVerifyClient allow" clients can login, but if I activate the "TLSVerifyClient demand" option in servers slapd.conf no user can perform an login and it causes errors in /var/log/messages:
[...]
What is wrong? The clients certificate "common name" is set to the clients hostname. Is this ok?
Clients don't read slapd.conf(5) but only ldap.conf(5), run slapd with debug level 3 to analyse the tls session.
-Dieter
Hello Dieter,
Now I have set the loglevel to "3" and I get the following output if I try to login (still fails): -------------------/var/log/messages--------------------------------------------------------------------- Feb 25 16:41:49 lmvserver slapd[11737]: slap_listener_activate(8): Feb 25 16:41:49 lmvserver slapd[11737]: >>> slap_listener(ldap://) Feb 25 16:41:49 lmvserver slapd[11737]: connection_get(13): got connid=0 Feb 25 16:41:49 lmvserver slapd[11737]: connection_read(13): checking for input on id=0 Feb 25 16:41:49 lmvserver slapd[11737]: conn=0 op=0 do_extended Feb 25 16:41:49 lmvserver slapd[11737]: send_ldap_extended: err=0 oid= len=0 Feb 25 16:41:49 lmvserver slapd[11737]: send_ldap_response: msgid=1 tag=120 err=0 Feb 25 16:41:49 lmvserver slapd[11737]: connection_get(13): got connid=0 Feb 25 16:41:49 lmvserver slapd[11737]: connection_read(13): checking for input on id=0 Feb 25 16:41:49 lmvserver slapd[11737]: connection_get(13): got connid=0 Feb 25 16:41:49 lmvserver slapd[11737]: connection_read(13): checking for input on id=0 Feb 25 16:41:49 lmvserver slapd[11737]: connection_read(13): TLS accept failure error=-1 id=0, closing Feb 25 16:41:49 lmvserver slapd[11737]: connection_closing: readying conn=0 sd=13 for close Feb 25 16:41:49 lmvserver slapd[11737]: connection_close: conn=0 sd=13 Feb 25 16:41:49 lmvserver kdm: :0[11544]: nss_ldap: could not search LDAP server - Server is unavailable Feb 25 16:41:49 lmvserver slapd[11737]: slap_listener_activate(8): Feb 25 16:41:49 lmvserver slapd[11737]: >>> slap_listener(ldap://) Feb 25 16:41:49 lmvserver slapd[11737]: connection_get(13): got connid=1 Feb 25 16:41:49 lmvserver slapd[11737]: connection_read(13): checking for input on id=1 Feb 25 16:41:49 lmvserver slapd[11737]: conn=1 op=0 do_extended Feb 25 16:41:49 lmvserver slapd[11737]: send_ldap_extended: err=0 oid= len=0 Feb 25 16:41:49 lmvserver slapd[11737]: send_ldap_response: msgid=1 tag=120 err=0 Feb 25 16:41:49 lmvserver slapd[11737]: connection_get(13): got connid=1 Feb 25 16:41:49 lmvserver slapd[11737]: connection_read(13): checking for input on id=1 Feb 25 16:41:49 lmvserver slapd[11737]: connection_get(13): got connid=1 Feb 25 16:41:49 lmvserver slapd[11737]: connection_read(13): checking for input on id=1 Feb 25 16:41:49 lmvserver slapd[11737]: connection_read(13): TLS accept failure error=-1 id=1, closing Feb 25 16:41:49 lmvserver slapd[11737]: connection_closing: readying conn=1 sd=13 for close Feb 25 16:41:49 lmvserver slapd[11737]: connection_close: conn=1 sd=13 Feb 25 16:41:49 lmvserver kdm: :0[11544]: pam_ldap: ldap_starttls_s: Connect error -------------------/var/log/messages---------------------------------------------------------------------
I am not sure, if this is an configuration or certificate error? Do You understand this output above?
Hello Sebastian,
Sebastian Reinhardt snr@lmv-hartmannsdorf.de writes:
Dieter Kluenter schrieb:
Sebastian Reinhardt snr@lmv-hartmannsdorf.de writes:
Hello,
I have configured an openSUSE 11.0 (x86_64) with openldap- server. Also the TLS is activated. All clients are set to "TLS_REQCERT demand" and is working. Then I created client certificates by using the servers Yast2 CA- management. I copied teh client certificates and also the servers "cacert" into the "/etc/openldap/" directory on client computer. With "TLSVerifyClient allow" clients can login, but if I activate the "TLSVerifyClient demand" option in servers slapd.conf no user can perform an login and it causes errors in /var/log/messages:
[...]
What is wrong? The clients certificate "common name" is set to the clients hostname. Is this ok?
Clients don't read slapd.conf(5) but only ldap.conf(5), run slapd with debug level 3 to analyse the tls session.
-Dieter
Hello Dieter,
Now I have set the loglevel to "3" and I get the following output if I try to login (still fails):
loglevel is != debug level, man slapd(8), run slapd -d3
-------------------/var/log/messages---------------------------------------------------------------------
[...]
Feb 25 16:41:49 lmvserver kdm: :0[11544]: nss_ldap: could not search LDAP server - Server is unavailable
[...]
Feb 25 16:41:49 lmvserver kdm: :0[11544]: pam_ldap: ldap_starttls_s: Connect error -------------------/var/log/messages---------------------------------------------------------------------
I am not sure, if this is an configuration or certificate error? Do You understand this output above?
The clients are nss_ldap and pam_ldap, check the clients configuration for starttls parameters. With debug level 3 you should see something like
TLS trace: SSL_accept:before/accept initialization tls_read: want=11, got=11 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 certificate request A tls_write: want=1931, written=1931 TLS trace: SSL_accept:SSLv3 flush data TLS trace: SSL3 alert write:warning:close notify
-Dieter
Dieter Kluenter schrieb:
Hello Sebastian,
Sebastian Reinhardt snr@lmv-hartmannsdorf.de writes:
Dieter Kluenter schrieb:
Sebastian Reinhardt snr@lmv-hartmannsdorf.de writes:
Hello,
I have configured an openSUSE 11.0 (x86_64) with openldap- server. Also the TLS is activated. All clients are set to "TLS_REQCERT demand" and is working. Then I created client certificates by using the servers Yast2 CA- management. I copied teh client certificates and also the servers "cacert" into the "/etc/openldap/" directory on client computer. With "TLSVerifyClient allow" clients can login, but if I activate the "TLSVerifyClient demand" option in servers slapd.conf no user can perform an login and it causes errors in /var/log/messages:
[...]
What is wrong? The clients certificate "common name" is set to the clients hostname. Is this ok?
Clients don't read slapd.conf(5) but only ldap.conf(5), run slapd with debug level 3 to analyse the tls session.
-Dieter
Hello Dieter,
Now I have set the loglevel to "3" and I get the following output if I try to login (still fails):
loglevel is != debug level, man slapd(8), run slapd -d3
-------------------/var/log/messages---------------------------------------------------------------------
[...]
Feb 25 16:41:49 lmvserver kdm: :0[11544]: nss_ldap: could not search LDAP server - Server is unavailable
[...]
Feb 25 16:41:49 lmvserver kdm: :0[11544]: pam_ldap: ldap_starttls_s: Connect error -------------------/var/log/messages---------------------------------------------------------------------
I am not sure, if this is an configuration or certificate error? Do You understand this output above?
The clients are nss_ldap and pam_ldap, check the clients configuration for starttls parameters. With debug level 3 you should see something like
TLS trace: SSL_accept:before/accept initialization tls_read: want=11, got=11 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 certificate request A tls_write: want=1931, written=1931 TLS trace: SSL_accept:SSLv3 flush data TLS trace: SSL3 alert write:warning:close notify
-Dieter
Sorry. I had not configured the pam_ldap (/etc/ldap.conf) config file properly. The certifikate entries were missing.
Here is my /etc/ldap.conf: -------------------/etc/ldap.conf------------------------------------------- host 127.0.0.1 base dc=lmv,dc=lmv #uri ldap://127.0.0.1/ #uri ldaps://127.0.0.1/ #uri ldapi://%2fvar%2frun%2fldapi_sock/ #ldap_version 3 #binddn cn=proxyuser,dc=example,dc=com #bindpw secret rootbinddn cn=ldaproot,dc=lmv,dc=lmv port 389 scope sub scope one scope base #timelimit 30 #bind_timelimit 30 bind_policy soft #nss_connect_policy persist #idle_timelimit 3600 #nss_paged_results yes #pagesize 1000 #pam_filter objectclass=account #pam_login_attribute uid pam_lookup_policy yes #pam_check_host_attr yes #pam_check_service_attr yes #pam_groupdn cn=PAM,ou=Groups,dc=example,dc=com #pam_member_attribute uniquemember #pam_min_uid 0 #pam_max_uid 0 #pam_login_attribute userPrincipalName #pam_template_login_attribute uid #pam_template_login nobody #pam_password clear #pam_password crypt #pam_password nds #pam_password racf #pam_password ad pam_password crypt #pam_password_prohibit_message Please visit http://internal to change your password. #nss_initgroups backlink nss_initgroups_ignoreusers root,ldap #nss_schema rfc2307bis nss_schema nis nss_base_passwd ou=users,dc=lmv,dc=lmv nss_base_shadow ou=users,dc=lmv,dc=lmv nss_base_group ou=groups,dc=lmv,dc=lmv nss_base_hosts ou=hosts,dc=lmv,dc=lmv #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 #nss_map_attribute rfc2307attribute mapped_attribute #nss_map_objectclass rfc2307objectclass mapped_objectclass nss_map_attribute uniqueMember member #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 #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 #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 #nss_map_attribute userPassword authPassword #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 #nss_map_objectclass automountMap nisMap #nss_map_attribute automountMapName nisMapName #nss_map_objectclass automount nisObject #nss_map_attribute automountKey cn #nss_map_attribute automountInformation nisMapEntry #ssl on sslpath /etc/openldap/ ssl start_tls ldap_version 3 pam_filter objectclass=posixAccount nss_base_passwd ou=users,dc=lmv,dc=lmv nss_base_shadow ou=users,dc=lmv,dc=lmv nss_base_group ou=groups,dc=lmv,dc=lmv tls_checkpeer yes #ssl on tls_cacertfile /etc/openldap/cacert.pem tls_cacertdir /etc/openldap/ #tls_randfile /var/run/egd-pool #tls_ciphers TLSv1 tls_cert /etc/openldap/clientcert_201.pem tls_key /etc/openldap/clientkey_201.pem #sasl_secprops maxssf=0 #krb5_ccname FILE:/etc/.ldapcache -------------------/etc/ldap.conf-------------------------------------------
And also my /etc/openldap/ldap.conf: -------------------/etc/openldap/ldap.conf----------------------------- TLS_CACERT /etc/openldap/cacert.pem TLS_CERT /etc/openldap/clientcert_201.pem TLS_KEY /etc/openldap/clientkey_201.pem TLS_REQCERT demand host 127.0.0.1 base dc=lmv,dc=lmv -------------------/etc/openldap/ldap.conf----------------------------- -------------------/etc/nsswitch.conf------------------------------------- passwd: compat group: files ldap hosts: files mdns4_minimal [NOTFOUND=return] dns networks: files dns services: files ldap protocols: files rpc: files ethers: files netmasks: files netgroup: files ldap publickey: files bootparams: files automount: files nis aliases: files ldap passwd_compat: ldap -------------------/etc/nsswitch.conf-------------------------------------
Now I have started with "-d 3" and I get some output:
-------------------------------------------------------------------------------------------- slap_listener_activate(8):
slap_listener(ldap://)
connection_get(13): got connid=32 connection_read(13): checking for input on id=32 ber_get_next ldap_read: want=8, got=8 0000: 30 1d 02 01 01 77 18 80 0....w.. ldap_read: want=23, got=23 0000: 16 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e 31 34 36 .1.3.6.1.4.1.146 0010: 36 2e 32 30 30 33 37 6.20037 ber_get_next: tag 0x30 len 29 contents: ber_get_next ldap_read: want=8 error=Resource temporarily unavailable conn=32 op=0 do_extended ber_scanf fmt ({m) ber: send_ldap_extended: err=0 oid= len=0 send_ldap_response: msgid=1 tag=120 err=0 ber_flush2: 14 bytes to sd 13 0000: 30 0c 02 01 01 78 07 0a 01 00 04 00 04 00 0....x........ ldap_write: want=14, written=14 0000: 30 0c 02 01 01 78 07 0a 01 00 04 00 04 00 0....x........ slap_listener_activate(8): connection_get(13): got connid=32 connection_read(13): checking for input on id=32
slap_listener(ldap://)
TLS trace: SSL_accept:before/accept initialization tls_read: want=11, got=7 0000: 30 05 02 01 02 42 00 0....B. tls_read: want=4, got=0
TLS: can't accept. connection_read(13): TLS accept failure error=-1 id=32, closing connection_closing: readying conn=32 sd=13 for close connection_close: conn=32 sd=13 connection_get(14): got connid=33 connection_read(14): checking for input on id=33 ber_get_next ldap_read: want=8, got=8 0000: 30 1d 02 01 01 77 18 80 0....w.. ldap_read: want=23, got=23 0000: 16 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e 31 34 36 .1.3.6.1.4.1.146 0010: 36 2e 32 30 30 33 37 6.20037 ber_get_next: tag 0x30 len 29 contents: ber_get_next ldap_read: want=8 error=Resource temporarily unavailable conn=33 op=0 do_extended ber_scanf fmt ({m) ber: send_ldap_extended: err=0 oid= len=0 send_ldap_response: msgid=1 tag=120 err=0 ber_flush2: 14 bytes to sd 14 0000: 30 0c 02 01 01 78 07 0a 01 00 04 00 04 00 0....x........ ldap_write: want=14, written=14 0000: 30 0c 02 01 01 78 07 0a 01 00 04 00 04 00 0....x........ connection_get(14): got connid=33 connection_read(14): checking for input on id=33 TLS trace: SSL_accept:before/accept initialization tls_read: want=11, got=7 0000: 30 05 02 01 02 42 00 0....B. tls_read: want=4, got=0
TLS: can't accept. connection_read(14): TLS accept failure error=-1 id=33, closing connection_closing: readying conn=33 sd=14 for close connection_close: conn=33 sd=14 slap_listener_activate(8):
slap_listener(ldap://)
connection_get(13): got connid=34 connection_read(13): checking for input on id=34 ber_get_next ldap_read: want=8, got=8 0000: 30 1d 02 01 01 77 18 80 0....w.. ldap_read: want=23, got=23 0000: 16 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e 31 34 36 .1.3.6.1.4.1.146 0010: 36 2e 32 30 30 33 37 6.20037 ber_get_next: tag 0x30 len 29 contents: ber_get_next ldap_read: want=8 error=Resource temporarily unavailable conn=34 op=0 do_extended ber_scanf fmt ({m) ber: send_ldap_extended: err=0 oid= len=0 send_ldap_response: msgid=1 tag=120 err=0 ber_flush2: 14 bytes to sd 13 0000: 30 0c 02 01 01 78 07 0a 01 00 04 00 04 00 0....x........ ldap_write: want=14, written=14 0000: 30 0c 02 01 01 78 07 0a 01 00 04 00 04 00 0....x........ connection_get(13): got connid=34 connection_read(13): checking for input on id=34 TLS trace: SSL_accept:before/accept initialization tls_read: want=11, got=7 0000: 30 05 02 01 02 42 00 0....B. tls_read: want=4, got=0
TLS: can't accept. connection_read(13): TLS accept failure error=-1 id=34, closing connection_closing: readying conn=34 sd=13 for close connection_close: conn=34 sd=13 -------------------------------------------------------------------------------------------- What is wrong? The certificate is not accepted? Is the certificae not ok?
Hello Sebastian,
Sebastian Reinhardt snr@lmv-hartmannsdorf.de writes:
Dieter Kluenter schrieb:
Hello Sebastian,
Sebastian Reinhardt snr@lmv-hartmannsdorf.de writes:
Dieter Kluenter schrieb:
Sebastian Reinhardt snr@lmv-hartmannsdorf.de writes:
[...]
Now I have set the loglevel to "3" and I get the following output if I try to login (still fails):
loglevel is != debug level, man slapd(8), run slapd -d3
-------------------/var/log/messages---------------------------------------------------------------------
[...]
Feb 25 16:41:49 lmvserver kdm: :0[11544]: nss_ldap: could not search LDAP server - Server is unavailable
[...]
Feb 25 16:41:49 lmvserver kdm: :0[11544]: pam_ldap: ldap_starttls_s: Connect error -------------------/var/log/messages---------------------------------------------------------------------
I am not sure, if this is an configuration or certificate error? Do You understand this output above?
The clients are nss_ldap and pam_ldap, check the clients configuration for starttls parameters. With debug level 3 you should see something like
[...]
Sorry. I had not configured the pam_ldap (/etc/ldap.conf) config file properly. The certifikate entries were missing.
Here is my /etc/ldap.conf: -------------------/etc/ldap.conf------------------------------------------- host 127.0.0.1
This Hostadress is probabely not the certifcate DN
base dc=lmv,dc=lmv #uri ldap://127.0.0.1/ #uri ldaps://127.0.0.1/ #uri ldapi://%2fvar%2frun%2fldapi_sock/ #ldap_version 3 #binddn cn=proxyuser,dc=example,dc=com #bindpw secret rootbinddn cn=ldaproot,dc=lmv,dc=lmv
To bind as rootdn is not a good idea.
[...]
#ssl on sslpath /etc/openldap/
although it is not the base of your problem, omit sslpath
ssl start_tls ldap_version 3 pam_filter objectclass=posixAccount nss_base_passwd ou=users,dc=lmv,dc=lmv nss_base_shadow ou=users,dc=lmv,dc=lmv nss_base_group ou=groups,dc=lmv,dc=lmv tls_checkpeer yes #ssl on tls_cacertfile /etc/openldap/cacert.pem tls_cacertdir /etc/openldap/
omit tls_cacertdir
#tls_randfile /var/run/egd-pool #tls_ciphers TLSv1 tls_cert /etc/openldap/clientcert_201.pem tls_key /etc/openldap/clientkey_201.pem #sasl_secprops maxssf=0 #krb5_ccname FILE:/etc/.ldapcache -------------------/etc/ldap.conf-------------------------------------------
And also my /etc/openldap/ldap.conf: -------------------/etc/openldap/ldap.conf----------------------------- TLS_CACERT /etc/openldap/cacert.pem TLS_CERT /etc/openldap/clientcert_201.pem TLS_KEY /etc/openldap/clientkey_201.pem TLS_REQCERT demand host 127.0.0.1
[...]
TLS: can't accept. connection_read(14): TLS accept failure error=-1 id=33, closing
[...]
What is wrong? The certificate is not accepted? Is the certificae not ok?
I presume the certificate DN is not in conformance with the called URI
To test this, just do a ldapsearch with a simple bind and starttls, that is ldapsearch -x -D some DN -w passwd -ZZ ldap://my.remote.host -b "" -s base +
You may do a strace on this process, that is "strace -o /tmp/myfile.txt ldapsearch ...." As you use a host certificate, on a successful session ou may see something like TLS trace: SSL_accept:SSLv3 flush data connection_read(19): unable to get TLS client DN, error=49 id=8 But despite a error 49, the session is established.
-Dieter
Dieter Kluenter schrieb:
Hello Sebastian,
Sebastian Reinhardt snr@lmv-hartmannsdorf.de writes:
Dieter Kluenter schrieb:
Hello Sebastian,
Sebastian Reinhardt snr@lmv-hartmannsdorf.de writes:
Dieter Kluenter schrieb:
Sebastian Reinhardt snr@lmv-hartmannsdorf.de writes:
[...]
Now I have set the loglevel to "3" and I get the following output if I try to login (still fails):
loglevel is != debug level, man slapd(8), run slapd -d3
-------------------/var/log/messages---------------------------------------------------------------------
[...]
Feb 25 16:41:49 lmvserver kdm: :0[11544]: nss_ldap: could not search LDAP server - Server is unavailable
[...]
Feb 25 16:41:49 lmvserver kdm: :0[11544]: pam_ldap: ldap_starttls_s: Connect error -------------------/var/log/messages---------------------------------------------------------------------
I am not sure, if this is an configuration or certificate error? Do You understand this output above?
The clients are nss_ldap and pam_ldap, check the clients configuration for starttls parameters. With debug level 3 you should see something like
[...]
Sorry. I had not configured the pam_ldap (/etc/ldap.conf) config file properly. The certifikate entries were missing.
Here is my /etc/ldap.conf: -------------------/etc/ldap.conf------------------------------------------- host 127.0.0.1
This Hostadress is probabely not the certifcate DN
base dc=lmv,dc=lmv #uri ldap://127.0.0.1/ #uri ldaps://127.0.0.1/ #uri ldapi://%2fvar%2frun%2fldapi_sock/ #ldap_version 3 #binddn cn=proxyuser,dc=example,dc=com #bindpw secret rootbinddn cn=ldaproot,dc=lmv,dc=lmv
To bind as rootdn is not a good idea.
[...]
#ssl on sslpath /etc/openldap/
although it is not the base of your problem, omit sslpath
ssl start_tls ldap_version 3 pam_filter objectclass=posixAccount nss_base_passwd ou=users,dc=lmv,dc=lmv nss_base_shadow ou=users,dc=lmv,dc=lmv nss_base_group ou=groups,dc=lmv,dc=lmv tls_checkpeer yes #ssl on tls_cacertfile /etc/openldap/cacert.pem tls_cacertdir /etc/openldap/
omit tls_cacertdir
#tls_randfile /var/run/egd-pool #tls_ciphers TLSv1 tls_cert /etc/openldap/clientcert_201.pem tls_key /etc/openldap/clientkey_201.pem #sasl_secprops maxssf=0 #krb5_ccname FILE:/etc/.ldapcache -------------------/etc/ldap.conf-------------------------------------------
And also my /etc/openldap/ldap.conf: -------------------/etc/openldap/ldap.conf----------------------------- TLS_CACERT /etc/openldap/cacert.pem TLS_CERT /etc/openldap/clientcert_201.pem TLS_KEY /etc/openldap/clientkey_201.pem TLS_REQCERT demand host 127.0.0.1
[...]
TLS: can't accept. connection_read(14): TLS accept failure error=-1 id=33, closing
[...]
What is wrong? The certificate is not accepted? Is the certificae not ok?
I presume the certificate DN is not in conformance with the called URI
To test this, just do a ldapsearch with a simple bind and starttls, that is ldapsearch -x -D some DN -w passwd -ZZ ldap://my.remote.host -b "" -s base +
You may do a strace on this process, that is "strace -o /tmp/myfile.txt ldapsearch ...." As you use a host certificate, on a successful session ou may see something like TLS trace: SSL_accept:SSLv3 flush data connection_read(19): unable to get TLS client DN, error=49 id=8 But despite a error 49, the session is established.
-Dieter
Hello,
As I tried to perform "ldapsearch" with TLS enabled I got some output about "version trouble" of openldap server and client libraries. But now I solved this problem and I have configured "pam_ldap" again. The login with "TLSVerifyClient demand" (enabled in slapd.conf) works, but not with "tls_checkpeer yes" in "/etc/ldap.conf". If "tls_checkpeer" is "yes", the login is not possible (output: "Permissions on the password database may be too restrictive").
The "strace -o /tmp/ldapsearch.txt ldapsearch -d 1 -x -ZZ -h 192.168.0.201 "(uid=*)" " is creating command line output: ------------------------------------------------------------------------------------------ ldap_create ldap_url_parse_ext(ldap://192.168.0.201) 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 192.168.0.201:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.0.201:389 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 0x613090 msgid 1 wait4msg ld 0x613090 msgid 1 (infinite timeout) wait4msg continue ld 0x613090 msgid 1 all 1 ** ld 0x613090 Connections: * host: 192.168.0.201 port: 389 (default) refcnt: 2 status: Connected last used: Mon Mar 2 22:23:57 2009
** ld 0x613090 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x613090 request count 1 (abandoned 0) ** ld 0x613090 Response Queue: Empty ld 0x613090 response count 0 ldap_chkResponseList ld 0x613090 msgid 1 all 1 ldap_chkResponseList returns ld 0x613090 NULL ldap_int_select read1msg: ld 0x613090 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 12 contents: read1msg: ld 0x613090 msgid 1 message type extended-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x613090 0 new referrals read1msg: mark request completed, ld 0x613090 msgid 1 request done: ld 0x613090 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_parse_extended_result ber_scanf fmt ({eAA) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 1, err: 0, subject: /C=DE/ST=Sachsen/L=Hartmannsdorf-Reichenau/O=LMV Landmaschinenvertrieb- und Service GmbH/OU=Computer/CN=lmvserver/emailAddress=snr@lmv-hartmannsdorf.de, issuer: /C=DE/ST=Sachsen/L=Hartmannsdorf-Reichenau/O=LMV Landmaschinenvertrieb- und Service GmbH/OU=Computer/CN=lmvserver/emailAddress=snr@lmv-hartmannsdorf.de TLS certificate verification: depth: 0, err: 0, subject: /C=DE/ST=Sachsen/L=Hartmannsdorf-Reichenau/O=LMV Landmaschinenvertrieb- und Service GmbH/OU=Computer/CN=lmvserver/emailAddress=snr@lmv-hartmannsdorf.de, issuer: /C=DE/ST=Sachsen/L=Hartmannsdorf-Reichenau/O=LMV Landmaschinenvertrieb- und Service GmbH/OU=Computer/CN=lmvserver/emailAddress=snr@lmv-hartmannsdorf.de TLS trace: SSL_connect:SSLv3 read server certificate A TLS trace: SSL_connect:SSLv3 read server certificate request A TLS trace: SSL_connect:SSLv3 read server done A TLS trace: SSL_connect:SSLv3 write client certificate A TLS trace: SSL_connect:SSLv3 write client key exchange A TLS trace: SSL_connect:SSLv3 write change cipher spec A TLS trace: SSL_connect:SSLv3 write finished A TLS trace: SSL_connect:SSLv3 flush data TLS trace: SSL3 alert read:fatal:handshake failure TLS trace: SSL_connect:failed in SSLv3 read finished A TLS: can't connect: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure. ldap_err2string ldap_start_tls: Connect error (-11) ------------------------------------------------------------------------------------------
For strace output take a look at the attached file, please. I think that server and client do not comunicate via TLS, or do they? And why can I login, but not search (with "tls_checkpeer no")?
Hello,
Sebastian Reinhardt snr@lmv-hartmannsdorf.de writes:
Dieter Kluenter schrieb:
Hello Sebastian,
Sebastian Reinhardt snr@lmv-hartmannsdorf.de writes:
Dieter Kluenter schrieb:
Hello Sebastian,
Sebastian Reinhardt snr@lmv-hartmannsdorf.de writes:
Dieter Kluenter schrieb:
Sebastian Reinhardt snr@lmv-hartmannsdorf.de writes:
[...]
As I tried to perform "ldapsearch" with TLS enabled I got some output about "version trouble" of openldap server and client libraries. But now I solved this problem and I have configured "pam_ldap" again. The login with "TLSVerifyClient demand" (enabled in slapd.conf) works, but not with "tls_checkpeer yes" in "/etc/ldap.conf". If "tls_checkpeer" is "yes", the login is not possible (output: "Permissions on the password database may be too restrictive").
The "strace -o /tmp/ldapsearch.txt ldapsearch -d 1 -x -ZZ -h 192.168.0.201 "(uid=*)" " is creating command line output:
[...]
For strace output take a look at the attached file, please. I think that server and client do not comunicate via TLS, or do they? And why can I login, but not search (with "tls_checkpeer no")?
Please check the output of openssl x509 -in <server-key> -text | grep Subject
compare the CN value of Subject with your -h value of ldapsearch and the host configuration in /etc/ldap.conf
-Dieter
"Dieter Kluenter" dieter@dkluenter.de writes:
Hello,
Sebastian Reinhardt snr@lmv-hartmannsdorf.de writes:
Dieter Kluenter schrieb:
Hello Sebastian,
Sebastian Reinhardt snr@lmv-hartmannsdorf.de writes:
Dieter Kluenter schrieb:
Hello Sebastian,
Sebastian Reinhardt snr@lmv-hartmannsdorf.de writes:
Dieter Kluenter schrieb:
> Sebastian Reinhardt snr@lmv-hartmannsdorf.de writes:
[...]
As I tried to perform "ldapsearch" with TLS enabled I got some output about "version trouble" of openldap server and client libraries. But now I solved this problem and I have configured "pam_ldap" again. The login with "TLSVerifyClient demand" (enabled in slapd.conf) works, but not with "tls_checkpeer yes" in "/etc/ldap.conf". If "tls_checkpeer" is "yes", the login is not possible (output: "Permissions on the password database may be too restrictive").
The "strace -o /tmp/ldapsearch.txt ldapsearch -d 1 -x -ZZ -h 192.168.0.201 "(uid=*)" " is creating command line output:
[...]
For strace output take a look at the attached file, please. I think that server and client do not comunicate via TLS, or do they? And why can I login, but not search (with "tls_checkpeer no")?
Please check the output of openssl x509 -in <server-key> -text | grep Subject
sorry, that should read openssl x509 -in <server-certificate> -text | grep Subject
compare the CN value of Subject with your -h value of ldapsearch and the host configuration in /etc/ldap.conf
-Ddieter
Hello Dieter,
IT WORKS - partialy....
I have got it working from one client. The last problem was, I used host names in certificates and ip's in /etc/ldap.conf. Because I red in comments of ldap.conf, that server must be resolveable without ldap.
But I like to use the server as an workstation, too. So I have configured the client part (certificates and ldap.conf) same as the "real" client pc, but I can not perform a user login at kdm on server. The output of "slapd -d 3..." shows an error "TLS certificate verification: Error, unable to get local issuer certificate". Why? I use the same "cacert" and an own client cert' which is created in same way like the client certs of the other client. Or should I use the server certificate as client one, too?
Here is the output during login (I cut some "hex"- lines):
slap_listener_activate(8):
slap_listener(ldap://)
connection_get(24): got connid=36 connection_read(24): checking for input on id=36 ber_get_next ldap_read: want=8, got=8 0000: 30 1d 02 01 01 77 18 80 0....w.. ldap_read: want=23, got=23 0000: 16 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e 31 34 36 .1.3.6.1.4.1.146 0010: 36 2e 32 30 30 33 37 6.20037 ber_get_next: tag 0x30 len 29 contents: ber_get_next ldap_read: want=8 error=Resource temporarily unavailable conn=36 op=0 do_extended ber_scanf fmt ({m) ber: send_ldap_extended: err=0 oid= len=0 send_ldap_response: msgid=1 tag=120 err=0 ber_flush2: 14 bytes to sd 24 0000: 30 0c 02 01 01 78 07 0a 01 00 04 00 04 00 0....x........ ldap_write: want=14, written=14 0000: 30 0c 02 01 01 78 07 0a 01 00 04 00 04 00 0....x........ connection_get(24): got connid=36 connection_read(24): checking for input on id=36 TLS trace: SSL_accept:before/accept initialization tls_read: want=11, got=11 0000: 80 86 01 03 01 00 5d 00 00 00 20 ......]... tls_read: want=125, got=125 0000: 00 00 39 00 00 38 00 00 35 00 00 88 00 00 87 00 ..9..8..5....... 0010: 00 84 00 00 16 00 00 13 00 00 0a 07 00 c0 00 00 ................ 0020: 33 00 00 32 00 00 2f 00 00 45 00 00 44 00 00 41 3..2../..E..D..A 0030: 03 00 80 00 00 05 00 00 04 01 00 80 00 00 15 00 ................ 0040: 00 12 00 00 09 06 00 40 00 00 14 00 00 11 00 00 .......@........ 0050: 08 00 00 06 04 00 80 00 00 03 02 00 80 0b 27 96 ..............'. 0060: 15 ac 75 97 72 09 93 a8 cf f3 57 d9 a4 76 34 69 ..u.r.....W..v4i 0070: 0a a2 ae 9d cf d9 e4 10 c5 08 66 b9 26 ..........f.& 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 certificate request A tls_write: want=1778, written=1778 0000: 16 03 01 00 4a 02 00 00 46 03 01 49 b0 67 40 b3 ....J...F..I.g@. . . . 06f0: 00 00 .. TLS trace: SSL_accept:SSLv3 flush data tls_read: want=5 error=Resource temporarily unavailable TLS trace: SSL_accept:error in SSLv3 read client certificate A TLS trace: SSL_accept:error in SSLv3 read client certificate A connection_get(24): got connid=36 connection_read(24): checking for input on id=36 tls_read: want=5, got=5 0000: 16 03 01 05 d4 ..... tls_read: want=1492, got=1492 0000: 0b 00 05 d0 00 05 cd 00 05 ca 30 82 05 c6 30 82 ..........0...0. . . . 05d0: 59 d2 29 be Y.). TLS certificate verification: depth: 0, err: 20, subject: /C=DE/ST=Saxony/L=Hartmannsdorf/O=LMV Landmaschinenvertrieb- und Service GmbH/OU=Computer/CN=lmvws1/emailAddress=snr@lmv-hartmannsdorf.de, issuer: /C=DE/ST=Saxony/L=Hartmannsdorf/O=LMV Landmaschinenvertrieb- und Service GmbH/OU=Computer/CN=Sebastian Reinhardt/emailAddress=snr@lmv-hartmannsdorf.de TLS certificate verification: Error, unable to get local issuer certificate tls_write: want=7, written=7 0000: 15 03 01 00 02 02 30 ......0 TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_accept:error in SSLv3 read client certificate B TLS: can't accept. TLS: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned s3_srvr.c:2564 connection_read(24): TLS accept failure error=-1 id=36, closing connection_closing: readying conn=36 sd=24 for close connection_close: conn=36 sd=24 slap_listener_activate(8):
slap_listener(ldap://)
connection_get(24): got connid=37 connection_read(24): checking for input on id=37 ber_get_next ldap_read: want=8, got=8 0000: 30 1d 02 01 01 77 18 80 0....w.. ldap_read: want=23, got=23 0000: 16 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e 31 34 36 .1.3.6.1.4.1.146 0010: 36 2e 32 30 30 33 37 6.20037 ber_get_next: tag 0x30 len 29 contents: ber_get_next ldap_read: want=8 error=Resource temporarily unavailable conn=37 op=0 do_extended ber_scanf fmt ({m) ber: send_ldap_extended: err=0 oid= len=0 send_ldap_response: msgid=1 tag=120 err=0 ber_flush2: 14 bytes to sd 24 0000: 30 0c 02 01 01 78 07 0a 01 00 04 00 04 00 0....x........ ldap_write: want=14, written=14 0000: 30 0c 02 01 01 78 07 0a 01 00 04 00 04 00 0....x........ connection_get(24): got connid=37 connection_read(24): checking for input on id=37 TLS trace: SSL_accept:before/accept initialization tls_read: want=11, got=11 0000: 80 86 01 03 01 00 5d 00 00 00 20 ......]... tls_read: want=125, got=125 0000: 00 00 39 00 00 38 00 00 35 00 00 88 00 00 87 00 ..9..8..5....... . . . 0070: 89 48 20 a2 5a e3 8f 57 e0 e2 3e fa a5 .H .Z..W..>.. 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 certificate request A tls_write: want=1778, written=1778 0000: 16 03 01 00 4a 02 00 00 46 03 01 49 b0 67 40 c4 ....J...F..I.g@. . . . 06f0: 00 00 .. TLS trace: SSL_accept:SSLv3 flush data tls_read: want=5 error=Resource temporarily unavailable TLS trace: SSL_accept:error in SSLv3 read client certificate A TLS trace: SSL_accept:error in SSLv3 read client certificate A connection_get(24): got connid=37 connection_read(24): checking for input on id=37 tls_read: want=5, got=5 0000: 16 03 01 05 d4 ..... tls_read: want=1492, got=1492 0000: 0b 00 05 d0 00 05 cd 00 05 ca 30 82 05 c6 30 82 ..........0...0. . . . 05d0: 59 d2 29 be Y.). TLS certificate verification: depth: 0, err: 20, subject: /C=DE/ST=Saxony/L=Hartmannsdorf/O=LMV Landmaschinenvertrieb- und Service GmbH/OU=Computer/CN=lmvws1/emailAddress=snr@lmv-hartmannsdorf.de, issuer: /C=DE/ST=Saxony/L=Hartmannsdorf/O=LMV Landmaschinenvertrieb- und Service GmbH/OU=Computer/CN=Sebastian Reinhardt/emailAddress=snr@lmv-hartmannsdorf.de TLS certificate verification: Error, unable to get local issuer certificate tls_write: want=7, written=7 0000: 15 03 01 00 02 02 30 ......0 TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_accept:error in SSLv3 read client certificate B TLS: can't accept. TLS: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned s3_srvr.c:2564 connection_read(24): TLS accept failure error=-1 id=37, closing connection_closing: readying conn=37 sd=24 for close connection_close: conn=37 sd=24 slap_listener_activate(8):
slap_listener(ldap://)
connection_get(24): got connid=38 connection_read(24): checking for input on id=38 ber_get_next ldap_read: want=8, got=8 0000: 30 1d 02 01 01 77 18 80 0....w.. ldap_read: want=23, got=23 0000: 16 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e 31 34 36 .1.3.6.1.4.1.146 0010: 36 2e 32 30 30 33 37 6.20037 ber_get_next: tag 0x30 len 29 contents: ber_get_next ldap_read: want=8 error=Resource temporarily unavailable conn=38 op=0 do_extended ber_scanf fmt ({m) ber: send_ldap_extended: err=0 oid= len=0 send_ldap_response: msgid=1 tag=120 err=0 ber_flush2: 14 bytes to sd 24 0000: 30 0c 02 01 01 78 07 0a 01 00 04 00 04 00 0....x........ ldap_write: want=14, written=14 0000: 30 0c 02 01 01 78 07 0a 01 00 04 00 04 00 0....x........ connection_get(24): got connid=38 connection_read(24): checking for input on id=38 TLS trace: SSL_accept:before/accept initialization tls_read: want=11, got=11 0000: 80 86 01 03 01 00 5d 00 00 00 20 ......]... tls_read: want=125, got=125 0000: 00 00 39 00 00 38 00 00 35 00 00 88 00 00 87 00 ..9..8..5....... . . . 0070: 10 6f b2 c4 c3 a4 52 ab 4b 08 0b d4 f5 .o....R.K.... 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 certificate request A tls_write: want=1778, written=1778 0000: 16 03 01 00 4a 02 00 00 46 03 01 49 b0 67 40 07 ....J...F..I.g@. . . . 06f0: 00 00 .. TLS trace: SSL_accept:SSLv3 flush data tls_read: want=5 error=Resource temporarily unavailable TLS trace: SSL_accept:error in SSLv3 read client certificate A TLS trace: SSL_accept:error in SSLv3 read client certificate A connection_get(24): got connid=38 connection_read(24): checking for input on id=38 tls_read: want=5, got=5 0000: 16 03 01 05 d4 ..... tls_read: want=1492, got=1492 0000: 0b 00 05 d0 00 05 cd 00 05 ca 30 82 05 c6 30 82 ..........0...0. . . . 05d0: 59 d2 29 be Y.). TLS certificate verification: depth: 0, err: 20, subject: /C=DE/ST=Saxony/L=Hartmannsdorf/O=LMV Landmaschinenvertrieb- und Service GmbH/OU=Computer/CN=lmvws1/emailAddress=snr@lmv-hartmannsdorf.de, issuer: /C=DE/ST=Saxony/L=Hartmannsdorf/O=LMV Landmaschinenvertrieb- und Service GmbH/OU=Computer/CN=Sebastian Reinhardt/emailAddress=snr@lmv-hartmannsdorf.de TLS certificate verification: Error, unable to get local issuer certificate tls_write: want=7, written=7 0000: 15 03 01 00 02 02 30 ......0 TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_accept:error in SSLv3 read client certificate B TLS: can't accept. TLS: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned s3_srvr.c:2564 connection_read(24): TLS accept failure error=-1 id=38, closing connection_closing: readying conn=38 sd=24 for close connection_close: conn=38 sd=24
Sorry, please forget everything I wrote in my last mail....stop! Not everithing! Delte the "partial"!
IT WORKS! I can login at both, "real" client pc and as client on server machine! Everithing is set to demand and the test (ldapsearch and login) works. So only the one point is left: the LDAP- Workshop (Stefan Kania's one) uses the "TLSCipherSuite HIGH:MEDIUM:+SSLv2" option. If I activate this in slapd.conf, ldap can not be started. Why? I do not know, because I get no output.
Sebastian Reinhardt snr@lmv-hartmannsdorf.de writes:
Sorry, please forget everything I wrote in my last mail....stop! Not everithing! Delte the "partial"!
IT WORKS! I can login at both, "real" client pc and as client on server machine! Everithing is set to demand and the test (ldapsearch and login) works. So only the one point is left: the LDAP- Workshop (Stefan Kania's one) uses the "TLSCipherSuite HIGH:MEDIUM:+SSLv2" option. If I activate this in slapd.conf, ldap can not be started. Why? I do not know, because I get no output.
In order to find out run openssl ciphers SSLv2 openssl ciphers HIGH openssl ciphers MEDIUM
-Dieter
Dieter Kluenter schrieb:
Sebastian Reinhardt snr@lmv-hartmannsdorf.de writes:
Sorry, please forget everything I wrote in my last mail....stop! Not everithing! Delte the "partial"!
IT WORKS! I can login at both, "real" client pc and as client on server machine! Everithing is set to demand and the test (ldapsearch and login) works. So only the one point is left: the LDAP- Workshop (Stefan Kania's one) uses the "TLSCipherSuite HIGH:MEDIUM:+SSLv2" option. If I activate this in slapd.conf, ldap can not be started. Why? I do not know, because I get no output.
In order to find out run openssl ciphers SSLv2 openssl ciphers HIGH openssl ciphers MEDIUM
-Dieter
Hi Dieter, I get the following output:
lmvserver:~ #openssl ciphers SSLv2 DES-CBC3-MD5:DES-CBC-MD5:EXP-RC2-CBC-MD5:RC2-CBC-MD5:EXP-RC4-MD5:RC4-MD5
lmvserver:~ # openssl ciphers MEDIUM ADH-RC4-MD5:RC4-SHA:RC4-MD5:RC2-CBC-MD5:RC4-MD5
lmvserver:~ # openssl ciphers HIGH ADH-CAMELLIA256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:CAMELLIA256-SHA:ADH-CAMELLIA128-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:CAMELLIA128-SHA:ADH-AES256-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:ADH-AES128-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES128-SHA:ADH-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:DES-CBC3-MD5
So I think, this should work?! SSLv3 is also available. Is it better to use "TLSCipherSuite HIGH:MEDIUM:+SSLv3"?
Oh, I had not posted the solution of my major problem: I mixed ip's and host names (in /etc/ldap.conf I used ip's and in certificates host names). Due to the comment in /etc/ldap.conf "the LDAP- Server must be resolveable without ldap" I thought that it is better to use the ip of our server. Also, I used as common name instead of servers host name the client name (in every client cert the according client host name). So this could not work......I was a little bit confused of configuring multiple ldap.conf- file, but thanks to Dieter the server is up and running.
Sebastian Reinhardt snr@lmv-hartmannsdorf.de writes:
Dieter Kluenter schrieb:
Sebastian Reinhardt snr@lmv-hartmannsdorf.de writes:
[...]
In order to find out run openssl ciphers SSLv2 openssl ciphers HIGH openssl ciphers MEDIUM
[...]
Hi Dieter, I get the following output:
lmvserver:~ #openssl ciphers SSLv2 DES-CBC3-MD5:DES-CBC-MD5:EXP-RC2-CBC-MD5:RC2-CBC-MD5:EXP-RC4-MD5:RC4-MD5
lmvserver:~ # openssl ciphers MEDIUM ADH-RC4-MD5:RC4-SHA:RC4-MD5:RC2-CBC-MD5:RC4-MD5
lmvserver:~ # openssl ciphers HIGH ADH-CAMELLIA256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:CAMELLIA256-SHA:ADH-CAMELLIA128-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:CAMELLIA128-SHA:ADH-AES256-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:ADH-AES128-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES128-SHA:ADH-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:DES-CBC3-MD5
So I think, this should work?! SSLv3 is also available. Is it better to use "TLSCipherSuite HIGH:MEDIUM:+SSLv3"?
Just try TLSCipherSuite HIGH If you see any failures try HIGH:MEDIUM
-Dieter
Dieter Kluenter schrieb:
Sebastian Reinhardt snr@lmv-hartmannsdorf.de writes:
Dieter Kluenter schrieb:
Sebastian Reinhardt snr@lmv-hartmannsdorf.de writes:
[...]
In order to find out run openssl ciphers SSLv2 openssl ciphers HIGH openssl ciphers MEDIUM
[...]
Hi Dieter, I get the following output:
lmvserver:~ #openssl ciphers SSLv2 DES-CBC3-MD5:DES-CBC-MD5:EXP-RC2-CBC-MD5:RC2-CBC-MD5:EXP-RC4-MD5:RC4-MD5
lmvserver:~ # openssl ciphers MEDIUM ADH-RC4-MD5:RC4-SHA:RC4-MD5:RC2-CBC-MD5:RC4-MD5
lmvserver:~ # openssl ciphers HIGH ADH-CAMELLIA256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:CAMELLIA256-SHA:ADH-CAMELLIA128-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:CAMELLIA128-SHA:ADH-AES256-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:ADH-AES128-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES128-SHA:ADH-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:DES-CBC3-MD5
So I think, this should work?! SSLv3 is also available. Is it better to use "TLSCipherSuite HIGH:MEDIUM:+SSLv3"?
Just try TLSCipherSuite HIGH If you see any failures try HIGH:MEDIUM
-Dieter
I tried it, here the result:
with "TLSCipherSuite HIGH"
Shutting down ldap-server done Starting ldap-serverstartproc: exit status of parent of /usr/lib/openldap/slapd: 1 failed
with "TLSCipherSuite HIGH:Medium"
Shutting down ldap-server done Starting ldap-serverstartproc: exit status of parent of /usr/lib/openldap/slapd: 1 failed
Hi,
Sebastian Reinhardt snr@lmv-hartmannsdorf.de writes:
Dieter Kluenter schrieb:
Sebastian Reinhardt snr@lmv-hartmannsdorf.de writes:
Dieter Kluenter schrieb:
Sebastian Reinhardt snr@lmv-hartmannsdorf.de writes:
[...]
In order to find out run openssl ciphers SSLv2 openssl ciphers HIGH openssl ciphers MEDIUM
[...]
Just try TLSCipherSuite HIGH If you see any failures try HIGH:MEDIUM
-Dieter
I tried it, here the result:
with "TLSCipherSuite HIGH"
Shutting down ldap-server done Starting ldap-serverstartproc: exit status of parent of /usr/lib/openldap/slapd: 1 failed
with "TLSCipherSuite HIGH:Medium"
Shutting down ldap-server done Starting ldap-serverstartproc: exit status of parent of /usr/lib/openldap/slapd: 1
failed
What is in the logs? Try to start slapd in debug mode. I don't think this error is based on TLSCipherSuite configuration.
-Dieter
Dieter Kluenter schrieb:
What is in the logs? Try to start slapd in debug mode. I don't think this error is based on TLSCipherSuite configuration.
-Dieter
That's right. No problem with option "TLSCipherSuite",b ut nothing in logs, too! It works. I used Stefan Kanias Workshop as blueprint and via "cpoy&paste" I copied the option into my slapd.conf file => no good idea because of this: Starting ldap with "-d 3" shows: /etc/openldap/slapd.conf: line 94: unknown directive <TLSCipherSuite�HIGH:MEDIUM:+SSLv2> outside backend info and database definitions. Ups, some invisible letters where also copied and nEdit did not show it!
Now it runs, I hope for ever...
Thanks a lot, Dieter.....and a good weekend! :-)
My next task, maybe tomorrow, is to reconfigure samba work with ldap. But this is an different topic and today I got the new book about LDAP2.4 (Galileo Computing), including a own chapter for this Samba- LDAP- integration.
Regards...
openldap-technical@openldap.org