Netscape SSL with IMAP problem

[Jason Keltz]

Hi..

My department has purchased two certificates from Equifax Secure --
one for our SSL-enabled web server (www.cs.yorku.ca), and the other for
our SSL-enabled IMAP mail server (mail.cs.yorku.ca).

For the web server, we are using Apache 1.3.14 + SSL 1.42.
For IMAP, we are using University of Washington's imap 2000 with SSL.
I have installed OpenSSL 0.9.6.

When I received the e-mail from Equifax with the certificates, I was sent
three pieces:
1) The Equifax Secure E-Business CA-2 certificate
   (C=US, O=Equifax Secure Inc, CN=Equifax Secure E-Business CA-2)
   which is signed by:
C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,
OU=Certification Services Division, CN=Thawte Server
[EMAIL PROTECTED]
2) The mail.cs.yorku.ca certificate
3) The www.cs.yorku.ca certificate

I copied the equifax certificate into /usr/local/ssl/certs.
I got the Thawte public certificate and put it into /usr/local/ssl/certs.
I got the hash values for each of these files with:
openssl x509 -in file -hash
and symlinked the name to the hash value.0 for each file.

I then concatenated the mail.cs.yorku.ca with the private key that we
generated when we generated our CSR and I did the same thing for WWW.

I was able to "openssl verify" both certificates.  Both were "OK".

If I try to connect to our secure web server with both Netscape and
Internet Explorer, everything works fine.

If I try to connect to our IMAP SSL server with Unix Pine mail reader, I
can see that the appropriate hash files are read, and the session is
encrypted.

If I try to connect to our IMAP SSL server with Outlook Express, Outlook
doesn't show any signs of being connected to an encrypted link, but a
snoop shows that the connection is indeed encrypted.  (I am sort of
surprised that Outlook Express doesn't have a method by which you can view
the certificate chain like in Internet Explorer?)

Finally, if I try to connect to the IMAP SSL server with Netscape
Communicator v4.75 and v6 -- the *SAME* Netscape Communicator that talks
to our SSL enabled web server without complaining suddenly says that it
does not does not recognize the authority who signed its Certificate".
If I continue, the session is indeed encrypted, but I specifically
purchased a certificate for the mail server so that the signer would be
trusted, and that message wouldn't come up -- otherwise, I could have just
use a self-signed certificate!  I have spent an entire day trying to
figure out why this happens, and I cannot.  Does anyone have any ideas?

The only fishy thing to me is that in the Netscape signer list, I see:
Equifax Premium CA
Equifax Secure CA
*not* Equifax Secure E-Business CA-2

But Netscape happily accepts the web connection, so it must be using a
fingerprint that is the same as one of the other two because all my other
certificate lists (other than "Signers") are empty.

Any help you could provide would be (very) much appreciated.

Jason Keltz ([EMAIL PROTECTED])
Technical Support
Department of Computer Science
York University
Toronto, Ontario CANADA


__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Netscape SSL with IMAP problem

[Oscar Jacobsson]

Jason Keltz wrote:
 Can someone explain why the server has to pass along the certificates from
 the CAs though?  I don't quite understand.  I'm new to this all.  Isn't it
 up to the server to send out just the certificate, and then up to the
 client to do the checks? 

On one side, it's because the TLS1 spec (haven't got an URL to the SSL3
drafts handy) says so. The self-signed certificate at the top level can
optionally be omitted though, since it will need to be explicitly
trusted (and thus, I presume, known) or the client-side verification
will fail.

On a more practical note, I think it is a very convenient thing to do,
given the fact that there's still, to my knowledge, no standardized way
for a given TLS client to be able to perform path discovery, meaning
that it won't necessarily be able to contruct a given chain on its own.

Even were it able to, it would conceivably run in to problems anyway due
to the "ship first, ask questions later" approach taken by a great deal
(kind of an understatement) of the PKIs I've come across so far. I can't
actually think of a single one that I've actually managed to verify
without hiccups, however minor, against the path validation algorithms
in either X.509 or RFC 2459. This might very well be a problem with me,
my diligence, or my memory though; in all fairness.

 I mean, isn't it counter-productive -- couldn't
 the server (be it imap or http) somehow send along fake CA certificates
 that make the real certificate look as if it were truly signed when it's
 not?

It would still need to compromise the private key of a certificate that
were trusted by the client in order to create a chain it would be able
to verify.

//oscar
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Netscape SSL with IMAP problem

[Michael T. Babcock]

Jason Keltz wrote:

 Can someone explain why the server has to pass along the certificates from
 the CAs though?  I don't quite understand.  I'm new to this all.  Isn't it
 up to the server to send out just the certificate, and then up to the
 client to do the checks?  I mean, isn't it counter-productive -- couldn't
 the server (be it imap or http) somehow send along fake CA certificates
 that make the real certificate look as if it were truly signed when it's
 not?

I believe I once saw on the Equifax site that they use signing certificates signed
by Thawte -- so its possible that their certificate is not in the browser but that
the browser can verify the Equifax certificate against the Thawte cert, and then
verify yours against the Equifax cert.

__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]