Lesson 1: Public Key Infrastructure

Public key cryptography is a critical technology for e-commerce, intranets, extranets, and other Web-enabled applications. However, to take advantage of the benefits of public key cryptography, a supporting infrastructure is needed. The Windows 2000 operating system includes a native PKI that is designed from the ground up to take full advantage of the Windows 2000 security architecture. This lesson provides an overview of the Windows 2000 PKI and includes discussions about security properties, cryptography, certificates, and Microsoft Certificate Services.

---

After this lesson, you will be able to

• Describe the fundamental concepts of public key cryptography and the Windows 2000 implementation of PKI
• Process certificate requests and add certificate authorities (CAs)
• Install Certificate Services

Estimated lesson time: 35 minutes

---

Security Properties

Computer security includes everything from the physical computing environment to the software environment. In a software environment, security should provide four functions: authentication, integrity, confidentiality, and anti-replay.

Authentication

Authentication is the process of reliably determining the genuine identity of the communicating computer (host) or user. Authentication is based on cryptography; it ensures that an attacker eavesdropping on the network cannot gain the information needed to impersonate a valid user or entity. It allows a communicating entity to prove its identity to another entity before unprotected data is sent across the network. Without strong authentication, any data and the host it is sent from is suspect.

Integrity

Integrity is the correctness of data as it was originally sent. Integrity services protect data from unauthorized modification in transit. Without data integrity, any data and the host it is sent from is suspect.

Confidentiality

Confidentiality ensures that data is disclosed only to intended recipients.

Anti-Replay

Anti-replay, also called replay prevention, ensures that datagrams are not retransmitted. Each datagram sent is unique. This uniqueness prevents attacks in which a message is intercepted, stored, and re-used later to attempt illegal access to information.

Cryptography

Cryptography is a set of mathematical techniques for encrypting and decrypting data so it can be transmitted securely and not be interpreted by unauthorized parties. Cryptography uses keys in conjunction with algorithms to secure data. A key is a value used to encrypt or decrypt information. Even if the algorithm is publicly known, security is not compromised because the data cannot be read without the key. For example, the algorithm of a combination lock is common knowledge: the dials are moved in a specific order to open the lock. However, the key to the lock—the numbers of the combination code—is secret and known only to the person with the combination. In other words, the key provides the security, not the algorithm. The algorithm provides the infrastructure in which the key is applied. Security systems can be based on public key or secret key cryptography, which are described later in this lesson.

There are a number of well-known cryptographic algorithms, each supporting different security operations. Table 27.1 describes several well-known cryptographic algorithms.

Table 27.1 Cryptographic Algorithms

Algorithm	Description
Rivest-Shamir-Adleman (RSA)	A general purpose algorithm that can support digital signatures, distributed authentication, secret key agreement via public key, and bulk data encryption without prior shared secrets.
Digital Signature Standard (DSA)	A public key algorithm used for producing digital signatures.
Diffie-Hellman	A public key cryptography algorithm that allows two communicating entities to agree on a shared key without requiring encryption during the key generation.
Hash Message Authentication Code (HMAC)	A secret key algorithm that provides integrity, authentication, and anti-replay. HMAC uses hash functions combined with a secret key. A hash, also known as a message digest, is used to create and verify a digital signature.
HMAC-Message Digest function (MD5)	A hash function that produces a 128-bit value known as a 5 digital signature. This signature is used for authentication, integrity, and anti-replay.
HMAC-Secure Hash Algorithm (SHA)	A hash function that produces a 160-bit digital signature and that is used for authentication, integrity, and anti-replay.
Data Encryption Standard-Cipher Chaining (DES-CBC)	A secret key algorithm used for confidentiality. A random number is generated and used with the secret key to encrypt data.

Public Key Cryptography

Public key cryptography is an asymmetric scheme that uses a pair of keys for encryption. It is called asymmetric because it uses two encryption keys that are mathematically related. These related keys are called the public and private key pair. To use public key encryption, an object (such as a user) must generate a public and private key pair. The object has only one private key (its own) but may obtain multiple public keys that pair to other private keys. Objects obtain public keys in one of two ways:

• The owner of the private key sends the receiver the matching public key.
• The receiver obtains the key from a directory service such as Active Directory service or Domain Name System (DNS).

