Exam 70-124: Objective 5.1, 5.1.1, 5.2: Installing and Managing Windows 2000 Certificate Authorities

Microsoft's PKI consists of the following components:

• Active Directory  Contains the certificate store for certificates and CRLs

• Certificate Services  Installed on a Windows 2000 machine to allow it to function as a CA

Microsoft recommends that the necessary domains be created before the needed CAs are set up on the network. Due to the hierarchical structure, the first CA is always the Root CA. The Root CA automatically generates a self-signed CA certificate using its own key pair, as discussed previously, and then generates CA certificates for any of its subordinate CAs as they are subsequently installed.

As with many services, Windows 2000 has a wizard to ease the installation of the certificate service. The wizard walks the installer through the entire process. Preplanning will make the installation run more smoothly. Before installing the Certificate Service, the administrator needs to identify what computer should run the service, considering such factors as current workload, physical security, connectivity, load balancing, and available hardware. The determination of the CA name requires some thought, because all issued certificates are tied to the CA name of the issuing CA. After the CA is created, no rename capability is available. Using the organizational naming convention probably already established for an organization is easiest.

During the Certificate Service installation, a public key pair is generated for the CA that is being created. This key pair is unique to the CA. If an Enterprise CA is being installed, the installation process involves Active Directory, in that a CA object and information about the CA configuration are added to Active Directory.

Before Certificate Services for an Enterprise CA solution can be installed, the administrator must have a properly configured Active Directory environment including Domain Name System (DNS) (which is required for Active Directory). If installing a Standalone CA solution, the administrator may do so with or without an Active Directory environment. To install an Enterprise CA server, the administrator must have administrative rights on the domain controllers, the DNS servers, and the CA server. Computers that have Certificate Services installed on them cannot be renamed, or joined to or removed from a domain after the installation. This makes sense, as performing any of these actions would destroy the CA hierarchy. Exercise 4.01 walks you through the process of installing Certificate Services on a computer.

Exercise 4.01: Installing Certificate Services

1. Click Start | Settings | Control Panel | Add/Remove Programs.

2. In the Add/Remove Programs window, click Add/Remove Windows Components. This brings up the Windows Components window shown in Figure 4.5.

   
   Figure 4.5: Adding Windows Components

3. Select the check box next to Certificate Services. Click Next to continue.

4. You will now be presented with the warning shown in Figure 4.6. You cannot change the computer's name or domain membership after Certificate Services are installed. Click Yes to continue.

   
   Figure 4.6: Installation Warning Window

5. Now you have to choose which type of Certificate Server to create. Choose the correct role in Figure 4.7, select the Advanced Options check box, and click Next to continue.

   
   Figure 4.7: Choosing a Certification Authority Type

6. Selecting the Advanced options check box presents the window shown in Figure 4.8.

   
   Figure 4.8: The Public and Private Key Pair

7. Select the Cryptographic Service Provider (CSP) and the Hash algorithm to be used. Click Next.

8. Figure 4.9 shows the CA Identifying Information window. You must enter a unique name for your CA. This is where you choose how long certificates will be valid—the default is two years. Fill in the needed information and click Next to continue.

   
   Figure 4.9: Certification Authority Identifying Information

9. You will now be presented with the Data Storage Location window shown in Figure 4.10. Enter the location of the certificate database and the certificate database log. The default is percentwindir%\system32\certlog. For fault tolerance, put the database and the log on separate drives. Click Next to continue.

   
   Figure 4.10: Selecting Database Storage

10. If prompted to create a folder, select Yes.

11. If the Internet Information Services (IIS) are running on your computer, you will be presented with the window shown in Figure 4.11. IIS must be stopped to allow some of the Certificate Services components to be installed and configured.

    
    Figure 4.11: Stopping IIS

12. Click OK to stop IIS from running and continue the install. After this, Certificate Services will be installed and configured on your computer.

13. After setup has finished, you will see the Completing the Windows Components Wizard window. Click Finish to accept the changes.

When configuring a complete Windows 2000 CA hierarchy, the first CA is installed as an Enterprise Root CA. The process to install and configure an Enterprise Subordinate CA is almost exactly the same with the differences being that it must be configured to act as a Subordinate CA instead of a Root CA. The process for configuring Standalone Root CA's and Subordinate CA's is also very similar and does not require the presence of Active Directory.

