Deploying the PKI

This paper is part of a series of white papers known as " The Smart Card Deployment Cookbook. "

On This Page

Introduction
Importance of Certificate Server Uptime
Prerequisite Tasks
Installing a Root Certification Authority with Windows 2000 Server
Conclusion

Introduction

This paper provides a step-by-step guide to Microsoft Windows 2000 Public Key Infrastructure (PKI) installation. It identifies crucial points in the installation process, helps you evaluate your progress, and explains the options available before you continue.

Although you can apply this material to production machines, we recommend using a test or lab environment first for the purpose of skill building and preparing department representatives who will be affected by the PKI deployment. Before you begin, you should have a core understanding of PKIs, or work with other personnel who are. If you are not confident regarding your background knowledge, you can pursue the following links as a parallel activity:

Windows 2000 Deployment Planning Guide

https://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/w2rkbook/DPG.mspx?mfr=true

RFC 2527

https://sunsite.dk/RFC/rfc/rfc2527.html

RFC 2459

https://sunsite.dk/RFC/rfc/rfc2459.html

Microsoft Security home page

https://www.microsoft.com/security/

Microsoft Security Bulletin Search

https://www.microsoft.com/technet/security/default.mspx

Importance of Certificate Server Uptime

When the decision was made to deploy a PKI at Hay Buv Toys (HBT), research and discussion revealed the importance of the online Certificate Services and its function in the business.

The online certification authority (CA) is not treated in the same way as a file, print, Web, or mail server. HBT, like most businesses, can tolerate and account for some file, print, and service outages on occasion. The same cannot be said for certificate servers, because the servers are critical to business. The goal and Microsoft recommendation for system uptime and availability is 99.999 percent. In addition, built-in Windows 2000 reporting, monitoring, and notification processes are continuously running to ensure that operations personnel are updated and informed regarding certificate service availability.

Although operations and security personnel at HBT are trusted and competent, the potential to compromise the PKI is increased by the number of personnel who are granted access to the equipment. To address these concerns, the PKI servers are installed in a restricted area, and serviced only by a limited number of senior administrators.

The pilot environment on which this paper is based uses stand-alone servers in a test lab on an isolated network. The material in this paper targets skill building for the pilot environment that you build prior to going into full production. When you document your experiences and incorporate them into the Microsoft Solutions Framework (MSF) best practices, your production deployment will be more streamlined, predictable, and trouble-free.

Prerequisite Tasks

Prior to PKI deployment, your environment should match that described in the previous section. It is recommended that you review the network diagrams for your company, so that you can compare and contrast your lab work against possible scenarios during full deployment. Prior to deployment, you can complete the following tasks:

1. Install and stabilize your Windows 2000 Service Pack 1 (SP1)–based domain server.

2. Install and stabilize a second Windows 2000 SP1–based computer to function as your certificate server.

3. Optional: Install a third Windows 2000 SP1–based computer that can serve as a subordinate to the root certificate server.

   Note: If you intend to use multiple CAs under the primary CA, it is recommended that you install one Windows 2000 SP1–based server for each. In addition, Windows 2000 has a Recovery tab associated with its Properties page. If your company uses Microsoft Exchange 2000 Server, you can use the Run a file option together with utilities such as MAPIsend or MailSend to send an e-mail message to a named user, distribution list, and pager gateway. Using an Exchange Server monitor is another option that provides a graphic image on the computer against which it is run.

4. Install the High Encryption Pack on each server.

Installing a Root Certification Authority with Windows 2000 Server

This installation process makes your root Certification Authority server invisible to your organization because it is not part of your corporate network. It is the subordinate server that will be visible on your network, and to your users and customers. The subordinate server runs your certificate management processes, including issuance and revocation. The strength of this hierarchy is a result of the preparation and maintenance of the servers that are dedicated to management tasks.

Install and Configure Microsoft Certificate Services

Before you begin, you must set up and stabilize the Windows 2000 SP1–based server that will be used as the certificate server, and also install the High Encryption Pack. After this is complete, locate your installation CD and ensure that share point is ready.