A public and private key pair are typically used for two purposes: data encryption and digital message signing.

Data Encryption. Data encryption provides confidentiality by ensuring that only the intended recipient is able to decrypt and view the original data. When secure data must be transmitted, the sender obtains the recipient's public key. The sender then uses the recipient's public key to encrypt data and send it. When the recipient receives the data, the recipient uses his or her own private key to decrypt the data. Encryption is only secure if the sender uses the recipient's public key for encryption. If a sender uses his or her private key to encrypt data, anyone can capture the data and decrypt it by obtaining the sender's public key.

Digital Message Signing. Digital signing provides authentication and integrity but does not provide confidentiality. Digital signing allows a recipient to be certain of the identity of the sender and verifies the content has not been modified during transit. This is to prevent the originator of a message from attempting to send a message under the guise of another identity.

When a sender signs a message, a message digest is created. A message digest is a representation of the message and is similar to a Cyclic Redundancy Check (CRC). The sender uses his or her private key to encrypt the message digest. When the recipient receives the message, the recipient obtains the sender's public key to decrypt the message digest. The recipient then creates a message digest from the message and compares the message digest to the decrypted message digest. If the message digests match, integrity is guaranteed (Figure 27.1).

Figure 27.1 Using a signed message, message digest and the PKI to verify authenticity of sender

Authentication is provided through the key pair. Since the message digest was encrypted by using the sender's private key (and only the sender's public key decrypts the message digest), the recipient can be certain that the message came from the owner of the key pair. The recipient, however, must have a mechanism for ensuring that the key pair belongs to the intended sender and not someone impersonating the sender. This is done through a certificate issued by a trusted third party, which confirms the identity of the owner of the public key. The trusted third party is known as a Certificate Authority (CA), which will be discussed later in the lesson.

Secret Keys

A secret key (also known as shared secret or shared secret key) is used in much the same way as a public key; however, there is only one key that provides security. Secret keys are generally used only for a particular session or for a short period of time before being discarded. Secret keys have an advantage over public keys because of their temporary status. If, for example, an unauthorized person became aware of the key, that person may be able to gain access to a session. However, the unauthorized person would not be able to impersonate either the user or computer outside of the session, and would not have access to other resources with the secret key.

In order to get the shared secret key to both parties, there must exist a mechanism for doing so without compromising security. If the key was sent over the network, an eavesdropper (someone using a network-monitoring tool to capture packets on the network) would have easy access to the key.

Secret Key Exchange

A common solution to providing the secret key to both parties is using public keys. Public keys make it possible to encrypt the secret key as it is sent across the network. Public keys ensure confidentiality, authentication, and integrity; therefore, security is not compromised when a secret key is sent.

For example, if Bruce wants to send data to Max by using a secret key, Bruce and Max each generate half of the secret key. Bruce obtains Max's public key to encrypt his half of the secret key and send it to Max. Likewise, Max obtains Bruce's public key to encrypt his half of the secret key and sends it to Bruce. Bruce and Max then combine the halves of the secret key to generate the shared secret key to be used for encrypting the data to be sent (Figure 27.2). This secret key negotiation and the use of the secret key to encrypt the data provide authenticity, integrity, and confidentiality.

Figure 27.2 Secret key exchange where two users (Bruce and Max) each generate half of a secret key to create a shared secret key

Data Encryption

In order to provide confidentiality, the data must be encrypted by using the shared secret key. Because there is only one key known to both the sender and the receiver, encryption is a straightforward process. The sender encrypts the data with the shared secret key, and the receiver decrypts it with the shared secret key. Since no other entity on the network has knowledge of the secret key, the data is safe from attack. The sender and the receiver generally discard shared secret keys once the session has been terminated.

Certificates

Public key encryption assumes that the identity of the key pair owner is established beyond doubt. A digital certificate, also referred to simply as a certificate, is a set of data that completely identifies an entity. A trusted CA issues certificates after the authority has verified the entity's identity. The CA provides a trusted third party for both communicating parties.

For example, if Tucker wants to send authenticated data to Max, Tucker sends his public key to Max. A trusted CA certifies Tucker's public key, thus certifying Tucker's identity. Because Max trusts the CA, he trusts Tucker.

