Implementing a Public Key Infrastructure (PKI), Windows Server 2003, Part I
E-commerce, e-healthcare, e-banking, and other types of organizations usually require a high level of security for their data and infrastructure. Such security can be tricky to implement, at best. Public Key Infrastructure (PKI) can be a good place to start; read on to learn how to implement a PKI using Microsoft Windows Server 2003.
Contributed by Eliana Stavrou Rating: / 20 November 10, 2004
Securing the infrastructure and data of an organization is not a simple task. There are many factors that must be considered before implementing security, such as the level of security we want to achieve. Based on the nature of the organization (i.e. e-commerce, e-healthcare, portal, mobile services), we need to apply appropriate security technologies to reach the required security level. If the organization needs a high level of security that calls for encryption, non-repudiation, authentication of users, and integrity of data, a Public Key Infrastructure (PKI) is a good starting point for addressing the problem.
In this article, I will discuss how to implement a Public Key Infrastructure using Microsoft Windows Server 2003 (also referred to as Microsoft Certificate Services). I will assume that you are familiar with terms such as public key cryptography, certificate authorities, digital certificates, digital signatures etc.
Overview of Microsoft Windows Server 2003 PKI
Windows Server 2003 Standard and Enterprise Editions include a PKI feature that can be used to benefit from public key cryptography. In addition, if you already have Windows Server 2003 (or 2000) you may save money as you can operate your own PKI and issue digital certificates to users, computers or services, instead of buying them from Certificate Authorities (CA) like VeriSign.
The Windows Server 2003 PKI supports a wide range of applications, including:
Secure email
Digital signatures that enable non-reputable transactions
Before moving into technical details, we need to decide the type of CA we want to implement. For further information on choosing a PKI architecture, you can read my previously published article “PKI Architectures—Which one best suits you” (http://www.devshed.com/c/a/Security/PKI-Architectures-How-to-Choose-One/).
Microsoft Certificate Services offer two types of CAs: enterprise CAs and stand-alone CAs. Each CA can be implemented as an online or offline CA. This decision is based on the sensitivity of the requirements; the stronger the security level needed, the less accessible the CA should be. The best practice is to place the stand-alone root CA offline because it is a single point of trust (if the root CA is compromised, it results in the compromisation of the entire PKI). Intermediate CAs are typically configured as offline as well. Online CAs are typically issuing CAs as they respond to certificate requests. Every Enterprise CA must be an online CA, since it requires connectivity to Active Directory at all times to obtain configuration information, validate requests, and publish certificates. However, you have to take into consideration that an online CA is subjected to a greater risk due to the network connectivity and continuous availability.
The following table lists a set of comparison criteria between the stand-alone CA and the Enterprise CA in order to help you decide what CA type is best for your organization.
Comparison Criteria
Stand-alone CA
Enterprise CA
Active Directory support
It issues certificates to users outside of an Active Directory environment. However, CA configuration can be published into Active Directory.
It must be a member of a Windows 2000 or Windows Server 2003 Active directory domain.
Identification of user when requesting a certificate
Identification information is captured through the Web enrollment interface.
User identification information is always automatically retrieved from Active Directory.
Enrollment
Web Enrollment -- You cannot apply the enrollment method (automatic or pending) on individual templates.
Web Enrollment or Certificates MMC (Microsoft Management Console) -- You can individually set the enrollment method (automatic or pending) on each template.
Issuing
Certificates are manually approved. -- Issue certificates based on predefined certificate template.
Certificates are manually approved or they are approved through Active Directory authentication. -- Can issue certificates based on customized certificate templates.
Installation
Can be installed on a domain controller, member server, or stand-alone server (workgroup member).
Can be installed on a domain controller or a member server (the CA is registered as a forest resource). It must not be installed on a stand-alone server (workgroup member).
In this section I will describe the steps that you should follow to install a root CA by using a computer running Windows Server 2003, Standard Edition. The procedure is similar for implementing the root CA on a computer running Windows Server 2003, Enterprise Edition.
A good practice before installing Microsoft Certificate Services is to write the Certificate Policy (CP) and the Certificate Practice Statement (CPS) that govern the operation of the PKI. The first policy provides rules for issues such as the cryptographic algorithms that will be used, the minimum allowable length of encryption keys, and so forth; the second policy details how the Certification Authority will implement the Certificate Policy (CP) into its procedures. Please note that providing information on how to write these policies is out of the scope of this article.
Also, be prepared to use Windows Server 2003 CD.
1. Log on as Administrator. Click Start, point to Control Panel and click Add/Remove Programs.
2. In the Add/Remove Programs window, click the Add/Remove Windows Components button.
3. In the Windows Components dialog box, select the Certificate Services component and then click the Details button.
4. In the Certificate Services dialog box, select the Certificate Services CA component. A dialog box appears and informs you that you can not change the machine name or the domain membership of the machine while it acts as a certificate server (so, you need to verify correctness of machine name or change accordingly). Read the information in the dialog box and click Yes.
5. Select Certificate Services Web Enrollment Support in the same dialog box and click OK in the Certificate Services dialog box.
6. Click Next in the Windows Components dialog box.
7. In CA Type window, click Stand-alone root CA, select the Use custom settings to generate the key pair and CA certificate check box, and then click Next.
It is expected that the enterprise root CA and enterprise subordinate CA options are not available because the computer is not a member of an Active Directory domain.
You cannot change the CA type at a later time; you must uninstall the original CA and then reinstall the CA to change it from either a stand-alone CA to an enterprise CA or an enterprise CA to a stand-alone CA.
8. Do the following:
In CSP (Cryptographic Service Provider), click Microsoft Strong Cryptographic Provider.
In Hash algorithm, click the default hash algorithm, SHA-1.
In Key length, click 4096. This value is recommended by Microsoft. According to the type of CA you choose there are other recommendations for the key length. Please note that there is no verification of the key length that you type into the box. So be careful of the value you define.
9. Confirm that both the selections Allow this CSP to interact with the desktop and Use an existing key are cleared, and then click Next.
Type in a Common Name for this CA. Keep in mind that the common name cannot exceed 64 characters in length. However, it is recommended that you use a maximum length of 51 characters to prevent an encoding length rule violation.
The customized field distinguished name suffix is optional. You can also set the distinguished name suffix at a later time.
This information is filled in automatically if the CA is joined to an Active Directory–based domain.
In Validity period, select 10 years. Click Next.
11. If you have previously uninstalled a CA on the computer you are configuring, you will receive a warning message telling you that you will overwrite the private key from the previous CA installation. For obvious reasons, you should ensure that the private key is never required again. If you continue, a new key is generated and the new key replaces the existing key.
12. In Certificate Database Settings do the following:
In Certificate database and Certificate database log, enter the locations to store the related configuration information. You can specify the local path C:\WINDOWS\System32\CertLog.
Select the option Store configuration information in a shared folder and specify a pathname as the name for the shared folder. The path can be either a universal naming convention (UNC) path such as the default, \\Localhost\CAConfig, or a local path, such as C:\CAConfig. If the computer does not have network cards installed, or has all network interfaces disabled, you must choose a local path. Click Next.
13. The Microsoft Certificate Services dialog box informs you that Internet Information Services must be temporarily stopped. Click Yes.
14. Microsoft Windows Server 2003 installation CD is required.
15. The Microsoft Certificate Services dialog box informs you that Active Server Pages must be enabled on IIS if you wish to use the Certificate Services Web enrollment site. Click Yes.
16. Click Finish on the Completing the Windows Components Wizard window.
17. Close the Add or Remove Programs window.
The Stand-alone Root Certificate Authority is now installed and can issue certificates. The following picture presents the Web Interface of Microsoft Certificate Services after implementing the stand-alone Certificate Authority that you can use to request certificates.
For further information about managing or troubleshooting the PKI you just created, you can visit Microsoft’s site and read related articles.
Conclusions
In today’s era of insecurities, it is critical for every organization to apply appropriate technology and try minimizing security problems. A must-have technology for today’s conditions is Public key Infrastructure (PKI), a favoured option among network implementers.
Installing and maintaining a PKI is not a simple task to do. My aim when writing this article was to give you a start point on PKI so you could be able to benefit as much as possible of what PKI has to offer you. Good luck in your efforts!
Reference
Best Practices for Implementing a Windows Server 2003 Public Key Infrastructure: