Professional Windows Server 1002003 Security A Technical Reference [Electronic resources]

Roberta Bragg

نسخه متنی -صفحه : 194/ 117
نمايش فراداده

Install and Configure a Subordinate CA

After the root CA is prepared, the subordinate CA must be installed. The following example installs and configures an enterprise subordinate CA. A standalone subordinate CA could also be installed but would not have the flexibility that an Enterprise CA has. In this example, the subordinate CA of the root CA will be the issuing CA for chicago.local. However, best practices indicate that a middle layer of intermediary subordinate CAs, which may or may not be kept offline, should be created. This layer provides flexibility, especially when organizations are large, when organizations anticipate cross-certification with partner CA hierarchies, or when the certificate usage will be large. However, it is not necessary, especially for smaller organizations, and providing instructions for the configuration of this layer would add little to this chapter. If you require a broader CA hierarchy, extensive information is available in the "Best Practices for Implementing a Windows Server 2003 Public Key Infrastructure" paper previously mentioned in this chapter.

Installing the Subordinate CA

To install the enterprise subordinate CA, a certificate request file must be generated on the subordinate CA computer. This request is used to manually obtain a certificate from the root CA. The certificate must then be installed on the subordinate CA. If the subordinate CA will also perform the Registration Authority role, IIS must also be installed.

Enable the Use of ASP on IIS

Windows Server 2003 IIS installs in a locked down configuration. You must enable the use of ASP pages for the CA Web Enrollment pages to work:

1.

Open the Internet Information Services Manager console.

2.

Select the Web Services Extension folder.

3.

Right-click the ASP pages button and select Properties.

4.

Select the Requires Files page.

5.

Select the file asp.dll and click Allow.

6.

Confirm that ASP extensions are now "Allowed," as shown in Figure 13-17.

Figure 13-17. Confirm that ASP pages may be used on the CA web server.

Start the Installation

The first step of the subordinate CA installation adds the files and registry keys and creates the certificate request file. If the CA that will provide the certificate is online, the CA certificate can be requested online, but that is not the case with the root CA. To start the installation and obtain a certificate request file, follow these steps:

1.

Log onto the subordinate CA server computer regalinn as a member of the Domain Admin group.

2.

Go to Start, Settings, Control Panel, Add or Remove Programs, Add/Remove Windows Components.

Figure 3-18. Intermediate and issuing CAs in a CA hierarchy must be subordinate CAs. When integration with Active Directory is desired, an Enterprise CA role should be selected. However, no rule says intermediate CAs have to be Enterprise CAs. They also can be standalone CAs and receive stronger protection, even offline status. This increases management but improves security.

Figure 13-18. Selecting an enterprise subordinate CA.

6.

Select the Use custom settings to generate the key pair and CA certificate check box, and then click Next.

7.

Change the key length to 4096, and then click Next.

8.

Enter the common name for this CA (in our example, SubCA), as shown in Figure 3-19, and then click OK. Note that the Distinguished name suffix, DC=chicago, DC=local is added for you, and the entire Distinguished name, CN=SubCA, DC=chicago, DC=local, is displayed. The figure shows that the validity period is determined by the parent CA.

Figure 13-19. Adding the common name for the CA.

9.

Click Next.

NOTE: Keys Are Generated by the Computer

The keys are generated at this point. Note that this computer generates the keys. The certificate will be produced by the root CA, but the keys are created locally on the local CA.

10.

Accept the default database and log locations and click Next.

11.

Click the Save the request to a file radio button, as shown in Figure 13-20, and then click Next.

Figure 13-20. Saving the certificate request.

12.

When prompted to stop IIS, click Yes. Then, wait while components are configured.

13.

Click OK at the message reminding you that the certificate request file must be used to obtain a certificate from the parent CA.

14.

Finish the installation of the CA. The installation will complete, but the service will not start until a CA certificate is obtained and installed.

15.

Copy the regalinn.chicago.local_subCA.req file to a floppy disk.

Obtain a Root CA Certificate from the Root CA

The certificate request file must be transported manually to the root CA and used to request a CA certificate. The certificate will be added to the Pending folder of the CA:

1.

Log on to the root CA as the Administrator.

2.

Insert the floppy or other media that includes the certificate request file.

3.

Open the Certification Authority console.

4.

Right-click the root1, click All Tasks, and then select Submit New Request.

5.

Enter the path or browse to A:\ regalinn.chicago.local_ subCA.req and click Open. The request is processed.

6.

Select the Pending Requests folder to see the CA certificate request, as shown in Figure 13-21. Note the Request ID, which is 2. The Request ID will also be shown in the Issued Certificates node and is required to request a copy via the command line of the certificate.