This process is similar to that of a notary public. A person signs a document in front of a notary public and provides proof of identity. The notary public is a trusted entity so that anyone examining the document can be sure that the signature is authentic. Likewise, when the sender of a message signs the message with a private key, the recipient of the message can use the sender's public key, signed by a trusted CA, to verify that the sender is legitimate. Since the trusted CA certifies the public key, the recipient can be sure that the sender is the assumed sender. A trusted CA may be a third-party provider of certificates such as VeriSign or Certificate Services.

A user can, for example, obtain a digital certificate for use with e-mail. The digital certificate includes the public key and information about the user. When the user sends e-mail, the e-mail includes a digital signature that uses the private key. The recipient obtains the public key and determines whether or not the sender of the mail message is the assumed sender. A private key is never sent to the recipient.

X.509

The term X.509 refers to the International Telecommunication Union-Telecommunication (ITU-T) standard for certificate syntax and format. The Windows 2000 certificate-based processes use the X.509 standard. Because it is possible to use certificates for different applications (for example, secure e-mail, file system encryption), each certificate has different information contained within it. However, certificates should, at a minimum, contain the following attributes:

• Version
• Serial number
• Signature algorithm ID
• Issuer name
• Validity period
• Subject (user) name
• Subject public key information
• Issuer unique identifier
• Subject unique identifier
• Extensions
• Signature on the above fields

Certificate Revocation Lists

Certificates, like most real-world forms of identification, can expire and become invalid. The CA can also revoke them for other reasons. In order to handle the existence of invalid certificates, the CA maintains a certificate revocation list (CRL). The CRL is available to network users to determine the validity of any given certificate.

CA Hierarchy

Rather than having one trusted CA provide authentication for the entire Internet or intranet, it is possible to have CAs certify other CAs. This hierarchical structure, called a chain, allows users to trust a single CA rather than having to trust all CAs. This chaining of CAs provides several benefits:

• Flexibility. It is easy to move, revoke, or chain CA's without affecting other parts of the organization.
• Distributed Administration. Administrators can be responsible for their own sites.
• Security Policies. Security policies can be different at each CA site.

The CA at the top of the chain is referred to as the root CA. CAs below the root are referred to as intermediate, subordinate, or issuing CAs.

Certificate Services

Certificate Services enables an organization to manage the issuance, renewal, and revocation of digital certificates without having to rely on external certificate authorities. In addition, Certificate Services allows an organization to fully control the policies associated with issuing, managing, and revoking certificates, as well as the format and contents of the certificates themselves. In addition, Certificate Services logs all transactions, enabling the administrator to track, audit, and manage certificate requests.

Certificate Services Features

Microsoft Certificate Services has a number of features that make it valuable to organizations that do not choose to rely upon external certificate authorities and who require a flexible tool that can be adapted to the needs of their organization.

Policy Independence. In order to obtain a certificate, requesters must meet certain criteria. This criteria is defined in certificate policies. For example, one policy may grant commercial certificates only if applicants present their identification in person. Another policy may grant credentials based on e-mail requests.

Policies are implemented in policy components that can be written in Java, Visual Basic, or Microsoft C/C++. The default policy for Certificate Services allows users to request certificates through a Hypertext Markup Language (HTML) page.

Transport Independence. Certificate Services can request and distribute certificates through any transport mechanism. That is, it can accept certificate requests from an applicant and post certificates to the applicant through Hypertext Transfer Protocol (HTTP), remote procedure call (RPC), disk file, or custom transport.

Adherence to Standards. Certificate Services can perform the following services:

• Accept standard Public Key Cryptography Standards (PKCS) #10 requests
• Support PKCS #7 cryptographically signed data
• Issue X.509 version 1.0 and 3.0 certificates

Support for additional certificate formats can be added to Certificate Services. Certificate Services includes a Lightweight Directory Access Protocol (LDAP) component so that Certificate Services can integrate with the Active Directory service.

Key Management. The security of a certification system depends on the protection of private keys. The design of Certificate Services ensures that individuals cannot access private key information without authorization. Certificate Services relies on Microsoft CryptoAPI to provide key management functionality and other cryptographic capabilities for building a secure store, with certificates kept in a certificate store.

Certificate Services Architecture

