Subject: Re: imap access via ipo3d (fwd)

From: [email-masked]
Date: Thu, 11 Nov 2004 17:24:49 +0100 (MET)

Hi Marc,

i have found the cause of the problem.
When ipo3d connects to the requested imap server it honors the starttls
capability. When it receives the certificate it must follow the
certificate chain up to the root certificate. Making available and doing a
c_rehash in SSLCERTS is not sufficient. You have to inform openssl of the
path to trusted certificates. After patching osdep/unix/ssl_unix.c with
the following the problem vanished (allmost).

*** ssl_unix.c.orig     Tue Apr 27 21:54:51 2004
--- ssl_unix.c  Thu Nov 11 11:45:39 2004
***************
*** 218,223 ****
--- 218,226 ----
    else SSL_CTX_set_verify
(stream->context,SSL_VERIFY_PEER,ssl_open_verify);
                                /* set default paths to CAs */
    SSL_CTX_set_default_verify_paths (stream->context);
+                                 /* set path to trusted CAs */
+   SSL_CTX_load_verify_locations(stream->context,NULL,
+                                 SSL_CERT_DIRECTORY);
                                /* create connection */
    if (!(stream->con = (SSL *) SSL_new (stream->context)))
      return "SSL connection failed";
***

Maybe it is better to introduce a new config option to be able to have the
trusted certificates in a seperate directory (SSLCAPATH)?

The problem is not completely solved because modern x509 certificates make
use of the "Subject Alternate Name" section. So it is not sufficient to
compare only CN with the hostname in ssl_start_work().

Kind regards
Paul

========================================================================
Paul Tedaldi                     |
Informatikdienste                |    Email:  [email-masked]
Universitaet Zuerich             |
Winterthurerstr. 190             |    Tel:    +41 (0)44 635 4523
CH-8057 Zuerich                  |    Fax:    +41 (0)44 635 4505
Switzerland                      |
========================================================================

---------- Forwarded message ----------
Date: Wed, 10 Nov 2004 21:08:11 +0100 (MET)
From: [email-masked]
To: [email-masked]
Subject: imap access via ipo3d

Hi,

we have used the feature of ipop3d to access a remote inbox via imap i.e
login to "imap-host:user@pop-host". This worked for years without
problems. Now we decided to activate SSL on both, the ipop and imap
servers. Now it is possible to login to the ipop server for a local
inbox and to login to the imap server directly for a local inbox there.
But login to the ipop server and request an inbox from the imap server no
longer works. Testing via telnet allows us to proceed to the pass
command but then we get "-ERR Unable to open user's INBOX" immediatly.
It does not matter if the client uses a SSL Connection or not.

We have imap-2004a on both servers.

Has anyone a setup like this working and give us some advice ?

Thanks Paul

========================================================================
Paul Tedaldi                     |
Informatikdienste                |    Email:  [email-masked]
Universitaet Zuerich             |
Winterthurerstr. 190             |    Tel:    +41 (0)44 635 4523
CH-8057 Zuerich                  |    Fax:    +41 (0)44 635 4505
Switzerland                      |
========================================================================
-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see:
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------
-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: Mark Crispin <[email-masked]>
Date: Thu, 11 Nov 2004 08:37:37 -0800 (PST)

SSL_CERT_DIRECTORY is the directory for the *server* to find the local 
host public certificate, and SSL_KEY_DIRECTORY is the directory for the 
*server* to find the local host private key.

These are *not* the directories for the CA certificates.  The CA 
certificate directory is declared as part of the OpenSSL build. 
Apparently, you built OpenSSL with a different CA certificate directory 
than you actually used.

If you think about it, you really want to use the CA certificate directory 
that OpenSSL was built with.  Otherwise, each and every program that uses 
OpenSSL would have to be told where the CA certificates are located as 
part of their build; nor could you change the CA certificate directory 
without rebuilding all programs that use OpenSSL.

It makes sense for programs to have configurability of their own 
certificates (such as the imapd and ipop3d server public certificates and 
private keys), but not the CA certificates.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.