Bug 99554
Summary: | Evolution can't talk to any openldap servers using SSL | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux Beta | Reporter: | Thomas J. Baker <tjb> |
Component: | evolution | Assignee: | Dave Malcolm <dmalcolm> |
Status: | CLOSED NOTABUG | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | beta1 | CC: | dmaley, nalin, p.van.egdom |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-05-18 15:19:38 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Thomas J. Baker
2003-07-21 20:06:28 UTC
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?) |