Certificate Services' architectural elements include the server engine that handles certificate requests and other modules that perform tasks by communicating with the server engine. Figure 27.3 illustrates how the components communicate with the server engine.

Figure 27.3 Server engine and other components of Certificate Services

Server Engine

The server engine is the core component of Certificate Services. The engine acts as a broker for all requests it receives from the entry modules, driving the flow of information between components during the processing of a request and generation of a certificate. At each processing stage, the engine interacts with the various modules to ensure appropriate action is taken based on the state of the request.

Intermediary

The intermediary is the architectural component that receives new certificate requests from clients and submits them to the server engine. The intermediary is composed of two parts: the intermediary application that performs actions on behalf of clients and the Certificate Services Client Interface that handles communications between the intermediary application and the server engine.

Intermediary applications can be written to handle certificate requests from different types of clients, across multiple transports, or according to policy-specific criteria. Microsoft Internet Information Services (IIS) is an intermediary application that provides support for clients over Hypertext Transfer Protocol (http). Intermediaries can also check on the status of a previously submitted request and obtain the Certificate Services' configuration information.

Server Database

Certificate Services includes a server database that maintains status information and a log of all issued certificates and certificate revocation lists (CRLs). The database is composed of two parts: the server log and the server queue.

Server Log

The server log stores all certificates and CRLs issued by the server so that administrators can track, audit, and archive server activity. In addition, the server log is used by the server engine to store pending revocations before publishing them in the CRL. The server log also stores recent certificate requests for a configurable period in case a problem is encountered when a certificate is issued.

Server Queue

The server queue maintains status information (receipt, parsing, authorization, signing, and dispatch) as the server processes a certificate request.

Policy Module

The policy module contains the set of rules governing issuance, renewal, and revocation of certificates. All requests received by the server engine are passed to the policy module for validation. Policy modules are also used to parse any supplemental information provided within a request and set properties on the certificate accordingly.

Extension Handlers

Extension handlers work in tandem with the policy module to set custom extensions on a certificate. Each extension handler acts as a template for the custom extensions that should appear in a certificate. The policy module must load the appropriate extension handler when it is needed.

Exit Modules

Exit modules publish completed certificates and CRLs through any number of transports or protocols. By default, the server notifies each exit module installed on the server whenever a certificate or CRL is published.

Certificate Services provides a Component Object Model (COM) interface for writing custom exit modules for different transports and protocols or for custom delivery options. For example, an LDAP exit module might be used to publish only client certificates in a directory service and not server certificates. In this case, the exit module can use the COM interface to determine the type of certificate that the server is issuing and filter out any that are not client certificates.

Processing Certificate Requests

Certificate Services provides services for processing certificate requests and issuing digital certificates (Figure 27.4).

Figure 27.4 Processing certificate requests

Certificate Services performs the following steps when processing a certificate request:

1. The certificate request is sent by the client to an intermediary application. The intermediary application formats it into a PKCS #10 format request and submits it to the server engine.
2. The server engine calls the policy module, which queries request properties, decides whether or not the request is authorized, and sets optional certificate properties.
3. If the request is approved, the server engine takes the request and builds a complete certificate.
4. The server engine stores the completed certificate in the certificate store and notifies the intermediary application of the request status. If the exit module has so requested, the server engine notifies it of a certificate issuance event. This allows the exit module to perform further operations, such as publishing the certificate to a directory service.
5. The intermediary gets the published certificate from the certificate store and passes it back to the client.

Enrolling Certificates

The process of obtaining a digital certificate is called certificate enrollment. This process begins with a client submitting a certificate request and ends with the installation of the issued certificate in the client application.

The enrollment control and its forms are accessed through the Certificate Services Enrollment Page (see Figure 27.5). This page is available from the Certificate Services Web page at http://server_name/certsrv/.

Figure 27.5 Enrollment control form for Server01 configured as an Enterprise CA

Certificate Authority Certificates

In the process of issuing a digital certificate, the CA validates the identity of the individual requesting the certificate and then signs the certificate with its own private key.

A client application, such as Microsoft Internet Explorer, checks the CA signature before accepting a certificate. If the CA signature is not valid or comes from an unknown source, Internet Explorer warns the user by displaying a security message and may prevent the user from accepting the certificate.

