SSL Basics

Secure Sockets Layer (SSL) is a security standard designed to provide secure connections on the Internet. Using an SSL solution, you can encrypt confidential data and exchange it over the Internet between Web servers and clients. The minimum components of an SSL solution are an SSL-equipped server, an SSL-equipped client, and a public-key certificate installed on either the server (typical) or the clients (the exception), or both.

Although an SSL solution typically has the public-key certificate installed on a Web site on the server only (in which case it is often called a server certificate) the data sent by both the server and the client are encrypted. This can be confusing. The server owns the certificate, but both parties to the transaction get access to the keys used for encryption. The server certificate is used to satisfy the client that the service provider is trustworthy. The authentication method used by the server to authenticate the client establishes that the client is trustworthy. Now a secure, encrypted two-way communication ensues, using public, private, and secret keys for encryption and decryption of the data sent over the Internet.

A public key and a private key constitute a key-pair used to encrypt and decrypt data sent through an SSL connection. The sender uses the public key to encrypt data before sending it to the recipient. The recipient uses the private key to decrypt the data received. The key-pair is not used to encrypt large amounts of data. Typically, the key-pair is used to encrypt or decrypt a session key, which is used to encrypt and decrypt the data.

For example, if a Web site is sending requested data to a client, the keys are used as follows:

1.       The client requests the public key from the server.

2.       The server sends the public key to the client.

3.       The client sends the server a session key, encrypting it with the public key.

4.       The server decrypts the session key received from the client by using the server’s private key. Both client and server will use the session key to decrypt data received.

Whenever secure, encrypted communication is required for a connection between two parties communicating over the Internet.

SSL encrypts the entire message, including the message headers and the message body.

Server certificates are used for SSL solutions that allow systems administrators to control the servers, but not the clients. This is the situation most commonly found on the Internet, and is often implemented for commerce. The server certificate provides the users with the assurance that the organization providing the service has been deemed legitimate by a certification authority (CA), and that the certification is current. The server certificate also contains the required keys. This SSL solution allows both clients and the service to protect the confidential data that it sends. For more information about CAs, see the question about Trusted Certification Authorities below.

You need a server certificate for each Web site that requires an SSL solution.

When establishing an SSL connection with a Web site that has a server certificate, browsers perform verification checks on the server certificate. When a client browser detects an incorrect value in the server certificate, the browser displays warning messages. You can use a browser to verify the server certificates on the Web sites that you manage. If you are browsing a Web site that belongs to another organization, you should notify the Web site administrator of any error messages that you receive when verifying their server certificates. Error messages are listed below.

·         This certificate was issued by an authority you have not chosen to trust.

This message informs the client that the root certificate of the CA that issued the server certificate is not in the client browser’s Trusted Root Certification Authority store. The message has no effect on establishing an SSL connection between the client browser and the Web site. This problem occurs only when using a non-trusted CA, such as Microsoft Certificate Services.

