SSL server authentication

SSL server authentication verifies that sites you communicate with are who they claim to be. Authentication confirms a server's identity through standard techniques of public-key cryptography to ensure that a server's certificate and public ID are valid and have been issued by a certificate authority listed in the client's list of trusted CA's.

Communication with "trusted" servers that possess authentication certificates issued by a certificate authority is critical to establishing a secure environment. Authentication certificates are digitally signed documents which bind the public key to the identity of the private key owner. Authentication happens at connection time and is independent of the application or application protocol. With SSL, authentication is performed by an exchange of certificates, which are blocks of data in a format described in the X.509 ITU-T standard. X.509 certificates are issued and digitally signed by a certificate authority.

However using SSL does not guarantee that the client is communicating with the correct server. Consider the following scenario, in which "Server1" and "Server2" both have valid certificates from a CA that the client ("Client") trusts. Client wants a secure session with Server1, but Server2 wants to eavesdrop on their communication and is physically located in a place that makes it possible to do so:

Client sends a request for an SSL session to Server1. Instead, the request (and all subsequent traffic) goes through Server2. Instead of forwarding Client's request to Server1, Server2 responds directly to the request by sending its own certificate to Client.
Client receives Server2's certificate and checks its list of trusted CAs. Since Server2's certificate is signed by the same CA as Server1's certificate, Client accepts the certificate and creates a secure session with Server2.
Having completed the secure session with Client, Server2 requests and creates its own SSL session with Server1. From this point, Client sends encrypted information to Server2. Server2 decrypts the information, re-encrypts it, then sends it to Server1. It does the same for information flowing in the opposite direction. The result is that Server2 is able to read it and even change it, even though all data is encrypted as it flows over the Internet.

SSL server authentication is designed to prevent this outcome. When server authentication is enabled, the client, after ensuring that the server's certificate can be trusted, checks that the Internet name in the certificate matches the Internet name of the server. If they match, the SSL negotiation continues. If not, the connection ends.

With server authentication enabled, the security scenario outlined above would proceed as follows:

Client sends a request for an SSL session to Server1. The request (and all subsequent traffic) actually goes through Server2. Instead of forwarding Client's request to Server1, Server2 responds directly to Client's request by sending its own certificate to Client.
Client receives Server2's certificate and checks its list of trusted CAs. Since Server2's certificate is signed by the same CA as Server1's certificate, Client accepts the certificate and creates a secure session with Server2.
After the secure session has been completed, but before any real data has been sent or received, Client compares the Internet name in the certificate it received with the name of the server it wants to talk to. Since they do not match, Client knows that the connection should not continue and disconnects it.