Test Day Tip 

It is critical when implementing Certificate Services to understand all of the various CA arrangements that can be configured. Each type of CA has its own strengths and weaknesses, as well as requirements. As is true in most things, there is no one universal solution when it comes to setting up a CA hierarchy—your individual situation will dictate your design. For the test, you need to understand the differences between the types of CAs and their requirements. You can expect to see at least one or more questions on this area in particular.

Once Certificate Services have been installed and configured on a network, it pretty much takes care of itself. Users request certificates using the templates configured to be available and these requests are processed as selected—either automatically approved or placed into a queue for manual approval. There are, however, some additional tasks that need to be completed to keep the CAs operating smoothly.

Exam Warning 

Watch out for scenarios that call for code-signing certificates. These always require a trusted, verifiable third-party Root CA such as VeriSign. If you only intend to digitally sign code for distribution within your own internal network, the need for a third-party Root Certificate may not be very strong. If you are distributing applications or ActiveX applets to customers and other users, you must use a third-party Root Certificate to lend trustworthiness and creditability to the certificate you are using to sign the code.

Head of the Class…
The Need for Stand-alone CAs

When you think of a stand-alone CA, you probably think of a lot of reasons why not to use it. It does not participate in Active Directory and thus is not nearly as robust or flexible as an Enterprise CA. However, despite its downside, stand-alone CAs have one very important and valuable thing working in their favor: they can be used to issue certificates as required, and then physically removed from the network. The old saying goes, "network security begins with physical security," and it certainly holds true. Being able to remove a CA from the network and place it into a safe, secure location greatly increases its security. Just remember the downside to doing so: clients will not be able to request and automatically receive certificates from a CA that has been removed from the network—an administrator will have to manually issue them and ensure they are delivered to the required location.

Note 

All of the following examples presume that an Enterprise CA system has been installed.

Exam 70-124: Objective 3.5.1, 3.5.3, 5.1.5, 5.1.6, 5.2.1: Requesting a Certificate

It makes sense that the first thing an administrator would want to do after installing and testing a new CA would be to start issuing certificates to their users. They can use the Certificate Request Wizard or the Certificate Services Web page to request a certificate. The wizard is only available when requesting a certificate from an Enterprise CA.

Exercise 4.02 walks you through requesting a certificate with the Certificate Request Wizard via the Certificate snap-in. Exercise 4.03 walks you through requesting a certificate with the Certificate Request Web page.

Exercise 4.02: Using the Certificate Request Wizard

You must first create a custom console containing the Certificate snap-in if not already done:

1. Click Start | Run.

2. Type MMC in the Open line. Click OK. This opens a blank MMC.

3. You now need to add the Certificate snap-in. Click on Console.

4. Choose Add/Remove Snap-in from the pop-up menu.

5. Click Add. Choose Certificates from the list of available snap-ins (see Figure 4.12). Select My User Account.

   
   Figure 4.12: Selecting the Certificates Snap-in

6. Click Finish.

7. Click Close on the Add Standalone Snap-in window.

8. Click OK on the Add/Remove Snap-in window.

   Now you can use your custom console to complete this exercise.

9. Expand Certificates | Current User.

10. Expand Personal. Right-click on Certificates and select All Tasks | Request New Certificate from the context menu, as shown in Figure 4.13. This starts the Certificate Request Wizard.

    
    Figure 4.13: Requesting a Certificate with the Wizard

11. Click Next to dismiss the opening page of the wizard.

12. You will now be prompted for what type of certificate to request, as shown in Figure 4.14. Choose the correct certificate type (User for this example) and click Next. If you want to configure advanced options, such as the CSP, select the Advanced check box before clicking Next.

    
    Figure 4.14: Selecting the Certificate Type

13. Enter a friendly name and description for your certificate, as shown in Figure 4.15, and click Next to continue.

    
    Figure 4.15: Entering Details for the Certificate

14. Click Finish to complete the process. If your request was approved, you will see a window as shown in Figure 4.16. Click Install Certificate to install your newly approved certificate.

    
    Figure 4.16: Installing the New Certificate