Figure 13-21. Viewing the Certificate Request.

[View full size image]

7.

Right-click the request, click All Tasks, and then select Issue.

Inspect the Subordinate CA Certificate and Obtain the Request ID

The new subordinate CA certificate should be inspected to ensure the correct CDP and AIA locations are present:

1.

In the Certification Authority console, select the Issued Certificates node.

2.

In the detail pane, note the Request ID for the subordinate CA certificate. In this example, the Request ID is number 2.

3.

Double-click the certificate to view it.

4.

Select the Details page and select the CRL Distribution Points field. Confirm that the distribution point is correct in both location and syntax. An example is shown in Figure 13-22.

Figure 13-22. Verify the CDP.

5.

Select the Authorities Information Access field and confirm that the location is correct both in location and syntax. An example is shown in Figure 13-23.

Figure 13-23. Verify the AIA.

6.

Click OK to close the certificate view.

Use certreq to Retrieve a Copy of the Certificate

The CA certificate is issued to the root CA database. To complete the installation of the subordinate CA, the certificate must be placed in a file and installed on the subordinate CA. To obtain a copy of the CA certificate for the regalinn CA, use the certreq command. The root CA computer, CA name, Request ID, and a file path must be listed:

1.

From a command prompt, issue the following command:

certreq retrieve config motorin\rootA 2 subcert.p7b

Install the CA Certificate

The CA certificate file is then used to install the CA certificate at the CA console:

1.

Log on to the subordinate CA and open the Certification Authority console.

2.

Right-click the CA node, click All Tasks, and then select Install certificate.

3.

Browse to the floppy disk with certificate file and click Open.

4.

The CA node should turn green to indicate that the service is started.

NOTE: CA Certificate Automatic Publishing

Because the subordinate Enterprise CA is integrated with Active Directory, the CA certificate will be automatically published to the Active Directory.

Time Differences

Recently, I assisted a client in setting up a PKI in a test network. All went smoothly until we went to install the subordinate CA certificate. The error indicated that the validity period was not correct. When the certificate was inspected, the Valid From time on the certificate was 10 minutes ahead of the current time on the subordinate CA. When the CA certificate is not valid, it cannot be installed. To be valid, the certificate must not be expired, and its Valid From time must already have passed on the CA to which it will be installed. In this case, because the time difference was slight, we simply waited 10 minutes, then tried again and were successful. We did manually synchronize the time on the root CA with the Active Directory.

Configure a Subordinate CA

After the enterprise subordinate CA is installed, but before it issues certificates, the following tasks should be completed:

1.

Back up the CA keys.

2.

Establish the CRL and delta CRL publishing schedules.

3.

Set auditing in the Active Directory and for the CA (see setting auditing for the rootCA).

4.

Set permissions on all the templates.

5.

Establish role separation.

6.

Configure autoenrollment and other Group Policy for PKI.

Steps 1 and 2 can be done in the same manner as they were done for the root CA. Setting auditing in Active Directory is similar to setting auditing in the Local Security Policy. It should be done in the OU in which the CA member server resides. The CRL and delta CRL publishing schedule is set by default, but you need to modify it to fit.

Restrict Certificate Usage by Setting Permissions

Certificate templates are stored in the Active Directory and are managed outside of the CA. Even if some templates will not be used, permissions should be set for all templates. Many certificates can be autoenrolled and others can be requested and obtained without any need to validate the request. If a user or computer can authenticate, and the certificate is not restricted, the certificate will be issued. Restrict certificates by setting the Enroll permission on the template, by removing certificate templates from the CA console, and for V2 templates, by requiring approval before the requested certificate is issued. Information on configuring V2 templates is provided in the section, "Use Custom Templates to Configure Key Archival for EFS."

Set Template Permissions

To set permissions on certificate templates, follow these steps:

1.

Open the Certification Authority console.

2.

Right-click the Certificate Templates node and select Manage. The Certificate Templates console opens.

3.

Double-click a template and then select the Security tab.

4.

Use the object picker to select the group that should have permission to request the template.

5.

Select this group and give them the Read and Enroll permissions.

6.

Select Domain Users, or any other group that has been given the Enroll permission and shouldn't have it, and then click the Enroll permission to deselect it.

7.

Click OK to close the certificate.

8.

Repeat for each certificate template.

9.

Close the Certificate Templates console.

Restrict Certificate Usage by Limiting the Certificates the CA Can Issue

