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]