NOTE

---

If Internet Explorer is set to the low security level, it will not warn the user of invalid certificates. This setting is appropriate for highly trusted intranet environments and is inappropriate for Internet access.

In addition to the server and client authentication certificates issued by Certificate Services, there are certificates that identify CAs.

The CA certificate is a signature certificate that contains a public key used to verify digital signatures. It identifies the CA that issues authentication certificates to the servers and clients that request these certificates. Clients use the CA certificate of the CA issuing the server certificate to validate the server certificate. Servers use the CA certificate of the CA issuing the client certificate to validate the client certificate.

A self-signed CA certificate is also called a root certificate because it is the certificate for the root CA. The root CA must sign its own CA certificate because by definition there is no higher certifying authority to sign its CA certificate.

Distribution and Installation of CA Certificates

CA certificates are not requested and issued in the same manner as server and client authentication certificates. Server and client authentication certificates are unique for each requesting server and client, and are not shared—they must be generated and issued by a CA upon demand. In contrast, the CA certificate does not require issuance upon demand. Instead, it is created once and then made readily available to all servers or clients who request certificates from the CA.

A commonly used technique for distributing CA certificates is to place them in a location known and accessible to anyone who requests certificates from the CA.

Installing Certificate Services

You can install Certificate Services by using the Add/Remove Programs utility in Control Panel or optionally during the installation of Windows 2000 Server. Administrators familiar with creating CAs can choose a custom setup by using the advanced options available when installing Certificate Services. Those unfamiliar with creating CAs can select the default settings.

Certificate Authority Type

The CA type allows selection of how the CA will be utilized in a CA hierarchy and whether or not the CA will rely upon Active Directory services. The following certificate authority types are available:

• Enterprise Root CA. This CA becomes the root CA for the hierarchy and requires Active Directory service.
• Enterprise Subordinate CA. This CA becomes a subordinate CA to an Enterprise Root CA. It requires Active Directory services. It requests a certificate from the Enterprise Root CA.
• Stand-alone Root CA. This CA becomes the root CA for the hierarchy but does not require Active Directory services.
• Stand-alone Subordinate CA. This CA becomes a subordinate CA to a Stand-alone Root CA. It does not require Active Directory services. It requests a certificate from the Stand-alone Root CA.

When installing the Certificate Services as an Enterprise CA, Certificate Services copies the certificates into Active Directory services. Security support providers such as the Kerberos protocol can query Active Directory services to get the certificate, which contains the public key.

CA Information

You must supply information about the initial CA that is created when you install Certificate Services. This information includes the CA name and other necessary information. None of this information can be changed after the CA setup is complete.

Advanced Configuration

The advanced configuration contains options for the type of cryptography algorithms to be used for the CA that you are creating. The advanced configuration options include the name of the cryptographic provider, the hash algorithm, the option to use existing public keys and private keys, and the key length.

Administering Certificate Services

The main tool used to administer Certificate Services is the Certification Authority snap-in (Figure 27.6).

Figure 27.6 Certification Authority snap-in for an Enterprise CA

The Certification Authority snap-in allows you to perform a variety of administrative tasks:

• Start or stop the Certificate services
• Set security permissions and delegate control of a CA
• View a CA certificate
• Back up a CA
• Restore a CA from a backup copy
• Renew a root CA
• Renew a subordinate CA
• Manage certificate revocation
• Manage certificate requests
• Manage certificate templates
• Change policy settings
• Map certificate to user accounts
• Modify the Policy Module or Exit Module

You can use the Certification Authority snap-in to administer a certification authority on the local computer or on another computer. The snap-in is installed when Certificate Services are installed or when installing the Administration Pack (Adminpak.msi).

Certutil.exe is a command-line utility used for administering certificate services. Running certutil without any command-line switches displays summary information about the local certificate authority. Certutil is used to dump and display CA configuration information, configure Certificate Services, back up and restore CA components, and verify certificates, key pairs, and certificate chains.

If you need to set security for the CA Web pages, you should use the Internet Information Services snap-in. Expand the Default Web Site from the console tree and then select CertSrv. From the Action menu, select Properties. On the Directory Security tab, under Anonymous access and authentication control, click Edit. In the Authentication Methods dialog box, configure the security settings for the CA Web pages.