15. Click OK to complete the process.

Now we will examine the process of requesting a new certificate using the Certificate Services Web interface as detailed in Exercise 4.03.

Exercise 4.03: Using the Certificate Services Web Interface

1. Open Internet Explorer and enter http://server_name/certsrv. This opens the page shown in Figure 4.17.

   
   Figure 4.17: Requesting a Certificate via Web Enrollment

2. Select Request a certificate and click Next. You can also check on a previous certificate request or view the current CRL from this page if you desire.

3. Select Advanced request and click Next. This takes you to the page shown in Figure 4.18.

   
   Figure 4.18: Advanced Request Options

4. Choose Submit a certificate request to this CA using a form. Click Next to continue. You must next choose a certificate template, as shown in Figure 4.19.

   
   Figure 4.19: Selecting the Template

5. Select EFS Recovery Agent. Scroll down to the bottom of the page and click Submit.

6. You will now be issued the certificate. You must now install the certificate by clicking on the Install this certificate link. This installs the certificate and informs you of the fact.

Exam Warning 

Remember: if you do not have an Enterprise CA setup you will not be able to use Web Enrollment.

The certificate enrollment used by Microsoft in Windows 2000 is based on the industry standard PKCS-10 and PKCS-7. PKCS-10 is the standard for a certificate request message, and PKCS-7 contains the issued certificate or certificate chain. The Windows 2000 operating system currently supports certificates based on RSA keys and signatures, Diffie-Hellman keys, and Digital Signature Algorithm (DSA) keys and signatures.

Exam 70-124: Objective 3.5.1, 3.5.3, 5.1.6: Exporting and Importing Certificates

From time to time it may become necessary to export a certificate and its private key for any number of reasons. Some of the possibilities include Encrypting File System (EFS) recovery (discussed in Chapter 5 in greater detail), backing up a certificate for disaster recovery, or simply moving a certificate from one computer to another. Fortunately, Windows 2000 makes it easy to export a certificate and corresponding private key easily through the Certificates snap-in. If the private key is exported, the information is encrypted as a PKCS-12 (Public Key Cryptography Standards) message to protect it from prying eyes. Exercise 4.04 details the certificate exportation process. Any exported certificate eventually has to be imported, so the importation of certificates is examined in Exercise 4.04. You may also find the need to.Exercise 4.05 details how to import external certificates, such as those from a Trusted Root CA, into a personal certificate store.

Exercise 4.04: Exporting a Certificate and a Private Key

1. Expand Certificates | Current User.

2. Expand Personal.

3. Select Certificates.

4. In the details pane (right side) right-click the certificate that you want to export and choose All Tasks | Export (see Figure 4.20). This starts the Certificate Export Wizard.

   
   Figure 4.20: Exporting the Certificate

5. Click Next to dismiss the opening page of the wizard.

6. As shown in Figure 4.21, choose whether you want to export the certificate with or without its private key. In this example, we will export the certificate and its private key by selecting Yes, export the private key. Click Next to continue.

   
   Figure 4.21: To Export the Private Key or Not to Export the Private Key

7. From the window shown in Figure 4.22, select the file format that you want to use. In this example, we will be using the PKCS #12 format, as it is the only one that supports exporting the private key. You can also opt to configure more advanced options, such as to include all certificates in the path, enabling strong protection and to delete the private key after successful exportation (this is a good way to prevent the key from being used by any unauthorized personnel). Click Next after configuring your options.

   
   Figure 4.22: Selecting Certificate Export Options

8. You will now be prompted for a password to assign to the private key. Enter the password twice and click Next to continue.

9. You will now be asked to specify the name and path of the file you want to export. Enter the name and click Next to continue.

10. Verify that the information is correct and click Finish to complete the Certificate Export Wizard. If all is successful, you will be presented with the window shown in Figure 4.23.

    
    Figure 4.23: The Certificate Export was Successfully Completed

11. Click OK. The certificate can be found in the location you exported it to. Figure 4.24 shows my exported certificate sitting on the Desktop.

    
    Figure 4.24: The Exported Certificate File

Exam Warning 

Pay attention to the question when dealing with exporting certificates to determine whether or not you will need to export the private key as well.