The procedure for installing and configuring Microsoft Certificate Services is as follows:

1. On the Start menu, point to Settings, and then click Control Panel.

2. Double-click Add/Remove Programs, click Certificate Services from the Components list, and then click Next.

   

3. When you are prompted, click Yes to continue. Any changes made to this computer after its services are active affect the entire domain.

   

4. Under Certification Authority types, click Stand-alone root CA, select the Advanced options check box, and then click Next.

   

5. With the High Encryption Pack installed, you have an additional cryptographic service provider (CSP) option, Microsoft Enhanced Cryptographic Provider version 1.0. Click this provider in the list. In the Key length box, increase the number from the default of 1024 to 4096, and then click Next.

   

   You can now configure the identity of the CA and its expected service lifespan. Unlike a computer name or user name, this should be planned in advance and considered to be permanent. Configure the CA accordingly, and ensure that the e-mail address is not likely to change during the declared service life.

   You will notice the ability to declare a valid lifespan. The value that you declare affects the serviceability of the certificate server. This is because the root CA can only issue certificates that have a lifespan less than the root, which is true for the entire hierarchy, if implemented. Therefore, if your root CA is configured with a 10-year lifespan, and the sub-CAs are configured with a 5-year lifespan, your users can employ the certificate services for less than 5 years. If your PKI deployment takes two years to deploy fully, users have even less time to use the service.

   CAs can be renewed and the lifespan subsequently changed, but this requires administration. You may opt to keep administration to a minimum to decrease the opportunity of service interruption due to human intervention or accident.

   Before completing the next step, you must know how to present your PKI services. You might want a sub-CA to service temporary or guest accounts, and therefore keep the lifespan short. In a high-security model, you might do the same. For permanent employees who do not have access to sensitive data, you might configure a sub-CA with a longer lifespan. This decision can be made by your deployment team. It is important to have your aggregate security needs known, declared, and in writing before putting the service into live production.

6. Type the appropriate information in the text boxes provided, and then click Next.

   

7. Your service configuration and CA are created. The root certificate is self-signed by the root CA. Click Next when the process is finished.

   

   You can now configure the location of the certificate database and log file. Backup and restore of the CA is directed against the folder declared in the Shared folder box.

   The CA must be homed on an NTFS file system partition. Because the goal for uptime is 99.999 percent, a redundant array of independent disks (RAID) 5 array should be considered for production deployment. Disk capacity also needs to be considered. If the service is expected to issue numerous certificates, you will need to account for database size, optimization, and fault tolerance requirements. For small- to medium-sized organizations, a reasonable starting estimate is 20 gigabytes (GB). Drives of this capacity are currently reasonably priced when the role the server plays is considered.

8. On the Data Storage Location page, enter the appropriate information in the Certificate database and Certificate database log boxes, and then click Next.

   

9. Any Internet Information Services (IIS) services will be halted and restarted as the Windows Components Wizard proceeds. Click OK.

   

10. On the Configuring Components page, click Next to complete the installation process. Your IIS-related services will be updated and appended. You are now ready to issue certificates and use the services.

    

Configuring the Certification Authority

The CA can now issue certificates to your test lab users. Before proceeding, you need to declare the locations of the Certificate Revocation List (CRL) and authority information access. Strong PKI applications verify these locations first to check the status of certificate revocation and public key download. It is recommended that you install these to the subordinate CA computer, which will not be shut down because its uptime is considered a priority.

The procedure for configuring the CA is as follows:

1. Open the Microsoft Management Console (MMC) associated with the certification authority. The green check mark indicates that the service is running. Get properties on your root CA.

   

2. Click Policy Module/Configure/X.509 Extensions. Note that the default location pointers are removed. You have the option to cancel or remove the defaults; the end result is the same.

Because the root CA computer is essentially invisible to the network, the CRL and CRT files are manually copied to the Web server. The name of the Web server is used in this example. However, a DNS name is preferred for production because a change in the Web server computer name would break the PKI.