Practice: Installing and Configuring Certificate Services

In this practice you install an Enterprise Root CA and use this CA to issue, install, and revoke certificates. Note that the secure way to configure Certification Services is to create a root CA that only issues certificates to subordinate CA types. The subordinate CA types then issue certificates for specific purposes such as application services and authentication. Using a root CA for this purpose is not secure because if the root CA security is breached, all certificates issued are compromised. However, for the purpose of learning how to install and configure certificate services, a root CA can be used.

Exercise 1: Installing Certificate Services and Configuring the Certificate Authority

In this exercise, you install Certificate Services on Server01. Server01 acts as an Enterprise Root CA.

1. Log on to Server01 as Administrator with a password of password.
2. Click Start, point to Settings, and then click Control Panel.

   Control Panel appears.

3. Double-click the Add/Remove Programs application.

   The Add/Remove Programs window appears.

4. In the left pane, click the Add/Remove Windows components icon.

   The Windows Components wizard appears.

5. Click the Certificate Services check box.

   A Microsoft Certificate Services message box appears stating that once Certificate Services is installed, the computer cannot be renamed and it cannot join or be removed from a domain.

6. Click Yes.
7. On the Windows Components screen, click Details.

   The Certificate Services window appears.

   Notice that Certificate Services subcomponents include both the service used to create a certificate authority and a Web enrollment form for submitting requests and retrieving certificates from the computer running as a CA.

8. Click OK.
9. On the Windows Components screen, click Next.

   The Certification Authority Type screen appears.

10. Select each radio button and read the text appearing in the Description box.

    Notice that the Enterprise CA types can only be used if Active Directory service is running. The standalone CA types run independently of Active Directory service. Thus, they can be used in the presence or absence of Active Directory service. If Active Directory service is present, the standalone CA types will use it. Subordinate CA types are dependent on the presence of a CA higher up in the CA hierarchy.

11. Click the Enterprise Root CA radio button and click the Advanced Options check box.
12. Click Next.

    The Public and Private Key Pair screen appears.

    Notice that there are a number of Cryptographic Service Providers (CSPs), each with one or more associated hash algorithms used to generate key pairs. From this screen you can also specify the key length or use existing keys installed on the computer, import keys, and view certificates.

13. In the CSP list box, verify that Microsoft Base Cryptographic Provider v1.0 is selected. In the Hash Algorithm list box, verify that the SHA-1 hash algorithm is selected. In the Key Length drop-down list box, verify that Default is selected. Click Next.

    The CA Identifying Information screen appears.

14. Type the information in the table into the text boxes on the CA Identifying Information screen.

    Label	Value to type
    CA name	Enterprise CA
    Organization	Microsoft Corporation
    Organizational unit	Microsoft Press
    City	Redmond
    State or province	Washington
    E-mail	[e-mail]
    CA description	Root CA for self-study training only

    Notice that this certificate is configured to be valid for two years.

15. Click Next.

    The Data Storage Location screen appears.

    Notice that the certificate database and log file folder, CertLog, is stored on the boot partition. If disk capacity on the boot partition is limited, consider specifying another secure partition for the certificate database and log folder.

    The Store configuration information in a shared folder is not necessary if Active Directory services is running and the computer operating as the certificate authority is a member of a domain. Configuration information about the CA is automatically published to the Active Directory store.

16. Click Next.

    A Microsoft Certificate Services message box appears stating that Internet Information Services is running on the computer and warning you that it must be stopped in order for you to be able to continue.

17. Click OK.

    The Configuring Components screen appears as the software is installed and configured, and then the Completing the Windows Components Wizard screen appears.

18. Click Finish and then on the Add/Remove Programs window, click Close.
19. Close Control Panel.

Exercise 2: Running Certificate Services

In this exercise you generate, install, and revoke a certificate on Server01. You will use the Certificate Enrollment URL and the Certification Authority snap-in to complete this exercise.

1. Open Certification Authority from the Administrative Tools program group.

   The Certification Authority snap-in appears.

2. In the console tree, expand the Enterprise CA node.
3. In the console tree, select the Issued Certificates folder and then minimize the Certification Authority snap-in.
4. Click the Start menu and then choose run.

   The Run dialog box appears.

