SSL and Certificates

Applies To: Windows Server 2003, Windows Server 2003 with SP1

Certificates are digital identification documents that allow both servers and clients to authenticate each other. If you want the server and client browser to set up an SSL connection over which encrypted information can be sent, certificates are required. Certificates include keys that are used to establish an SSL-encrypted connection. A key is a unique value that is used to authenticate the server and the client in establishing an SSL connection. A public key and a private key form an SSLkey pair. The World Wide Web Publishing Service (WWW service) on your Web server uses this key pair to negotiate an encrypted connection with the client browser.

The certificate-based SSL features in IIS consist of a server certificate, a client certificate, and various digital keys. You can use Certificate Services to create certificates, or you can obtain certificates from a mutually trusted third-party organization called a certification authority (CA). For more information about obtaining, installing, and managing certificates, see Certificates_IIS_SP1_Ops.

Server certificates provide a way for users to confirm the identity of your Web site before they transmit personal information, such as a credit card number. A server certificate contains detailed identification information, such as the name of the organization that is affiliated with the server content, the name of the organization that issued the certificate, and a public key that is used to establish an encrypted connection. This information helps to assure users of the authenticity of Web server content and the integrity of the SSL–secured connection.

With SSL, your Web server also has the option of authenticating users by checking the contents of their client certificates. A typical client certificate contains detailed identification information about a user and the organization that issued the certificate, as well as a public key. You can use client certificate authentication, along with SSL encryption, to implement a method for verifying the identity of your users.

Use the Web Server Certificate Wizard to either generate a certificate request file (NewKeyRq.txt, by default) that you can send to a certification authority, or to generate a request for an online certification authority, such as Microsoft® Certificate Services. For more information, see Obtaining Server Certificates.

If you are not using Microsoft Certificate Services to issue your own server certificates, a third-party certification authority must approve your request and issue your server certificate. Depending on the level of identification assurance offered by your server certificate, you can expect to wait anywhere from several days to several months for the certification authority to approve your request and send you a certificate file. You can have only one server certificate per Web site.

After you receive a server certificate file, use the wizard to install it. The installation process attaches, or binds, your certificate to a Web site. For more information about installing certificates, see Requesting a New Server Certificate from an Online CA.

Certification Authorities

You can obtain a certificate from a mutually trusted, third-party commercial organization called a certification authority (CA). The primary responsibility of the CA is to confirm the identity of the party that is seeking a certificate, thus ensuring the validity of the identification information that is contained in the certificate.

Before issuing a certificate, the CA requires you to provide identification information, such as name, address, and organization. The extent of this information can vary with the identification assurance requirements of the certificate. If you need a certificate to provide absolute assurance about your identity, the CA will require substantial information from you; gathering this information might require a personal interview with the CA as well as the endorsement of a notary.

Ultimately, the success of certification authentication depends on whether the party receiving a certificate trusts the authority who issued the certificate, and that the authority correctly verified the certificate owner's identity. However, beyond this trust, certificates do not provide conclusive proof of the identity, trustworthiness, or intentions of the user or server.

Certificate Trust Lists

You can configure computers running Windows Server 2003 with IIS 6.0 to accept certificates from a predefined list of certification authorities (CAs). For example, you might create a different list of trusted certification authorities for each department on your network. IIS would accept only client certificates supplied by certification authorities in the CTL for that department. Each Web site can be configured to accept certificates from a different list by using certificate trust lists (CTLs). You can automatically verify client certificates against the CTL. You can use the Certificate Trust List Wizard to create and edit CTLs and to add new root certificates to your CTLs.

Certificate Revocation Lists

Certification authorities (CAs) cannot physically revoke your users' client certificates. However, they might publish Certificate Revocation Lists (CRLs) that are copied onto your computer, where they can be searched for client certificates that are in revoked status. This process, called CRL checking, allows IIS to reject client certificates that do not meet the CA criteria for validity. CRLs pair subscribers and revocation status, along with a description of the reason for the revocation. Most CRL services also include a prospective date for the next CRL to be published. Frequent updates help you stay current with subscribers' status with the CA. When determining the schedule for CRL publishing, there is a trade-off between performance and security. The more often CRLs are published, the more current clients can be with the list of revoked CRLs and the less likely they are to accept recently-revoked certificates. However, frequent publishing can negatively impact network and client performance. To help mitigate this trade off, delta CRLs can be used if the environment supports them. For more information about certificate revocation and CRLs, see Revoking Certificates and Publishing CRLs.

CRL checking is managed by setting metabase properties. The metabase properties that control CRL checking can be set or viewed using a COM object, or WMI scripts, or ADSI scripts.

Enabling and Disabling CRL Checking

You can enable and disable CRL checking by setting the CertCheckMode Metabase Property. CRL checking is enabled by default. The CRL will be refreshed by the CA whenever a new CRL is issued, unless you set a different CRL refresh interval by specifying a value other than 0 for the CertCheckMode metabase property.

Configuring CRL Refreshes

Optionally, you can refresh the CRL on your computer with the CRL on the CA server even when the cached CRL on your computer is valid, by changing the setting of the RevocationFreshnessTime Metabase Property.

You can change the length of time allocated for downloading a CRL to a time, in seconds, by setting the RevocationURLRetrievalTimeout Metabase Property.