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:
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:
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:
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 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:
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:
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:
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.
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:
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.
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.
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:
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.
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:
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 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.
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.
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.
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.
