Understanding Digital Certificates

To verify the identity of people and organizations on the Web and to ensure content integrity, Internet Explorer uses industry-standard X.509 v3 digital certificates. Certificates are electronic credentials that bind the identity of the certificate owner to a pair (public and private) of electronic keys that can be used to encrypt and sign information digitally. These electronic credentials assure that the keys actually belong to the person or organization specified. Messages can be encrypted with either the public or private key, and then decrypted with the other key.

The following illustration shows the basic process of using public and private keys to encrypt and decrypt a message sent over the Internet.

Illustration 6.1 How Public and Private Keys Work

Each certificate contains at least the following information:

• Owner's public key

• Owner's name or alias

• Expiration date of the certificate

• Serial number of the certificate

• Name of the entity that issued the certificate

• Digital signature of the entity that issued the certificate

Certificates can also contain other user-supplied information, including a postal address, e-mail address, and basic registration information, such as the country, postal code, age, and gender of the user.

Certificates form the basis for secure communication and client and server authentication on the Web. You can use certificates to do the following:

• Verify the identity of clients and servers on the Web.

• Encrypt secure communication channels between clients and servers.

• Encrypt messages for secure Internet e-mail communication.

• Verify the sender's identity for Internet e-mail messages.

• Sign executable code that users can download from the Web.

• Verify the source and integrity of signed executable code that users can download from the Web.

Certificates are authenticated, issued, and managed by a trusted third party called a certification authority (CA). The CA must provide a combination of three essential elements:

• Technology, such as security protocols and standards, secure messaging, and cryptography

• Infrastructure, including secure facilities, backup systems, and customer support

• Practices, including a defined model of trust and a legally binding framework for managing subscriber activities and resolving disputes

A commercial CA must be a trusted service. In addition to obtaining certificates from CAs, you can also implement a certificate server, such as Microsoft Certificate Server, and use it to provide certificate services for your Web infrastructure.

Commercial Certificate Authorities

Commercial CAs issue certificates that verify the electronic identity of individuals and organizations on the Web. The primary responsibility of a CA is to confirm the identity of the people and organizations seeking certificates. This effort ensures the validity of the identification information contained in the certificate.

CAs perform the following types of services:

• Issue and renew certificates.

• Authenticate the identities of individuals and organizations.

• Verify the registrations of individuals and organizations.

• Publish and maintain a Certificate Revocation List (CRL) of all certificates that the CA has revoked.

• Handle legal and liability issues related to security.

Many commercial CAs offer certificate services for Microsoft products, as well as a wide range of other certificate services. For a current list of CAs that support Microsoft products, visit the Microsoft Security Advisor Web site. For a list of Microsoft Web sites that offer additional product support information related to Internet Explorer, see Appendix I , "Microsoft Internet Explorer 5 Resource Directory."

Commercial CAs issue various types of certificates, including the following:

• Personal certificates for people to digitally sign communications and assure secure transactions over the Internet and intranet

• Client authentication and server authentication certificates for managing secure transactions between clients and servers

• Software publisher certificates for people who digitally sign their software

• Software publisher certificates for commercial software companies that digitally sign their software

CAs can also issue many other types of certificates. Each CA operates within the charter of its Certification Practices Statement (CPS). You can visit the CA's Web site and read the CPS to understand the types of certificates issued by a specific CA and the operating procedures that the CA follows.

When you choose a CA, you should consider the following issues:

• Is the CA a trusted entity operating a certification practice that can both meet your needs and operate efficiently in your region? Other people should immediately recognize your CA as reputable and trustworthy. If you choose a CA with a questionable reputation, users may reject your certificate.

• Is the CA familiar with your organization's business interests? Look for a CA from which you can leverage technical, legal, and business expertise.

• Does the CA require detailed information from you to verify your trustworthiness? Most CAs require information, such as your identity, your organization's identity, and your official authority to administer the Web server for which you are requesting a certificate. Depending on the level of identification required, a CA may need additional information, such as professional affiliations or financial records, and the endorsement of this information by a notary.

• Does the CA have a system for receiving online certificate requests, such as requests generated by a key manager server? An online system can speed up the processing of your certificate requests.

• Does the CA give you enough flexibility and control over how certificates are issued and authenticated? Some commercial CA services and products may not integrate with your existing security model and directory services.

• Does the cost of the CA service meet your requirements? Substantial costs can be associated with obtaining a server certificate, especially if you need a high level of identification assurance.

Certificate Servers