Note: If your root CA server is also your CRL distribution point, and you want to have the location of the CRL distribution point in the self-signed certificate for the root CA, you need to create the root CA by using a Capolicy.inf file. This is also necessary for setting a certification practice statement URL in the root CA certificate. Capolicy.inf is placed in the \winnt directory, and looks similar to the following string:

[Version] 
Signature= "$Windows NT$" 
[CAPolicy] 
Policies = LegalPolicy, LimitedUsePolicy, ExtraPolicy, OIDPolicy 
[LegalPolicy] 
OID = 1.3.6.1.4.1.311.21.43 
Notice = "Legal policy statement text." 
[LimitedUsePolicy] 
OID = 1.3.6.1.4.1.311.21.47 
URL = "https://http.site.com/some where/default.asp" 
URL = "ftp://ftp.site.com/some where else/default.asp" 
Notice = "Limited use policy statement text." 
URL = "ldap://ldap.site.com/some where else again/default.asp" 
[ExtraPolicy] 
OID = 1.3.6.1.4.1.311.21.53 
URL = https://extra.site.com/Extra Policy/default.asp 
[oidpolicy] 
OID = 1.3.6.1.4.1.311.21.55

You are now ready to publish the root certificate to Active Directory™. After this step is complete, you will have set the path to the top of your certificate hierarchy. As discussed previously, system uptime from this point forward is crucial because the trust will be broken if the root CA cannot be touched.

To publish, you can run Dsstore.exe from the Windows 2000 Server Resource Kit. The following command line is used in the HBT test lab. Note that the variable identifiers are in uppercase:

dsstore.exe DC=haybuv,DC=com –addroot ROOTCA.CRT "Hay Buv Toys ROOT CA"

During full deployment, replication must be complete before the certificate is available across the entire domain. The DSSTORE –pulse switch can accelerate this process.

Installing the Subordinate Certification Authority

As mentioned in previous papers, HBT intends to work with multiple subordinate certificate authorities under the root. One will service smart cards, and another user and computer accounts.

Root authorities differ from subordinate authorities in that subordinates store CRL and authority information access in Active Directory, which enables a Lightweight Directory Access Protocol (LDAP) query.

The process of installing a subordinate CA is similar to installing the root, and is identical for every subordinate to be created. Online authorities will use the offline root to sign the certificates they make available to the enterprise.

The procedure for installing subordinate CAs is as follows:

1. Using the sub-CA computer, sign in as an enterprise-level administrator. On the Start menu, point to Settings, and then click Control Panel. Double-click Add-Remove Programs, click to select the Windows Components sequence, and then click Add/Remove. Select the option to Install Certificate Services.

2. Click Enterprise subordinate CA, select Advanced options, and then click Next.

   

3. In the CSP list, click Microsoft Enhanced Cryptographic Provider v1.0, and then in the Key length box, increase the number to 2048. Click Next.

   

   Again, the identification should be planned in advance. The lifespan is determined by the root authority, and is one year by default. The certificates can be renewed, and a one-year default might be appropriate for a high security requirement. If this is not the case, the default lifespan can be modified by changing the following registry value on the root CA computer. After you have changed the registry value, cycle the certificate service.

4. Confirm the CA identifying information, and then click Next.

HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration<name
of the root CA>\ValidityPeriod

