Bug 114003 - Evolution fails to recognise a valid SSL/TLS server certificate
Summary: Evolution fails to recognise a valid SSL/TLS server certificate
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: evolution
Version: 9
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Dave Malcolm
QA Contact:
Keywords: Security
Depends On:
Blocks: 171511
TreeView+ depends on / blocked
Reported: 2004-01-21 10:12 UTC by Jon Warbrick
Modified: 2007-04-18 17:01 UTC (History)
4 users (show)

Clone Of:
Last Closed: 2005-10-22 00:08:57 UTC

Attachments (Terms of Use)

Description Jon Warbrick 2004-01-21 10:12:56 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1)

Description of problem:
Attempting to contact imap.hermes.cam.ac.uk using IMAP and SSL results
in a warning message form Evolution:

-- cut --
Bad certificate from imap.hermes.cam.ac.uk

Issuer:   /C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting
cc/OU=Certification Services Division/CN=Thawte Server
Subject:   /C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting
cc/OU=Certification Services Division/CN=Thawte Server
Fingerprint:  68:19:dc:c1:2b:ae:12:cc:9b:84:22:08:d7:15:34:a7
Signature:     BAD

Unable to get issuer's certificate locally
-- cut --

imap.hermes does have a valid certificate, issued by Thawte, and this
works find in all other known IMAPS clients. 

The message suggests that Evolution is failing to find its local copy
of Thawte's root certificate which it needs to validate the signature
on imap.hermes's certificate. I would expect that Evolution, like most
SSL/TLS clients, would be pre-configured with the root certificates
from the well known CAs. I can't investigate this since Evolution does
not to provide any way to find out which root root certificates it
knows about. 

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Attempt to opne an IMAPS connection as above

Actual Results:  Warning message about bad signature, as above

Expected Results:  Connection with no warning

Additional info:

I've clasified this as a security issue since in general it encourages
users to ignore what is being reported as an SSL certificate error.
Doing so undermines much of the security provided by SSL/TLS.

Comment 1 Dave Malcolm 2004-09-01 18:21:31 UTC
Evolution 1.2.2 is a relatively old version, these days.  Do similar
problems occur for Evolution 1.4.* or later versions?  In Evolution
1.5.93 I can select Tools->Settings->Certificates and view Evolution's
known certificates that way.

Comment 2 Jon Warbrick 2004-09-02 08:50:52 UTC
Well, Evolution 1.2.2 was the version from RH9 that had the problem.
The demise of RH9 and the change to licencing and release arrangements
mean that I'm no longer using Red Hat (nor Fedora) for this
application so I'm not in a position to test anything more current.

One of my colleagues investigated a similar problem with Evolution
1.4.4 and 1.4.6 in the distribution we are now using. In this case the
problem was that Evolution's OpenSSL code was not calling 


to select use of OpenSSL's default certificate path. He submitted a
patch to the Evolution project but they have declined to include it
since the current 1.5 uses a different crypto library be default
(though the broken OpenSSL code is still provided, just not built). So
it may well be that the problem is fixed in 1.5.

Comment 3 Richard Bullington-McGuire 2005-03-22 15:18:22 UTC
This is still a problem in Evolution 1.4.6, as shipped with Fedora Core 2. I
hope Fedora chooses to fix this issue in a security errata. Jon Warbrick hit
this one on the head. Fedora Core 3 and above avoid this bug by using the
Mozilla NSS SSL cert code instead of the unsupported OpenSSL code. However, it
would still be worth fixing this, since the problem is well-understood and
Fedora Core 2 is still supported. 

Here is a patch to the spec file that fixes the problem (also see below for the
patch referenced in the spec file):

--- evolution.spec.dist 2005-03-22 10:02:40.085564332 -0500
+++ evolution.spec      2005-03-22 10:02:44.244035041 -0500
@@ -22,7 +22,7 @@
 Name: evolution
 Version: 1.4.6
-Release: 2
+Release: 2.1.PKR
 License: GPL
 BuildRoot: %{_tmppath}/%{name}-%{version}-root
 URL: http://www.ximian.com/
@@ -60,6 +60,12 @@
 # evolution-wombat but it does work to fix the problem
 Patch500: evolution-wombat-sm.patch
+# Fixes openssl certificate negotiation, ximian rejected patch due
+# to unsupported state of openssl in evolution.
+# http://lists.ximian.com/archives/public/evolution-hackers/2004-August/004222.html
+Patch600: evolution-1.4.6-openssl-verify-cert.patch
 Summary: GNOME's next-generation groupware suite
 Group: Applications/Productivity
@@ -162,6 +168,8 @@
 #patch500 -p0 -b .wombatsm
+%patch600 -p1 -b .openssl-verify-cert
 mkdir -p krb5-fakeprefix/include
 mkdir -p krb5-fakeprefix/lib
 mkdir -p krb5-fakeprefix/%{_lib}

This patch should be put in the file "evolution-1.4.6-openssl-verify-cert.patch":

diff -urNp -urNp evolution-1.4.6.old/camel/camel-tcp-stream-openssl.c
--- evolution-1.4.6.old/camel/camel-tcp-stream-openssl.c        2003-03-03
22:53:15.000000000 +0000
+++ evolution-1.4.6/camel/camel-tcp-stream-openssl.c    2004-08-18
15:20:09.282083003 +0100
@@ -735,6 +735,7 @@ open_ssl_connection (CamelService *servi
        ssl_ctx = SSL_CTX_new (SSLv23_client_method ());
        g_return_val_if_fail (ssl_ctx != NULL, NULL);
+       SSL_CTX_set_default_verify_paths(ssl_ctx);
        SSL_CTX_set_verify (ssl_ctx, SSL_VERIFY_PEER, &ssl_verify);
        ssl = SSL_new (ssl_ctx);
        SSL_set_fd (ssl, sockfd);

Comment 10 Dave Malcolm 2005-10-22 00:08:57 UTC
Cleanup of bugzilla: resolving this bug as the issue is fixed in current release
(FC4), and does not affect FC3.

Note You need to log in before you can comment on or make changes to this bug.