You can implement a certificate server, such as Microsoft Certificate Server, to manage the issuance, renewal, and revocation of industry-standard certificates. You can use these certificates in conjunction with servers that support Secure Sockets Layer (SSL), Transport Layer Security (TLS), or Private Communications Technology (PCT) to build a secure Web infrastructure for the Internet or intranet. For large organizations with complex Web needs, certificate servers can offer many advantages over commercial CAs, including lower costs and total control over certificate management policies.

Depending on your relationship with your users, you can obtain server certificates from a commercial CA, or you can issue your own server certificates. For services on your intranet, user trust is typically not an issue, and you can easily configure Internet Explorer to trust server certificates issued by your organization. For services on the Internet, however, users may not know enough about your organization to trust certificates issued by your certificate server. Therefore, you may need to obtain server certificates that are issued by a well-known, commercial CA to ensure that users trust your Internet sites.

Authenticode Technology

Microsoft Authenticode™2.0 is client-side software that watches for the downloading of ActiveX control (.ocx) files, cabinet (.cab) files, Java applets, or executable files in order to provide reliable identity of the code. Authenticode displays certificate information, such as the name included in the digital signature, an indication of whether it is a commercial or personal certificate, and the date when the certificate expires. This information enables users to make a more informed decision before continuing with the download.

The software publisher digitally signs software (including .exe, .dll, .ocx, and .cab files) when it is ready for publication. Software publishers that obtain a code-signing certificate from a CA can use Authenticode signing tools to digitally sign their files for distribution over the Web. Authenticode looks for the signatures (or the lack of signatures) in the files that users attempt to download. For more information about how to digitally sign files by using Authenticode signing tools, see Chapter 12 , "Preparing for the IEAK," and the MSDN Online Web site. **

If a piece of software has been digitally signed, Internet Explorer can verify that the software originated from the named software publisher and that no one has tampered with it. Internet Explorer displays a verification certificate if the software meets these criteria. A valid digital signature, though, does not necessarily mean that the software is without problems. It just means that the software originated from a traceable source and that the software has not been modified since it was published. Likewise, an invalid signature does not prove that the software is dangerous, but just alerts the user to potential problems. When a digital signature fails the verification process, Internet Explorer reports the failure, indicates why the signature is invalid, and prompts the user about whether to proceed with the download.

You can configure Internet Explorer to handle software in different ways, depending on the status of its digital signature. Software can be unsigned, signed using valid certificates, or signed using invalid certificates.

For signed or unsigned software, you can configure Internet Explorer to do the following:

• Prevent users from downloading or running the software from a specific zone.

• Download and run the software without user intervention from a specific zone.

• Prompt users to make a choice about whether to download or run the software from a specific zone.

How you configure Internet Explorer to respond to certificates depends on various factors, such as the level of trust you have for the security zone where the content originated. If you are deploying Internet Explorer in an organization, you may also want to consider the level of trust you have for the intended user group and the level of technical expertise of the users. For example, you might trust unsigned software from your intranet, but not trust unsigned software from the Internet. In that case, you would configure Internet Explorer to automatically download and run unsigned active content from the intranet without user intervention and prevent the download of unsigned active content from the Internet.

Secure Client and Server Communications

Certificates can be used for secure communications and user authentication between clients and servers on the Web. Certificates enable clients to establish a server's identity, because the server presents a server authentication certificate that discloses its source. If you connect to a Web site that has a server certificate issued by a trusted authority, you can be confident that the server is actually operated by the person or organization identified by the certificate. Similarly, certificates enable servers to establish a client's identity. When you connect to a Web site, the server can be assured about your identity if it receives your client certificate.

The following sections describe security technologies that ensure secure communications between clients and servers.

Secure Channels

The exchange of certificates between clients and servers is performed using a secure transmission protocol, such as SSL, TLS, or PCT. SSL 2.0 supports server authentication only. SSL 3.0, TLS 1.0, and PCT 1.0 support both client and server authentication. Secure transmission protocols can provide these four basic security services:

• Client authentication - Verifies the identity of the client through the exchange and validation of certificates.

• Server authentication - Verifies the identity of the server through the exchange and validation of certificates.

• Communication privacy - Encrypts information exchanged between clients and servers by using a secure channel.

• Communication integrity - Verifies the integrity of the contents of messages that are exchanged between clients and servers by ensuring that messages have not been altered en route.

Note Encrypting all traffic over secure channels can put a heavy load on clients and servers. Therefore, secure channel encryption is typically used only for the transfer of small amounts of sensitive information, such as personal financial data and user authentication information.