[![Dd277382.smar0816(en-us,TechNet.10).gif](images/Dd277382.smar0816(en-us,TechNet.10).gif "Dd277382.smar0816(en-us,TechNet.10).gif")](https://technet.microsoft.com/en-us/dd277382.smar0816_big\(en-us,technet.10\).gif)

5. On the Data Storage Location page, enter the appropriate location information in the Certificate database and Certificate database log boxes, and then click Next.

   You have the option to store configuration information in a shared folder, but if you exercise that option, the specific computer should also have a maximum uptime goal.

   

   You have two options to have the subordinate certificate signed by the root. You can send the request directly to the root, or you can create a file for the root to process. For this exercise, you can create a file for the root to process because the root CA is not available on the network.

6. Click Save the request to a file, and then click Next.

   

7. Follow the on-screen instructions to complete the installation process, and then click OK.

   The wizard will then inform you that the installation process is complete and that the service will be available when you process and install the certificate.

   

8. The Completing the Windows Components Wizard page appears. Click Finish to close the wizard.

   

Getting the Certification Request Signed by the Root Authority

To get the subordinate certificate request signed by the root, you can access the root computer directly by using the following procedure:

1. Start your browser. On the Tools menu, click Internet Options to open the Internet Options dialog box.

2. Click the Security tab, and then click Trusted Sites. Click Sites, and then clear the Require server verification check box. In the Add this Web site to the zone text box, type localhost, or the name of the Web server, in the following format:

   https://localhost/

3. Click Add, and then click OK. Set the appropriate security level to a custom level, or accept the default level. Click Apply, and then click OK to close the Internet Options dialog box.

4. Call the local host's certificate service from the browser, click Request a certificate from the Select a task list, and then click Next.

   

5. Click Advanced request, and then click Next.

   

6. Click Submit a certificate request using a base64 encoded PKCS #10 file or a renewal request using a base64 encoded PKCS #7 file, and then click Next.

   Note: During a full production deployment, if your root CA does not face your corporate network, you can ensure increased security by hand-delivering the certificate request to the root CA computer. Base 64 files are encoded, not encrypted. Although base 64 files provide a foundation for encryption, base 64 encoders and decoders are readily available.

   

7. When you receive the following message, click OK to continue.

   

   You have the option to paste the base 64 encoded text into the form field if you prefer. When you are ready, submit the request.

   

8. Open the Pending Requests folder for the root MMC, and notice the pending request.

   

9. Right-click the pending request, point to All Tasks, and then click Issue. You can issue or deny the pending request. In a live production environment, you can run the request against a registration authority to guarantee the authenticity of the request.

   

10. Return to the root's enrollment page to check the status of the request, click Check on a pending certificate, and then click Next.

    

11. Click to select the request that you want to review, and then click Next.

    

    The certificate is issued, and you can retrieve it from a downloadable certification path or copy it to a floppy disk. In a live production setting, the floppy disk can be hand-delivered to remote sites as needed.

    

Install and Activate the Subordinate CA

You are now ready to install and activate the subordinate CA., which you can do through the following procedure:

1. In the Certification Authority (Local) folder, click Hay Buv Toys USWEST SUB CA. Open the MMC, and notice the Stop dot informing you that the service is not running or is completed.

   

2. Right-click Hay Buy Toys USWEST SUB CA, point to All Tasks, and then click Install CA Certificate.

   

3. Click the Policy Settings folder, and then click Computer.

   

   You can now view the subordinate CA in the Policy Settings folder.

   

Installing Additional Subordinate CAs

From this point forward, you can add subordinate CAs under the subordinate of the root. The installation process is identical to installations covered in this paper thus far. The process is simplified because you can sign certificates from the online certification authority.

The procedure for installing additional Subordinate CAs is as follows:

1. Create a subordinate under the root's subordinate, by typing the appropriate information on the CA Identifying Information page.

   

2. Click Send the request directly to a CA already on the network to send the request directly to the root's sub-CA, and then click Next to finish the process.

   

Conclusion

This paper discusses how to set up a certificate hierarchy, and conveys the importance of keeping the online CA running at all times and serviced only by trusted operations personnel. Although file, print, and Web servers and services are often subject to change, the same should not be true for your certificate servers. If Certificate Services is interrupted, your ability to trust your certificate hierarchy is compromised. Your advanced preparation tasks will reduce this risk to a minimum.

Microsoft Enterprise Services

Roland Zeitler: MCS Germany

March 2001

For information about Enterprise Services, see https://www.microsoft.com/es/.

Companies, organizations, products, people, and events depicted in examples in this paper are fictitious. No association with any real company, organization, product, person, or event is intended or should be inferred.