Before doing an export operation of a certificate and its public key pairs, the administrator should look at the CSP being used. When the Microsoft CSP is used, the exporting of key pairs occurs only if the exportable flag CRYPT_EXPORTABLE was set at the time the key was created. Some third-party CSPs may not support the backup and restoration of key pairs and their certificates. If this is the case, only a complete system image backup is possible to provide for restoration of the certificate.

Although Exercise 4.05 examines the importation of a Trusted Root CA certificate, the same process holds true for any certificate you want to import. The main difference is that the process is started from a folder in the certificate store other than the Trusted Root Certification Authorities, as shown in Exercise 4.05.

Exercise 4.05: Importing a Certificate from a Trusted Root CA

1. Expand Certificates | Current User.

2. Expand Trusted Root Certification Authorities. Right-click Certificate and choose Import from the context menu. This starts the Certificate Import Wizard.

3. Click Next to dismiss the first page of the wizard.

4. You will now be asked to select a file to import, as shown in Figure 4.25. Enter or browse to the location of the certificate and then click Next to continue.

   
   Figure 4.25: Selecting the Certificate to Import

5. Type the password assigned to the file and click Next to continue. As shown in Figure 4.26, you may also have additional configurable options. It is always highly recommended to make the private key exportable in case you need to export this certificate and private key later.

   
   Figure 4.26: Configuring Advanced Import Options

6. Choose where to place the certificate and click Next.

7. Verify that you have made the correct choices and click Finish to complete the wizard.

8. You will now be prompted to add the certificate to the Root Store, as shown in Figure 4.27.

   
   Figure 4.27: Adding the Certificate to the Root Store

9. Click Yes. If the addition is successful, you will be informed of such. Click OK.

It is worth mentioning that the Certificate Import Wizard can also be started by double-clicking on an exported certificate file (like the one shown in Figure 4.24). The primary difference in importing a certificate this way is that the administrator will need to specify where to install the certificate at or just allow Windows to handle it automatically.

Exam 70-124: Objective 5.2.2: Revoking Certificates

Certificates tend to be issued with an average lifetime of two or three years. Until they expire, there can be many reasons to cease trusting the credentials. From a security point of view, any of the following circumstances certainly warrant the revoking of a certificate:

• An entity's private key has been compromised

• A project with another organization is completed

• The employee has changed status within the company

• A department is to cease having access to certain information

• The certificate was obtained through forgery

The Windows 2000 public key functions are based on distributed verification, so any revocation of certificates will also be handled in a distributed fashion. There is no need to create a central location for revocation information.

Microsoft designed Windows 2000 revocation around the industry standard CRLs. The Microsoft Enterprise CA publishes the CRLs to Active Directory. From there, domain clients can obtain the information, cache it to the local machine, and then read it from the cache when certificates are verified. Clients can verify certificates when they use a commercial CA or any third-party CA, as long as the published CRL is available over the network. Exercise 4.06 walks you through revoking a certificate and manually publishing a new CRL.

Exercise 4.06: Revoking a Certificate and Publishing a CRL

1. Click Start | Programs | Administrative Tools.

2. Open Certification Authority.

3. Expand the name of your CA.

4. Select Issued Certificates (as shown in Figure 4.28).

   
   Figure 4.28: Listing the Issued Certificates

5. In the details pane (right side) right-click the certificate that you want to revoke and choose All Tasks | Revoke Certificate from the context menu.

6. You will now be asked (see Figure 4.29) if you are sure that you want to revoke the selected certificate. If you are sure, pick a reason code and click Yes to revoke the certificate. You will not be prompted after clicking Yes, so be sure that you have the correct certificate and revocation reason. The possible reason codes are the following:

   
   Figure 4.29: Selecting the Revocation Reason

   • Unspecified

   • Key Compromise

   • CA Compromise

   • Change of Affiliation

   • Superseded

   • Cease of Operation

   • Certificate Hold

7. To publish a new CRL, right-click on Revoked Certificates and choose All Tasks | Publish from the pop-up menu. If your CRL has not expired, this gives you the window shown in Figure 4.30.

   
   Figure 4.30: Manually Publishing a New CRL

8. Click Yes to publish the new CRL.

Damage & Defense…
Revoke Those Certificates

