From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686) Gecko/20030701 Galeon/1.3.5 Description of problem: Evolution can't contact my openldap servers (servers are Red Hat 9 and openldap 2.0.x.). I had the same problem when I was running Red Hat 9 + rawhide. Then, if I downgraded openldap to 2.0.x from Red Hat 9, it worked fine. I don't think this is the long term solution you're looking for so I'm not going to verify that will work on Severn unless you want me to. Version-Release number of selected component (if applicable): evolution-1.4.3-3 openldap-2.1.22-3 How reproducible: Always Steps to Reproduce: 1. configure an ldap contact server in evolution 2. try to connect to it 3. Actual Results: "We were unable to open this addressbook." error dialog. Expected Results: It connects and I can get to my contacts. Additional info: I should have reported this with the rawhide version...
Can you think of any openldap changes that would cause this Nalin?
I can't get evolution to talk to my newly configured 2.1.22 server either, although I'm not sure it's evolution's fault this time. I keep getting TLS trace: SSL3 alert read:fatal:unknown CA TLS trace: SSL_accept:failed in SSLv3 read client certificate A TLS: can't accept. TLS: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca s3_pkt.c:1052 connection_read(7): TLS accept error error=-1 id=0, closing errors. When I connect using openssl s_client -state -debug -connect localhost:ldaps, it connects fine. I have the minimum three tls lines defined: TLSCACertificateFile /usr/share/ssl/certs/ca-bundle.crt TLSCertificateFile /usr/share/ssl/certs/slapd.pem TLSCertificateKeyFile /usr/share/ssl/certs/slapd.pem and the permissions are all correct.
This seems to be an evo+openldap 2.1.22 problem. At home on a system that is also running a full rawhide release except that I kept openldap at openldap-2.0.27-8, evolution-1.4.3-5 can talk to both my home 2.0.27 server and my work 2.1.22 server. At work, evo+openldap 2.1.22 can't talk to any openldap servers. I can provide any logs you need.
For clarity, I should add that at home, the 2.0.27 ldap server is running on a different stock RH 9 system and the working evo+openldap 2.0.27 combo is running on a rawhide system. At work, both the server and client are running on the same rawhide system so I can't just install the openldap-2.0.27 rpm like I could at home because the server rpm needs the 2.1.22 client rpm. This seems to point to the evo+openldap 2.1.22 client libraries not working together since the same evolution-1.4.3 does work with the openldap 2.0.27 client libraries to both 2.0 and 2.1 openldap servers.
The 1.4.4 evo build doesn't help with the problem. Any ideas on this?
Are you using SSL?
Yes. That's what the ldap error I included above is about.
If you edit /etc/ldap.conf and put the following in, does it work? TLS_REQCERT try or TLS_REQCERT allow The SSL handling in openldap 2.1 is much more strict about things matching than in previous versions.
Neither one seemed to help. Maybe you can enlighten me on what ldap parts evolution uses. The file you had me modify is owned by nss_ldap-207-1. Now does that package use the openldap client libraries? I ask because on a system with openldap-2.0.27-8 and nss_ldap-207-1, evolution works fine using SSL to both server versions. On a system with nss_ldap-207-1 and openldap-2.1.22-4, it doesn't work and gives the TLS trace: SSL_accept:SSLv3 flush data tls_read: want=5, got=5 0000: 15 03 01 00 02 ..... tls_read: want=2, got=2 0000: 02 30 .0 TLS trace: SSL3 alert read:fatal:unknown CA TLS trace: SSL_accept:failed in SSLv3 read client certificate A TLS: can't accept. TLS: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca s3_pkt.c:1052 connection_read(8): TLS accept error error=-1 id=0, closing connection_closing: readying conn=0 sd=8 for close connection_close: conn=0 sd=8 daemon: removing 8 error. So is nss_ldap talking to the openldap client libraries? FWIW, I just double-checked this on a third system. If I simply replace openldap-2.1 with openldap-2.0, it works fine: katratzi> rpm -qa | grep openldap openldap-devel-2.1.22-4 openldap-2.1.22-4 katratzi> su Password: su: incorrect password katratzi> su Password: [root@katratzi tjb]# cd /net/redhat/9/en/os/i386/RedHat/RPMS/ [root@katratzi RPMS]# rpm -Uvh --oldpackage openldap-devel-2.0.27-8.i386.rpm openldap-2.0.27-8.i386.rpm warning: openldap-devel-2.0.27-8.i386.rpm: V3 DSA signature: NOKEY, key ID db42a60e Preparing... ########################################### [100%] 1:openldap warning: /etc/openldap/ldap.conf created as /etc/openldap/ldap.conf.rpmnew ########################################### [ 50%] 2:openldap-devel ########################################### [100%] [root@katratzi RPMS]# This works without even fixing any config files.
I still have no luck connecting to and ldap server using ssl with evolution-1.4.4-6. Is this problem not reproducible on your end? Should I be trying to provide more information?
I've just verified that with mozilla, I can connect to either ldap server in question in SSL mode. So it appears to be evolution/openldap 2.1 related. Neither of the two recent updates to openldap or evolution have fixed it (openldap-2.1.22-6 and evolution-1.4.4-7).
Better summary.
Just for thoroughness, it works with SSL disabled.
This still is a problem with evolution-1.4.5-7 and openldap-devel-2.1.22-8, openldap-clients-2.1.22-8, openldap-servers-2.1.22-8, and openldap-2.1.22-8. I assume that this is not going to be fixed for FC1?
This bug can die. I don't know why it didn't work back then but the "TLS_REQCERT allow" from #8 works for me now. I've been using it since at least FC2. I didn't know this bug was still open until I clicked on mybugs after adding an FC4 one. I'm not going to close it since I'm not sure how it should be characterized (ERRATA maybe?)