IIS administrators can resolve this condition by installing the root certificate into their client browsers. For more information, search the Microsoft Knowledge Base for article 297681 at the Microsoft Product Support Services Web site (http://support.microsoft.com).

·         Certificate has expired or is not yet valid.

When this message appears in a browser, one of the following conditions has probably occurred and requires action:

The certificate has not yet taken effect. Inform the Web site administrator of the error message. If you are the administrator, check the Effective Date of the certificate to determine its current validity.

The certificate has expired. Inform the Web site administrator of the error message. If you are the administrator, check the Expiration Date of the certificate.

The client system date and time is incorrect. In this case, it is possible that the certificate is valid, but the erroneous date and time has caused an error message to be generated.

·         The name of the security certificate is invalid or does not match the name of the site.

This message is generated when the registered domain name, also called the common name, that was specified when the certificate was generated does not match the URL in the request. This error message is a warning only. The client can still access the site by using an HTTPS request.

To avoid this error message, make sure that the common name on the server certificate matches the correct request URL. To do this, acquire a new certificate whenever the URL used for access cannot be changed to match the common name on the server certificate.

Yes. You can configure SSL to help protect confidential data on a URL-by-URL basis. One part of the Web site may require encryption of data transmissions with SSL (by specifying HTTPS in the URL), while another part of the Web site is suitable for unencrypted data transmission (by specifying HTTP in the URL). This flexibility in security configuration allows you to provide encryption of confidential data as required.

As an example, consider a fictitious organization called Contoso Pharmaceuticals that has an e-commerce Web site on the Internet. The Web site contains both secured and unsecured content. The URL for the unsecured home page is http://www.contoso.com. The URL for the secured e-commerce portion of the Web site is https://purchase.contoso.com. Traffic between clients and the home page is unencrypted, whereas SSL encrypts traffic between clients and the e-commerce portion of the Web site.

You need a thorough understanding of the purpose of the application to decide whether to use client certificates. Client certificates are considered a valid authentication protocol because they adhere to the mutual-authentication requirement. In client certificate solutions, both the server and the client are challenged for their identities. Hence, before the connection has been successfully established, both identities have been exposed. In anonymous environments, where many requests go unauthenticated, client certificates are not a good solution. Client certificates require an administrator to have access to the IIS server and to each client that will be connecting to it. This is not feasible in many Internet solutions, where clients from just about anywhere can be used to attempt a connection.

On the other hand, client certificates are the only way to connect to IIS when all other authentication methods – anonymous, basic, integrated, digest, and passport – are disabled on the server.

For any computer that uses SSL, a Trusted Certification Authority (Trusted CA) is an organization that is listed in the Certificate Trust List, or similar document, for that computer. The Trusted CA plays a vital role in SSL security. The Trusted CA is responsible for establishing that individuals and organizations requesting certificates are who they claim to be, and are not likely to commit fraud or other offenses. They also review the purpose of the request and how the certificate will be used. They approve, or deny, the request. Finally, the Trusted CA is responsible for informing its customers, the certificate holders, when a certificate is revoked.

With every copy of Windows NT 4.0 Option Pack, Windows 2000, or Windows Server 2003, Microsoft ships a fully functional certification authority. There is no way to ensure that any certificate “approved” by a Microsoft CA should be trusted because it can be created by anyone using a Microsoft Certificate Services.

No. Trust continues for as long as the trust status is current (that is, the CA is in good standing and the certificate has not expired). Trust is revoked only when the certificate appears on the Certificate Revocation List (CRL) in the Windows registry. IIS 5.0 and IIS 6.0 check each request against the CRL unless the CRL is disabled.

The data is encrypted by using more bits, making decryption more difficult for anyone intercepting the encrypted data. The downside is that high encryption requires the server to consume more CPU and bandwidth. As a result, performance suffers.

Very safe, at least from hackers who have limited computing power. The key that is dynamically created for one SSL connection is usually out-of-date by the time a hacker can decrypt the 128-bit encrypted request.

Yes. Encryption and decryption require more bandwidth and CPU time.

A hardware SSL accelerator is a fast, hardware-based encryption/decryption solution that outperforms most software-based solutions. In software solutions, the CPU is a shared resource among many different processes. Hence, the CPU consumption of encryption/decryption is added to the rest of the load on the CPU. However, accelerators are hardware-level devices that offload all encryption/decryption work to the on-board CPU. All encryption/decryption is performed outside of the main (shared) CPU. This is logically similar to 3-D video cards that take on expensive graphic computations to save the main CPU for other tasks.

Microsoft-specific questions

To enable SSL, complete the following steps for each Web site and application:

1.       Request a server certificate for the Web site from a certification authority (CA), or generate a request to send over the network to an online CA, such as Microsoft Certificate Services.

2.       Depending on the level of identification assurance offered by your server certificate, you can expect to wait several days to several months for the CA to approve your request and send you a certificate file.

3.       Install the server certificate on the Web server.

4.       Assign the server certificate to the Web site.

For more information about requesting, installing, and assigning a server certificate, see Help for the version of IIS you are using.

In Internet Explorer, right-click in the browser window, and then click Properties. In the Properties box, Connection should list a version of SSL.