Objective 2.2.2: Designing Certificate Distribution

We have learned about PKI design in detail. Now, we put the theory to practice. We will learn how to implement a PKI implementation from scratch. The first step is to install the certificate server on Windows Server 2003. This not installed by default.

Test Day Tip  

You should not install a CA on a FAT file system The FAT system will not support domain-based security. The best practice is to install CA on an NTFS system. The NTFS system will enable seamless interaction with Active Directory and share user account information.

Exercise 3.01: Installing a CA on Windows Server 2003

1. Navigate to Start Control Panel Add Remove Programs .

2. Select Add Remove Windows Components from the left pane.

3. You will be presented with a Windows Components Wizard window. Choose Certificate Services from the options available. Your screen should be similar to Figure 3.7.

   
   Figure 3.7: Selecting Certificate Service to Install

   You will get a message box as soon as you click the Certificate Services option box. This is a warning sign to make the user aware of the consequences of changing the machine name and the domain of the server. The certificates will be invalid if we change the machine name. (The certificates generated form this server will have a binding to server-specific information, the server name.) Active Directory will also lose track of the server if the machine name or domain is reconfigured. The Warning looks similar to Figure 3.8. Click Yes to navigate to the next screen.

4. The next screen will let you select a CA type. There are several types of CA servers: enterprise root, enterprise subordinate, stand-alone root, and stand-alone subordinate. The server will also do a quick check to see whether Active Directory is present in the network. You can install an enterprise root or an enterprise subordinate if Active Directory is present in the network. You will only be able to install a stand-alone CA if Active Directory is not present. The enterprise option will be grayed out in this case. This scenario is illustrated in Figure 3.9. We are trying to create a root CA for demonstration purposes. Select Stand-alone root CA and click Next .

   
   Figure 3.8: Warning Screen before Installing Certificate Services

   
   Figure 3.9: Selecting a CA Type

5. The next screen will let you choose the private and public key pair. Figure 3.10 shows the options available. You can choose a CSP from the CSP menu and associate a hashing algorithm to it. Several CSPs are included in Windows Server 2003: MS Base DSS Cryptographic Provider, MS Enhanced Cryptographic Provider, and MS Strong Cryptographic Provider. The default is MS Strong Cryptographic Provider. There are several built-in hashing algorithms available in Windows Server 2003: MD2, MD3, MD5, and SHA-1. The default is SHA-1. (These are sophisticated hashing algorithms that are used to encrypt data.) We can also select the key length. The key length can be 512, 1024, 2048, or 4096. The default is 2048. The longer the key length, the more secure the transaction is. However, performance can be hindered due to the increase of complexity in key manipulation. You can also import key pairs by clicking the Import button or use an existing key pair. (This is done by clicking the Use an exiting key option.) We have selected the defaults for this demonstration. Click Next to navigate to the next screen.

   
   Figure 3.10: Selecting Public and Private Key Pairs

6. The next screen will let you configure the CA naming for the enterprise. The screen is similar to Figure 3.11. The Common name for this CA is the identity of your CA on the network. We will enter CertificateRootServer as the name. The name should be less than 64 characters . This is a limitation imposed by the Lightweight Directory Access Protocol (LDAP) used by Active

   
   Figure 3.11: CA Identity Information

   Directory. The name will be truncated if it exceeds 64 characters. We also need to enter the distinguished name suffix. This is also an LDAP requirement to populate the Active Directory. This entry will identify our root CA object from the rest of the Active Directory objects. Then, we finally choose the life span of a certificate. We have chosen one month as the preferred life span for a certificate generated by this root CA (the default industry standard is one year). Click Next to navigate to the next screen.

7. The next screen is to configure the certificate database locations and logs. The certificates are stored locally on the CA server. The default location for the certificates is %SystemRoot% \ System 32\certlog. The best practice is to store the certificate on a different physical disk. This will maximize the CA throughput of the server. Your screen should be similar to Figure 3.12. Click Next to proceed to the next screen.

   
   Figure 3.12: Configuring Database Settings

   Exam Warning  

   The Active Directory does not act as a database for the stand-alone CA server. The installation will automatically populate the CA information in the Active Directory if an Active Directory is present on the network. The certificates are stored locally on the CA server and the Active Directory will be informed of the location. The certificates will be stored in user object containers in an enterprise CA implementation.

8. The next step will install the CA on the server. You will also be presented with an information request to stop IIS if you are already running it. Finally, you will be presented with a screen confirming the end of the setup.

 

Head of the Class
CA Web Enrollment Support System