Get rid of certificates as soon as you do not need them—having extra certificates in existence only makes your network that much more vulnerable to compromise and attack. If you no longer have a need for a certificate, such as when a user leaves the organization or if a certificate (or CA) has been comprised, you should immediately revoke any and all affected certificates. Do not leave back doors installed that can allow an unauthorized attacker to gain entrance to your network and impersonate an authorized user.

You should also strongly consider manually publishing the Certificate Revocation List (CRL) to your CRL Distribution Points (CDP) any time you find yourself revoking certificates for reasons such as theft, loss, or termination or user or partner contract. Even if you've revoked a certificate, it may be some time until the next CRL publication interval. When the security of your network is at stake, do it right the first time!

Exam 70-124: Objective 5.1.3, 5.2.3: Configuring Publication of CRLs

The CRL is a file maintained by each CA that specifies certificates that have not reached their expiration date but are no longer valid for any number of reasons. The CRL provides a critical part of certificate verification by ensuring that a certificate that is presented has not been revoked. CRLs are digitally signed by their respective CA, the same as an issued certificate. Although certificates are immediately added to the CRL when they are revoked, the CRL itself is not published immediately to reflect the changes. Administrators can configure the publication interval for CRLs and the location to which they are published—known as CRL Distribution Points (CDPs). By default, CRLs are published on a one-week interval, but the administrator can configure any value between one hour and 9999 years. CDPs can be configured as Active Directory, Hypertext Transfer Protocol (HTTP), or file-based locations. It is very common to configure multiple CDP methods to ensure that clients can always locate the most current CRL. Exercise 4.07examines the configuration of the CRL publication interval and the CDP location

Exercise 4.07: Configuring CRL Publishing Options

1. Click Start | Programs | Administrative Tools.

2. Open Certification Authority and expand the name of your CA.

3. Right-click Revoked Certificates and select Properties from the context menu. This opens the window shown in Figure 4.31.

   
   Figure 4.31: Configuring the CRL Publication Schedule

4. Configure the interval of your choosing. If you want to view the current CRL, click View Current CRL, which opens a window like that shown in Figure 4.32—of course, your CRL will be different.

   
   Figure 4.32: Viewing the Current CRL

5. After you have configured the CRL publication schedule (or disabled publication by selecting the Disable publication schedule checkbox), click OK to close out the Revoked Certificates Properties window.

6. If you need to change the CRL publication location, you can do so by right-clicking on the CA name and selecting Properties. Switch to the Policy Module tab and click the Configure button. This opens the window shown in Figure 4.33.

   
   Figure 4.33: Configuring the CRL Distribution Points

7. Change to the X.509 Extensions tab and click Add CDP. Enter the URL, file, or Active Directory location you want to publish to and click OK three times when you are done.

8. To manually force publish the CRL after you have made the modifications, right-click on the Revoked Certificates folder and select All Tasks | Publish from the context menu.

Exam Warning 

As simple and trivial as it seems, configuring the CRL publication interval and location is very important. You should expect to be tested in some depth about the specifics of these operations.

Exam 70-124: Objective 5.1.2: Configuring Certificate Templates

Certificate templates are used to define policies that control the generation and use of a certificate. A template is identified by a common name that usually associates with the group for which the template was designed, such as the Engineers template or the Developers template.

A template defines components to be incorporated into a certificate, such as :

• Name requirements

• The expiration date

• The CSP

• The public key generation algorithm

The Enterprise CA gets a set of templates with its policy object. The certificate templates available through the Certification Authority Console can be changed, as shown in Exercise 4.08. Table 4.2 lists the types of user templates available by default and Table 4.3 lists the types of machine templates available by default.

Exercise 4.08: Selecting the Available Certificate Templates for New Certificate Issue

1. Click Start | Programs | Administrative Tools.

2. Open Certification Authority and expand the name of your CA.

3. Right-click Policy Settings, as shown in Figure 4.34.

   
   Figure 4.34: Selecting the Certificates to Issue

4. Choose New | Certificate to Issue from the context menu. This gives you the window shown in Figure 4.35.

   
   Figure 4.35: Adding New Templates

5. Select the certificate template to be available on your CA and click OK.