Just as the root CA and any intermediary CAs should issue only CA certificates, the issuing CA should issue only those certificates they are authorized to issue. The certificates each CA should issue are a matter of security policy and CA hierarchy design, but no issuing CA should issue CA certificates. Removing the certificates listed in the Certificates Template node of the CA can prevent the CA from issuing them. However, any administrator with the proper privileges can add them back in. Removing the certificates, however, will prevent accidental issuance of these certificates. Audit the Enterprise CA to confirm compliance.

Limit the Certificates the CA Can Issue

1.

Open the Certification Authority console.

2.

Select the Certificate Templates node.

3.

Right-click the subordinate CA certificate template and click Delete.

4.

Click Yes to confirm the deletion.

5.

Repeat until all certificates templates that you do not want this CA to issue are removed.

TIP: Templates Are Persistent

Removing templates from the Certificate Templates node does not remove the certificate templates; it simply prevents the CA from issuing certificates of this type.

Establish Role Separation for the Subordinate CA

Role separation is the process of dividing the CA administration duties among several people. To delegate administrative responsibilities, assign permissions on the CA to different custom Windows groups. To prevent an individual account from becoming a member of both groups and thus hinder role separation, enforce role separation.

Role separation can be configured and enforced for all CAs. For the offline root, use local computer groups. For an Enterprise CA, use global computer groups. In an environment where a large number of certificates will be issued, you may want to further divide the role of Certificate Manager. To do so, create multiple Certificate Manager groups. Then, use the Restrict Certificate Manager CA property page to assign each group the responsibility of managing groups of users and computers.

Separating Administrative Roles

1.

Use Active Directory Users and Computers and create three new groups: CA Administrator, Certificate ManagerA, and Certificate ManagerB.

2.

Add authorized users to the appropriate groups. Make sure that no account is added to both CA Administrators and either of the Certificate Manager groups. Each authorized user account must only be added to one group. Remember, once role separation is enabled, if a user has both privileges, he will not be able to use either.

3.

Log on to the CA as the Administrator.

4.

Open the Certification Authority console.

5.

Right-click the CA node and select Properties.

6.

Select the Security tab.

7.

Click Add, then enter or use the object picker to add the CA Administrator group, and then click OK.

8.

Select the CA Administrator group and click the Manage CA permission.

9.

Click Add, then enter or use the object picker to add the Certificate Manager group, and then click OK.

10.

Select the Certificate Manager group and click the Issue and Manage Certificates permission, as shown in Figure 13-24. This creates the two CA roles. You can name the groups whatever you please when you assign the security permission that provides them the ability to perform the role.

Figure 13-24. Configuring CA roles.

11.

Select the local Administrators group and clear the Issue and Manage Certificates and Manage CA permissions. To provide role separation, the local Administrators group cannot have either permission. If role separation will be enforced, make sure that these permissions are removed before role separation is enforced.

12.

On the CA computer, make the new groups members of the local Administrators group.

Enforce Role Separation

If role separation is not enforced, an individual account could be a member of both groups and therefore have full control of the CA. To enforce role separation, follow these steps:

1.

Open a command prompt on the CA and enter the following command. (The setreg switch adds the information to the registry, and ca\RoleSeparationEnabled is the registry key that controls role separation. When it has a value of 1, role separation is enabled.)

certutil -setreg ca\RoleSeparationEnabled 1

2.

To verify that role separation has been applied, enter the following command:

certutil -getreg ca\RoleSeparationEnabled

3.

Stop and start certificate services:

Net stop certsvc
Net start certsvc

TIP: Remove Role Separation

If you have incorrectly enabled role separation and need to remove it, enter the following command:

certutil -delreg ca\RoleSeparationEnabled

Restrict Certificate Managers

To limit certificate managers by Windows group, follow these steps:

1.

Open the Certification Authority console.

2.

Right-click the CA and select Properties.

3.

Select the Certificate Manager Restrictions page.

4.

Select Restrict Certificate Managers.

5.

Use the drop-down box to select a Windows group that has been given the permission Issue and Manage Certificates.

6.

Use the Add button to add Windows groups that this certificate manager group should have responsibility for, as shown in Figure 13-25.

Figure 13-25. Restrict Certificate Managers by assigning them management of specific Windows groups.

Configure Autoenrollment

The process by which a user or computer certificate is issued can be broken into three parts:

Request A certificate is requested by some manual action, such as by using the web enrollment pages or the certificates snap-in. A certificate request may also be automatically issued when a user or computer authenticates to Active Directory.

Issue A certificate request is approved, and the certificate is created.

Distribution The certificate is installed in the certificate stores of the computer.

Autoenrollment, which is the performance of these activities without user intervention can be configured in many cases. In other cases, user intervention is required. Autoenrollment is configured in three places:

On the Policy property page of the CA, as shown in the configuration sections of both the offline root CA and the enterprise subordinate CA. There are two choices: certificates may require a Certificate Manager approval, or they may be issued automatically. If the CA is a Windows Server 2003 Enterprise Edition Enterprise CA, certificates may be issued according to configuration of the V2 certificate.

In the certificate template.

In Group Policy.

For more information on capabilities for certutil, check http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/sag_cs_certutil2.asp.

Configure Autoenrollment Using Certificate Templates

The Certificate Templates console displays the certificates and basic information about them. A column is provided for autoenrollment status. Each certificate, as shown in Figure 13-26, is marked as either autoenrollment Allowed or autoenrollment Not Allowed. In the figure, the Key Recovery Agent certificate is marked as Allowed. This does not mean the certificate is automatically issued; in this case, it just means that the certificate can be installed without user intervention. Double-click the certificate to view it, and on the Issuance Requirements page, note that the box CA Certificate Manager Approval is checked (see Figure 13-27). If an authorized individual requests the certificate, and the CA Certificate Manager issues the certificate, the certificate is automatically installed in the user's Personal certificate store.

Figure 13-26. Certificate templates are marked autoenrollment Allowed or Not Allowed.

[View full size image]

Figure 13-27. The Key Recovery certificate issuance requires CA Certificate Manager approval.

Template configuration sections on several template property pages can have an impact on autoenrollment. Select these settings, as described in Table 13-2, to configure templates for autoenrollment. While only a Windows Server 2003 Enterprise Edition CA or a Windows Server 2003 Datacenter Edition CA can be used to configure the properties of the certificates, autoenrollment is possible based on template defaults and Group Policy configuration no matter which Windows CA is used.

Table 13-2. Autoenrollment Certificate Template Settings

Property Page

Setting

Description

Request Handling

Enroll subject without requiring any user input

Users won't know that a certificate is being installed.

Request Handling

Prompt the user during enrollment

The user is notified and may need to take an action, such as inserting a smart card.

Request Handling

Prompt the user during enrollment and require user input when the private key is used.

During enrollment and during use, the user must take some action.

Request Handling

CSP selection

A number of CSPs that can be used by the template are listed. The user is given a choice.

Subject Name

Supply in the request

Disables autoenrollment of certificates based on this template because the user must be prompted to enter a subject name.

Issuance Requirements

This number of authorized signatures

If a number greater than 1 is entered, autoenrollment based on this tem-plate is disabled. If a 1 is entered, the user must have a valid signing certificate in his certificate store. The valid certificate is specified in the Application Policy and Issuance Policies section of this page.

Issuance Requirements

Valid existing certificate

If configured, the subject may not need to supply a valid signing certificate for certificate renewal of a valid certificate based on this template.

General

Validity period and renewal periods

Autoenrollment will not renew a certificate unless 20 percent of the certificate lifetime has expired (prevents autoenrollment based on improper configurationshort validity periods that overlap with renewal periods).

Certificate Template Permissions can also impact autoenrollment. The permissions are as follows:

Read Discover the template in Active Directory.

Enroll Request and receive the certificate.

Full Control All actions.

Autoenroll Automatically enroll. This new permission is only present on v2 templates. Templates customized by duplicating v2 templates will also have the permission. A user must have the Enroll and Autoenroll permission.

Write Modify templates.

TIP: Check Permissions

The Enterprise CA must also have Enroll permission on the template. Typically, the Enterprise CA gets this permission because it is a member of the Authenticated Users group. If you remove the Enroll permission for the Authenticate Users group, be sure and add the Enterprise CA and provide it permissions if you want autoenrollment to occur.

Configure Autoenrollment in Group Policy

Group Policy PKI settings are configured in the Computer Configuration, Windows Settings, Security Settings, Public Key Policy and in the User Configuration path. Policies that can be configured are as follows:

Encrypting File System

Automatic Certificate Request Setting

Trusted Root Certification Authority

Enterprise Trust

At the root of the Public Key Policy folder, in the details pane, there is also an Autoenrollment policy. This policy turns on or turns off autoenrollment, as shown in Figure 13-28, for this GPO. To enable autoenrollment for users and computers, you must enable enrollment in both User Configuration and Computer Configuration paths.

Figure 13-28. Turn autoenrollment on or off for a GPO.

The Automatic Certificate Request Setting policies configure autoenrollment of computer certificates. Right-clicking the policy and selecting New allows the selection of a computer certificate from a wizard page, as shown in Figure 13-29, to automatically enroll authorized computers. Each policy can include only one certificate type.

Figure 13-29. Configure autoenrollment of computer certificates.