5. In the Open text box, type http://server01/certsrv and then click OK.

   The Internet Connection wizard appears.

6. Click the I Want To Setup My Internet Connection Manually, or I Want To Connect Through A Local Area Network (LAN) radio button.
7. Click Next.

   The Setting Up Your Internet Connection screen appears.

8. Click the I Connect Through A Local Area Network (LAN) radio button.
9. Click Next.

   The Local Area Network Internet Configuration screen appears.

10. Clear the Automatic Discovery Of Proxy Server (Recommended) check box.
11. Click Next.

    The Set Up Your Internet Mail Account screen appears.

12. Click the No radio button, and then click Next.

    The Completing The Internet Connection wizard appears.

13. Click Finish.

    Internet Explorer appears and displays the certificate services enrollment page.

14. Read the information on this page and then verify that the Request A Certificate radio button is selected.
15. Click Next.

    The Choose Request Type page appears and the User Certificate Request radio button is selected.

16. Click Next.

    The User Certificate - Identifying Information page appears.

17. Click More Options.

    Notice that the CSP selected was the CSP type you specified during installation of Certificate Services.

18. Click Submit.

    The Certificate Issued page appears.

19. Minimize Internet Explorer and restore the Certification Authority snap-in.

    The Certification Authority snap-in appears, and one certificate is listed in the details pane. If you don't see the certificate request, press F5 to refresh the details pane.

20. Double-click the certificate appearing in the details pane.

    The Certificate dialog box appears with three tabs.

21. Click the Details tab.
22. In the top box below the Show drop-down list box, click Issuer.

    Notice that the information appearing in the bottom box is the information you typed into the CA Identifying Information screen.

23. Click OK.
24. Minimize the Certification Authority snap-in and restore Internet Explorer.
25. Click the Install This Certificate hyperlink.

    The Certificate Installed page appears stating that you have successfully installed a certificate.

26. Close Internet Explorer.
27. Restore the Certification Authority snap-in and select the certificate in the details pane.
28. Click the Action Menu, point to All Tasks and then click Revoke Certificate.

    The Certificate Revocation dialog box appears.

29. In the Reason Code drop-down list box choose Key Compromise, and then click Yes.
30. In the console tree, click the Revoked Certificates folder.

    The revoked certificate appears in the details pane.

31. Click the Action menu, point to All Tasks and then click Publish.

    The Certificate Revocation List dialog box appears stating that the previous list is still valid.

32. Click Yes.
33. Close the Certification Authority snap-in.
34. Click the Start menu, and then click Run.

    The URL to the Certsrv directory appears.

35. Click OK.

    Internet Explorer appears and displays the certificate services enrollment page.

36. Click the Retrieve The CA Certificate Or Certificate Revocation List radio button, and then click next.
37. Click the Download Latest Certificate Revocation List hyperlink.

    The File Download dialog box appears.

38. Click the Open This File From Its Current Location radio button, and then click OK.

    The Certificate Revocation List dialog box appears.

39. Click the Revocation List tab.
40. In the Revoked Certificates box, click the item that appears.

    In the Revocation entry box, the Serial number of the revoked certificate, the date of revocation, and the reason for revocation appear.

41. Click OK.
42. Close Internet Explorer.

Lesson Summary

Windows 2000 includes a native PKI that is designed to take full advantage of the Windows 2000 security architecture. Public key cryptography is an asymmetric scheme that uses a pair of keys for encryption. To use public key encryption, a user must generate a public and private key pair. Public key encryption uses digital certificates to completely identify the key pair owner. The Windows 2000 certificate-based processes use the X.509 standard. Certificate Services enables an organization to manage the issuance, renewal, and revocation of digital certificates without having to rely on external CAs. Certificate Services supports policy independence, transport independence, adherence to standards, and key management. Certificate Services architectural elements include the server engine that handles certificate requests and other modules that perform tasks by communicating with the server engine. Certificate Services provides services for processing certificate requests and issuing digital certificates. You can install Certificate Services by using the Add/Remove Programs utility in Control Panel or optionally during Windows 2000 Server installation. The tools used to administer Certificate Services once it is installed are the Certification Authority snap-in, the Certutil utility, and the Certificate Services enrollment Web page.