> > Verifying that you got the "right certificate" as opposed to a valid
> > certificate is outside the scope of what the SSL layer can do.
> The key issue (pun intended) is possession of the associated private
> key for the identity bound to the public key in the cert. If the
> party possesses it, they may be presumed (modulo key revocation, etc.)
> to be the party indicated in the certificate -- no one else can perform
> a successful SSL handshake.
>
> Whether you like IP addresses or FQDNs is irrelevant.
OpenSSL can check whether the other end has the private key
corresponding
to the certificate presented. This proves it owns the certificate.
OpenSSL can check that the certificate presented is properly signed by a
trusted authority. This ensures that the other end owns the CN in that
certificate.
However, OpenSSL cannot make sure the certificate presented is for the
entity you wanted to connect to. Because it does not know that you really
wanted to connect to 'www.amazon.com', it has no way to complain that the
valid certificate presented was actually for 'www.evilsite.com'.
Obviously, resolving 'www.evilsite.com' to an IP address and getting the
one you connected to doesn't help.
You must come back and make sure the certificate is owned by the thing
you
wanted to connect to in the first place.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