Table 4.2: Templates Available for Users

Template Name	Purposes
Administrator	Code signing, Microsoft trust list signing, EFS, secure e-mail, client authentication
Certification authority	All
ClientAuth	Client authentication
CodeSigning	Code signing
CTLSigning	Microsoft trust list signing
EFS	Encrypting File System
EFSRecovery	File recovery
EnrollmentAgent	Certificate request agent
SmartcardLogon	Client authentication
SmartcardUser	Client authentication, secure e-mail
User	EFS, secure e-mail, client authentication
UserSignature	Secure e-mail, client authentication
Exchange enrollment agent (offline request)	Certificate request agent
Exchange user	Secure e-mail, client authentication
Exchange user signature	Secure e-mail, client authentication

Table 4.3: Templates Available for Machines

Certificate Template Name	Certificate Purposes
Certification authority	All
Domain controller	Client authentication, server authentication
IPSECIntermediateOffline	IP Security
IPSECIntermediateOnline	IP Security
MachineEnrollmentAgent	Certificate request agent
Machine	Client authentication, server authentication
OfflineRouter	Client authentication
SubCA	All
WebServer	Server authentication
Exchange user signature	Secure e-mail, client authentication

Exam 70-124: Objective 5.1.4: Configuring Public Key Group Policy

Windows 2000 fully uses the Kerberos security standard, thus providing single point logons at the enterprise level. Any policy, including the security policy, can be globally established for an entire enterprise, a site, a domain, or an organizational unit. The security policy, once set, would then affect the groups of users or computers defined on the network.

The public key security policy is just one element of the overall Windows 2000 security policy and is a component of the PKI. The security policy is enforced globally, but for ease of administration, it can be centrally defined and managed.

Configuring Automatic Certificate Enrollment

The CA contains numerous properties that are tied to its use. The administrator can use the Microsoft Management Console Certificate snap-in to specify the certificate policy that will control the generation and use of certificates by the CA. When they are specified, the properties restrict when certificates are valid. A user can use the certificate to validate secure mail but may not be allowed to use the certificate's private key for digital signatures. These objects may be restricted in any combination:

• Server authentication

• Client authentication

• Code signing

• E-mail

• IP security end system

• Internet Protocol Security (IPSec) tunnel

• IPSec user

• Timestamping

• Microsoft EFS

To make the PKI transparent to the user, Windows 2000 had to make it possible to support automatic certificate enrollment, which is controlled by certificate types and auto-enrollment objects. Both of these elements are integrated with the group policy object, so they can be defined at the site, the domain, the organizational unit, the computer, or the user level. Exercise 4.09 walks you through configuring automatic certificate enrollment through a group policy object.

Exercise 4.09: Configuring Automatic Certificate Enrollment

1. Click Start | Programs | Administrative Tools.

2. Open Active Directory Users and Computers.

3. Right-click on the domain and choose Properties from the context menu.

4. Switch to the Group Policy tab. Select the Default Domain Policy GPO or any other that you want to work with.

5. Click Edit. This opens a window similar to that shown in Figure 4.36.

   
   Figure 4.36: The Group Policy Editor

6. Expand the following nodes: Computer Configuration | Windows Settings | Security Settings | Public Key Policies.

7. Right-click on Automatic Certificate Request Settings (see Figure 4.37) and select New | Automatic Certificate Request from the context menu. This opens the Automatic Certificate Request Setup Wizard.

   
   Figure 4.37: Configuring Automatic Certificate Enrollments

8. Click Next to dismiss the opening page of the wizard.

9. Choose a certificate template (see Figure 4.38) and click Next to continue.

   
   Figure 4.38: Selecting a Template for Use

10. Select the CA or CAs that should be used to issue this certificate (only one of the selected CAs will issue any one specific CA) and click Next to continue.

11. Click Finish to complete the wizard.

Configuring the Trusted Root CAs

While Figure 4.4 shows how to manage Trusted Root CA certificates from within the Certificate Services snap-in, the changes made there will only apply to the computer they are configured on. To easily make additions to the Trusted Root CAs readily available for the entire domain, the administrator should consider configuring their domain Group Policy Object. To configure Trusted Root CAs using Group Policy, complete the steps outlined in Exercise 4.10.