You can change the set of protocols that are enabled for client and server authentication by clicking the Tools menu, clicking Internet Options , and then clicking the Advanced tab. For more information, see "Configuring Advanced Security Options for Certificate and Authentication Features" later in this chapter.

Server Gated Cryptography

For situations that require the highest-possible level of security, such as online banking, you can implement Server Gated Cryptography (SGC) to provide stronger encryption for communication between clients and servers. SGC enables a 128-bit server with an SGC certificate to communicate securely with all versions of Internet Explorer by using 128-bit SSL encryption. For example, SGC enables financial institutions with Microsoft Windows NT®based Internet servers to use 128-bit SSL encryption for secure financial transactions.

Note 128-bit SSL encryption is available in the United States; internationally, it is restricted to approved SGC sites only.

The key benefits of SGC include the following:

• Banks and financial institutions can securely conduct financial transactions with their retail customers worldwide without requiring customers to change their standard Web browser or financial software.

• Online banking does not require any special client software. For example, customers can use all standard, off-the-shelf, exportable versions of Internet Explorer to connect to an SGC server and conduct secure transactions by using 128-bit encryption.

• SGC is fully interoperable with Netscape browsers and servers. Therefore, Internet Explorer users can communicate with Netscape servers using 128-bit encryption by means of SGC.

SGC is enabled in Internet Explorer 4.0 and later. It works with standard, off-the-shelf export-version servers and client applications that use an updated dynamic-link library named Schannel.dll and have an SGC certificate. For no charge, you can download the updated Schannel.dll from the Microsoft Web site. Users can enable their Internet Explorer browser for SGC by simply downloading the exportable 128-bit SGC add-on.

Banks can enable Microsoft Internet Information Server (IIS) for SGC if they have the standard, off-the-shelf version of IIS 3.0, which is part of Windows NT 4.0. First, they must download and apply the patch that updates their Schannel.dll file for IIS 3.0. Then they can use the Key Manager in IIS 3.0 to generate a request for a certificate, and submit the request to an authorized CA. After the certificate has been issued and installed, IIS will be fully SGC-enabled and can communicate with SGC-enabled Microsoft and Netscape clients.

CryptoAPI 2.0

CryptoAPI 2.0 provides the underlying security services for certificate management, secure channels, and code signing and verification (Authenticode technology). Using CryptoAPI, developers can easily integrate strong cryptography into their applications. Cryptographic Service Provider (CSP) modules interface with CryptoAPI and perform several functions, including key generation and exchange, data encryption and decryption, hashing, creation of digital signatures, and signature verification. CryptoAPI is included as a core component of the latest versions of Windows. Internet Explorer automatically provides this support for earlier versions of Windows.

Fortezza Support

Microsoft provides a Fortezza cryptographic service provider (CSP) plug-in for Internet Explorer that supports Fortezza security technology, which was created by the National Security Agency for the United States Department of Defense. Users can install the Fortezza CSP plug-in to ensure secure Internet Explorer communications based on Fortezza security standards; this support includes communications with Fortezza-secured Web sites.

Note To use the Fortezza CSP plug-in provided for Internet Explorer 5, users must have the necessary Fortezza hardware and CSP installed. For tools and instructions about installing and enabling Fortezza, users can contact their Fortezza hardware vendor.

Using Internet Explorer, users can log in using Fortezza credentials, and operate in Fortezza mode, which is identified by an "F" overlaid on the Internet Explorer lock icon. They can perform various Fortezza management functions, including selecting certificates and changing personalities (credentials). To enable this support, select the Use Fortezza check box. For more information about enabling advanced security options, see "Configuring Advanced Security Options for Certificate and Authentication Features" later in this chapter.

Server Certificate Revocation

Internet Explorer 5 adds support for server certificate revocation, which verifies that an issuing CA has not revoked a server certificate. This feature checks for CryptoAPI revocation when certificate extensions are present. If the URL for the revocation information is unresponsive, Internet Explorer cancels the connection.

Note Outlook Express also includes certificate revocation, which is controlled through a separate option within the e-mail program.

To enable server certificate revocation, select the Check for server certificate revocation check box. For more information about enabling advanced security options, see "Configuring Advanced Security Options for Certificate and Authentication Features" later in this chapter.

Publisher's Certificate Revocation

Internet Explorer 5 adds support for publisher's certificate revocation, which verifies that an issuing CA has not revoked a publisher's certificate. To enable publisher's certificate revocation, select the Check for publisher's certificate revocation check box. For more information about enabling advanced security options, see "Configuring Advanced Security Options for Certificate and Authentication Features" later in this chapter.

.