Certificates contain information used in establishing identities over a network, a process called authentication. Similar to conventional forms of identification, certificates enable Web servers and users to authenticate each other before establishing a connection. Certificates also contain encryption values, or keys, that are used in establishing a Secure Sockets Layer (SSL) connection between the client and server. Information, such as a credit card number, sent over this connection is encrypted so that it cannot be intercepted and used by unauthorized parties.
There are two types of certificates used in SSL, each with its own format and purpose. Client certificates contain personal information about the clients requesting access to your site that allows you to positively identify them before allowing them access to the site. Server certificates contain information about the server that allows the client to positively identify the server before sharing sensitive information.
To activate your Web server's SSL 3.0 security features, you must obtain and install a valid server certificate. Server certificates are digital identifications containing information about your Web server and the organization sponsoring the server's Web content. A server certificate enables users to authenticate your server, check the validity of Web content, and establish a secure connection. The server certificate also contains a public key, which is used in creating a secure connection between the client and server.
The success of a server certificate as a means of identification depends on whether the user trusts the validity of information contained in the certificate. For example, a user logging on to your company's Web site might be hesitant to provide credit card information, despite having viewed the contents of your company's server certificate. This may be especially true if your company is new and not well known.
For this reason, certificates are sometimes issued and endorsed by a mutually trusted, third-party organization, called a certification authority (CA). The certification authority's primary responsibility is confirming the identity of those seeking a certificate, thus ensuring the validity of the identification information contained in the certificate.
Alternatively, depending on your organization's relationship with its Web site users, you can issue your own server certificates. For example, in the case of a large corporate intranet handling employee payroll and benefits information, corporate management may decide to maintain a certificate server, and assume responsibility for validating identification information and issuing server certificates. For more information see Obtaining a Server Certificate.
Server-Gated Cryptography (SGC) offers financial institutions the solution for worldwide secure financial transactions using 128-bit encryption. SGC is an extension of Secure Sockets Layer (SSL) that allows financial institutions with export versions of IIS to use strong encryption.
Server-Gated Cryptography does not require an application running on the client's browser and can be utilized by standard export versions of IIS, version 4.0 or later. A server configured for SGC can facilitate both 128-bit and 40-bit encryption sessions, so multiple versions of IIS are not required. Although SGC capabilities are built into IIS 4.0 and later versions, a special SGC certificate is required to use SGC. Contact your certification authority for availability information. For more information about SGC, see Server-Gated Cryptography (SGC) at http://www.microsoft.com/security/tech/sgc.
Client certificates are electronic documents that contain information about clients. These certificates, like server certificates, contain not only this information but also encryption keys that form part of the SSL 3.0 security features of IIS. These keys, or encryption codes, from the server and the client certificates form a key pair that facilitate encryption and decryption of transmitted data over an open network, such as the Internet. For more information on encryption see About Encryption.
The typical client certificate contains several items of information: the identity of the user, the identity of the certification authority, a public key used for establishing secure communications, and validation information, such as an expiration date and serial number. Certification authorities offer different types of client certificates, containing differing amounts of information, depending on the level of authentication required. For more information, see Obtaining a Client Certificate.
You can obtain a client certificate from a mutually trusted, commercial organization called a certification authority. Before issuing a certificate, the authority requires you to provide identification information, such as a name, address, and organization name. 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, then the certification authority will require substantial information from you; gathering this information may require a personal interview with the authority and the endorsement of a notary.
For a list of certificate authorities, see Obtaining a Server Certificate.
Note Ultimately, the success of certificate authentication depends on whether the party receiving a certificate trusts the authority who issued the certificate, and that the authority properly verified the certificate owner's identity. But beyond this trust, certificates do not provide conclusive proof about the identity, trustworthiness, or intentions, of the user or server.
By maintaining a certificate trust list (CTL), Web site administrators can automatically verify client certificates against a predefined list of trusted certificate authorities.
For example, an intranet administrator might create a different list of trusted certificate authorities for each department on the network. IIS would only accept client certificates supplied by certificate authorities in the CTL for that department. For more information, see Using Certificate Trust Lists.
Most reputable certificate authorities maintain a certificate revocation list (CRL), which is a list of current client certificates revoked before their scheduled expiration dates.
For example, if a certification authority issues a client certificate to a user and later determines that the user submitted false information, the authority can revoke that user's client certificate. However, because the certification authority cannot physically revoke a client certificate, the authority alerts Web administrators by adding information about the revoked client certificate to a CRL. For more information about revocation service providers, contact your certification authority.