Exercise 4.10: Configuring Trusted Root CAs

1. Click Start | Programs | Administrative Tools.

2. Open Active Directory Users and Computers.

3. Right-click on the domain and choose Properties from the context menu.

4. Switch to the Group Policy tab. Select the Default Domain Policy GPO or any other that you want to work with.

5. Click Edit. This opens a window similar to that shown previously in Figure 4.36.

6. Expand the following nodes: Computer Configuration | Windows Settings | Security Settings | Public Key Policies.

7. Right-click on Trusted Root Certification Authorities (see Figure 4.39) and select All Tasks | Import from the context menu. This opens the Certificate Import Wizard.

   
   Figure 4.39: Configuring Trusted Root CAs

8. Follow the steps in the Certificate Import Wizard to complete the importation process.

Exam Warning 

You should understand the reason and process behind configuring additional Trusted Root CAs through Group Policy.

Exam 70-124: Objective 5.2.4: Backing Up and Restoring Certificate Services

Microsoft recommends that the entire CA server be backed up. By backing up the system state data on a CA, the administrator will automatically get a backup of the certificate store, the registry, system files, and Active Directory (if the CA resides on a domain controller). Sometimes, the administrator may want to back up just the certificate services portion of the computer without doing a full backup of everything else. Exercise 4.11 walks you through backing up Certificate Services. Backups are only useful if they can be restored. Exercise 4.12 walks you through restoring Certificate Services.

Exercise 4.11: Backing Up Certificate Services

1. Click Start | Programs | Administrative Tools.

2. Open Certification Authority.

3. Expand the name of your CA.

4. Right-click your CA and select All Tasks | Backup CA from the context menu.

5. Click Next to dismiss the opening page of the wizard.

6. You will now be prompted to select the items to be backed up, as shown in Figure 4.40.

   
   Figure 4.40: Selecting Items to be Backed Up

7. Choose what to back up and the backup location and click Next.

8. Type in the backup password twice and click Next.

9. Click Finish to close the wizard.

If you need to restore your Certificate Services backup, proceed as outlined in Exercise 4.12.

Exercise 4.12: Restoring Certificate Services

1. Click Start | Programs | Administrative Tools.

2. Open Certification Authority.

3. Expand the name of your CA.

4. Right-click your CA and select All Tasks | Restore CA from the context menu. This gives you the notice shown in Figure 4.41.

   
   Figure 4.41: Stopping Certificate Services

5. Click OK to stop Certificate Services from running and start the wizard.

6. Click Next to continue. You will now be given the window shown in Figure 4.42.

   
   Figure 4.42: Selecting What to Restore

7. Select the items to be restored and the restore file location and click Next.

8. You must now enter the password assigned to the restore file. Enter the password and click Next.

9. Click Finish to complete the wizard.

10. You will now be prompted to restart the certificate services, as shown in Figure 4.43. Click Yes to restart the services.

    
    Figure 4.43: Restarting Certificate Services

Exam Warning 

You should be familiar with the process to back up and restore Certificate Services from the Certification Authority console.

Notes from the Underground…
Nothing in Life Is Perfect

No security method is foolproof, and this includes the use of CAs to verify identity. In early 2001, someone tricked VeriSign into believing that they were a legitimate Microsoft employee and they received two digital certificates from VeriSign to be used for code signing (see www.microsoft.com/technet/security/bulletin/ms01-017.asp). What is even more interesting (or scary, depending on how you look at it) is that this security failure went unnoticed for a month before VeriSign caught onto the problem and revoked the digital certificates.

So, if one of the pioneers in the digital certificate game can be tricked by some slick social engineering into giving out two high-level digital certificates, what are the odds that the same thing might not happen to you on your network? No matter how secure you think you are or how many layers deep your defensive posture is, always remember that an attacker is one step ahead of you…they just do not know it yet. Eventually every system can and will be penetrated if someone tries hard enough and has the capabilities to pull off the attack. This is why "defense in depth" is such a critical concept. The more layers of defense you have in your network, the better your odds are of keeping an attacker out, or at worst, detecting and tracking an attacker should they penetrate your defenses. Never stop thinking you have done enough to protect your network because nothing in life is perfect.