The Windows Server 2003 CA installation will provide an ASP Web front to request and manage certificates. This is installed by default during installation and is referred to as CA Web Enrollment support. You can also uninstall or reinstall this using the Start Control Panel Add Remove Programs Add Remove Windows Components utility. We need to select Certificate Authority and click the Details button. We can select the Certificate Service Web Enrollment Support from the options. We can select or deselect the option to install or uninstall, respectively. This can be used as an alternative to the Microsoft Management Console (CA) window. However, some options are not available in the Web Enrollment Support system (for example, we cannot enable CA server auditing though this interface). This interface will add value to CA administrators to manage the certificates from multiple secure machines. (We do not need to install the CA MMC administration console on other machines to connect to the CA.)

The Web Enrollment Support system provides many services to CA administrators; for example, they can request a certificate using this tool. CA administrators can also view the status of a pending certificate and download a certificate or CRL using these Web pages. The Web enrollment support system adds a certsrv virtual directory to the hosting IIS machine. The local path for this system is http:// < Server Name > /_certsrv/ . The Web Enrollment Support system is commonly used to issue certificates to Web browser applications to authenticate the users.

 

Let s look into some administrate tasks associated with Windows Server 2003 CA server. We will be looking into enrollment, renewal, revocation, and enable auditing on CA servers. We will use the CA Web Enrollment system to request a certificate and use the CA MMC to navigate through the certificate life cycle.

Objective 2.1.2: Designing Enrollment and Distribution

The first step is to request a certificate from the CA. This could be achieved using the Web Enrollment Support system. This interface will generate a certificate and add it to the pending queue of the CA. The CA administrator needs to open the MMC console and grant access to use the certificate.

Exercise 3.02: Request a Certificate from the Web Enrollment Interface

1. Open an Internet Explorer window and navigate to URL http:// < Server Name > /certsrv/ (this will be http://devsvr01/certsrv/ for demonstration purposes).

2. Click the Request a Certificate link. You will be presented with a view similar to Figure 3.13. We are trying to create a certificate for Web browsers. Therefore, we will click the Web Browser Certificate link. You can also generate a certificate to authenticate your e- mails using this interface by selecting the E-Mail Protection Certificate link. The advance certificate request will present you with more options to create sophisticated certificates, including modifying hash algorithms and key lengths of key pairs to the default settings of the CA server.

   
   Figure 3.13: Select a Certificate Type

3. Figure 3.14 shows the next screen you will be presented with. Enter the user details for the certificate. You can also change the default CSP by selecting the More Options link.

   
   Figure 3.14: Enter the User s Details to Issue a Certificate

4. Click Submit to send the request to the CA server. This will enter the certificate details onto a CA pending queue. The CA administrator will approve or deny the request according to the organization policies. The confirmation screen looks similar to Figure 3.15. We need to keep track of the Request ID . We might need to refer to this when we approve the certificate from the pending queue. This ID is automatically generated by the CA server; therefore, your ID number will differ from the one in the exercises.

   
   Figure 3.15: Confirmation Screen for a Certificate Request

 

Any user in the enterprise can log on to this public Web site and request a certificate using these Web pages.

Objective 2.1.2: Approving Certificates by CA Administrators

Let s investigate the CA administrator s role that will approve or revoke these certificates. Note that we are switching roles from an enterprise user to a CA administrator to perform these tasks.

Exercise 3.03: Approve or Deny a Certificate from the CA Pending Queue

1. Navigate to Start Administration Tools Certification Authority .

2. The Certification Authority management console will appear. Navigate to and select Certification Authority < CA Server name > Pending Requests . This will be Certification Authority (Local) CertificateRootServer Pending Requests in our demonstration. Your screen should be similar to Figure 3.16.

3. Right-click on the interested certificate. This will be the certificate with the Request ID 4 (refer to the previous exercise). You will get a context menu. Select All tasks from it and then select Issue . You can also deny the request by clicking the Deny option. Your screen will be similar to Figure 3.17. The certificate will be deleted form the Pending Requests and will be added to the Issued Certificates on approval by the CA administrators.

   
   Figure 3.16: Pending Queue of the CA

   
   Figure 3.17: Approve a Certificate from Pending Queue

4. Navigate to the Issued Certificate folder. You should see the newly issued certificate (Request ID 4). You can view the certificate by double-clicking on the certificate.

 

Objective 2.1.3: Revoking Certificates by CA Administrators

The CA administrator can revoke a certificate before it expires . This is also done through the Certification Authority MMC snap-in. Exercise 3.04 lists the steps to revoke a certificate.

Exercise 3.04: Revoking a Certificate

1. Navigate to Start Administration Tools Certification Authority .

2. The Certification Authority management console will appear. Navigate to and select Certification Authority < CA Server name >. This will be Certification Authority (Local) CertificateRootServer in our demonstration.

3. Navigate to the Issued Certificates and right-click on the certificate you want to revoke.

4. Select All Tasks Revoke Certificate . The certificate will be moved from the Issued Certificates folder to the Revoked Certificates folder.

 

Exam Warning  

Auto-enrollment will automatically issue certificates without a CA administrator. This feature was available in Windows 2000 Server. We could auto-enroll computer certificates in Windows 2000; however, we could not auto-enroll user certificates. The user details could be verified to a higher level of detail. Windows Server 2003 has a better model of integrating with Active Directory. Therefore, auto-enrollment for users is available under Windows Server 2003.

Auto-enrollment features are set by CA administrators in the certificate templates. A user who is authorized to use these Certificate templates will be auto-enrolled. Auto-renewal is also a new feature in Windows Server 2003. This capability will enable CA servers to renew certificates when they expire automatically without any human interaction.

Objective 2.1.3: Establishing Renewal and Auditing

We need to protect the public key and private key pairs of the enterprise. If these keys are compromised, the security of the enterprise is in serious jeopardy. Intruders can cause malicious harm to the resources by getting unauthorized access. A disgruntled employee could act as an intruder to sabotage the IT system. This intruder can log on to the CA server and issue fraudulent certificates to unauthorized users. What will you do as the CA administrator to avoid this scenario?

Test Day Tip  

It is best practice to enable auditing on the CA server activity. This will allow us to see any attempts of hacking in to the CA server. Auditing is a new feature in Windows Server 2003. We can enable auditing on multiple activities that are related to issue certificates.

We can enable auditing on Windows Server 2003 with ease. Let s learn how to do this. Auditing will enable us to monitor activities to identify the issue.

Exercise 3.05: Enable Auditing on a CA Server

1. Navigate to Start Administration Tools Certification Authority.

2. The CA MMC will appear. Navigate to and select Certification Authority < CA Server name >. This will be Certification Authority (Local) CertificateRootServer in our demonstration.

3. Right-click and select Properties from the context menu. You will see the < CA Server Name > Properties window. Navigate to the Auditing tab. Your screen should be similar to Figure 3.18. We might need to track the CA activities. The intruder is changing the CA configuration and issuing fraudulent certificates to others. Therefore, we select the options shown in Figure 3.18.

   
   Figure 3.18: Auditing Tab of the CA Properties

4. Click Apply to apply the new audit policy on the CA. The audit trial will be added to the Security Log in the Event Viewer .

5. Now we can monitor the Security Log in the Event Viewer and track down the disgruntled employee. (Every CA configuration, every CA server setting change, and so forth will be documented in the security log in our demonstration.) The Event Viewer can be found at Start Administrative Tools Event Viewer .

 

After we track down the intruder, we might need to take some extra steps. The intruder was able to get into the CA server and issue certificates. Therefore, the public and private key pairs have been compromised on the CA server. Consequently, we need to reset the key pairs so that the old keys will not grant access to the system. This process is commonly referred as the renewal of keys . You will also need to renew the keys when they expire. Let s learn how to renew keys.

Exercise 3.06: Renewal of CA Keys

1. Navigate to Start Administration Tools Certification Authority .

2. The CA MMC will appear. Navigate to and select Certification Authority < CA Server name >. This will be Certification Authority (Local) CertificateRootServer in our demonstration.

3. Click on the Action menu item. Select All tasks Renew CA Certificates .

4. The dialog box in Figure 3.19 will appear, asking you to stop the certificate server. Select Yes .

   
   Figure 3.19: Confirmation to Stop the Certificate Service

5. You can obtain a new certificate with the old key pairs. Unfortunately, this is not safe because the keys were compromised by the disgruntled employee. Therefore, we need to generate both the certificate and key pairs. You will be presented with a message screen that will confirm to change the keys. It will be similar to Figure 3.20. Click Yes to generate a new key pair. This will generate a new key pair and restart the certificate server.

   
   Figure 3.20: Confirmation to Generate New Keys

   This scenario could be an expensive exercise for the enterprise. It is easy to generate the public key on the server. However, distributing the private key to each employee or business partner will cost money and time. Therefore, we should take strict measures to protect the CA certificate information.

 

Test Day Tip  

We can do all of these MMC console functions using the command-line utility certutil.exe . This was also present in Windows 2000. However, there are some new options available in Windows Server 2003 to mainly interact with the Active Directory. We can publish certificates and CRL lists directly to the Active Directory under Windows Server 2003 CA Server. This could be done with the following syntax.

certutil -dspublish [certcrl]