Simply put, Public Key Infrastructure (PKI) is software, certificates, encryption algorithms, and other services that allow you to secure your communications on the Internet. Digital certificates issued by trusted certificate authorities are used to enable and protect vital services in today’s world of communication and commerce on the public Internet. PKI services with digital certificates help to verify the identity of users using services.
Windows 2000 also provided Certificate Services, but for Windows Server 2003 Microsoft has enhanced the services to provide additional security and to ease the related administrative burden. Windows Server 2003 includes some new features including the ability to separate administrative roles between different administrators, auto-enroll users in certain certificates, and more. This article will discuss common CA functions as well as the role separation features found in Windows 2003.
Installing Certificate Services
The Certificate Services are not installed as a server role like IIS and DNS. Rather, they are installed as optional Windows components. Service installation is accomplished by selecting Start | Control Panel | Add or Remove Programs | Add/Remove Windows Components. From the list of Windows components, select Certificate Services. As you can see in Figure A, you will be warned that changing the name of the machine or the domain membership will invalidate any certificates that this server is responsible for. As such, make sure that the server name and domain membership are finalized before installing the services. Click Yes followed by Next to continue with the installation.
|Certificate Services installation warning|
The next screen, shown in Figure B, asks for you to specify the type of Certificate Authority (CA) for this server. You have four choices.
- Enterprise Root CA: Requiring the use of Active Directory, an Enterprise root CA is the foundation for an enterprise-wide certificate hierarchy. An Enterprise Root CA signs its own certificate and does not typically provide services directly to end users.
- Enterprise Subordinate CA: Also requiring Active Directory, an Enterprise subordinate CA obtains its certificate from an already existing CA. These types of CAs are used to provide smart-card-enabled logons by Windows XP and other Windows Server 2003 machines.
- Stand-Alone Root CA: While a Stand-alone root CA does not require the use of Active Directory, it will use AD if it is present for the purposes of publishing certificates and certificate revocation lists. As a stand-alone service, this type of CA can be disconnected from the network and placed in a secure area.
- Stand-Alone Subordinate CA: This type of CA also does not require Active Directory and obtains its own certificate from a different CA.
|Select the type of CA to install.|
Enterprise CAs can be used to issue certificates to support such services as digital signatures, Secure Multipurpose Internet Mail Extensions (S/MIME) secure mail, Secure Sockets Layer (SSL) or Transport Layer Security (TLS) secured web access and smart card authentication. Enterprise CAsare used to provide certificate services to internal users who have user accounts in the domain.
Stand-alone CAs are used to provide similar services but are targeted at extranets and Internet users. Issuing stand-alone certificates requires that the requestor provide all identifying information. This is not required for Enterprise CAs since the Active Directory contains much of the pertinent user information for internal users.
Group Policy is used to propagate the root certificate to the Trusted Root Certification Authorities certificate store for the users and computers in the domain. A certificate store is a permanent storage area where certificate, certificate revocation lists, and certificate trust lists are stored.
For this example, install an Enterprise root CA. Click Next to continue.
Next, you need to supply some identifying information for the new CA, including its name and validity period. As you can see in Figure C, this CA is called "eca" (example CA) and has a validity period of six months. The validity period defines the range during which the certificate can be accepted as an authoritative credential verifying the identity of the user. Click Next to continue.
|Provide CA identifying information.|
Next, on the screen shown in Figure D, provide the locations for the certificate database and certificate database log. By default, these are located at C:\WINDOWS\system32. Click Next to continue.
|Provide a location for the certificate database.|
If you have IIS installed and running, you will be prompted with an indication that it must be temporarily stopped. This is done in order to install web enrollment services. Select Yes.
Finally, the Certificate Services component is installed. It takes a minute for the files to be copied and the service installed. During the installation, if you have IIS installed without ASP, you’ll get the notice shown in Figure E. This indicates that Active Server Pages (ASP) is required for web enrollment services but that ASP is a potential security risk. For this example, I’ve selected to enable ASP.
|Should ASP be enabled?|
Managing Certificate Services
Certificate Services in Windows Server 2003 is managed by the Certificate Authority administrative tool available at Start | Administrative Tools | Certificate Authority. When you start it, you'll see the MMC start, as shown in Figure F.
|The Certificate Authority administrative tool|
In Windows Server 2003, some functions require the distribution of certificates to each user that attempts to make use of specific services. A perfect example is the Encrypting File System (EFS). EFS is used to encrypt the contents of a file in order to protect the contents from unauthorized use.
You don’t have to manually provide users with certificates to use EFS. When a user that doesn’t already have a certificate attempts to encrypt a file for the first time, he is issued a certificate for this purpose. To see who has been issued certificates, click the Issued Certificates option. In Figure G below, you can see that the Administrator has been issued a certificate for EFS services. This certificate was issued as a result of a file encryption operation.
|A certificate was issued to support an EFS operation.|
To see the certificate details, double-click the desired selection in the right-hand side of the window. In Figure H, notice that this certificate was issued for the purpose of encrypting a file.
|The details of the aforementioned EFS certificate|
Notice the tab marked Certification Path. This tab lists the path back to the root certificate authority that was used to eventually provide this certificate. In Figure I, you can see that the EFS certificate was issued to Administrator from eca (the name of the root CA in this example).
Double-click the name of each CA up the line to view its certificate details. Figure I also shows the eca certificate and its purposes. In this case, the eca certificate— the self-signed root certificate— allows the eca certificate to be used for all issuances and application purposes.
Revoke a certificate
If you feel that the security of a certificate has been compromised or you need to disable the use of a certificate for some reason, you can easily revoke it using the Certificate Authority administrative tool. To do so, from the Issued Certificates tab, right-click the certificate you wish to revoke and select All Tasks | Revoke Certificate, as shown in Figure J.
|Revoke a certificate.|
When you elect to revoke a certificate, you are asked to provide a reason for the revocation on the screen shown in Figure K. You don’t have to do this, but it provides a good record for the future when you need to analyze the effectiveness of your PKI infrastructure and security policies. For this example, I’ll choose Key Compromise. Select your revocation reason and click Yes to revoke the certificate.
|Optionally provide a reason for the certificate revocation.|
After revocation, the certificate is listed in the Revoked Certificates section. Notice that the revocation reason is listed in this screen. You can unrevoke a certificate but only if the revocation reason was Certificate Hold. Attempting to unrevoke with any other revocation reason results in an error.
You can now use what is called role separation to separate administrators into predefined roles. This is a new feature in Windows Server 2003. When an administrator has permission to perform certain CA roles, they are the only activities that he can perform.
By default, role-based administration is not enabled in Windows Server 2003’s certificate services. To enable it, execute the following command from a command prompt:
certutil -setreg ca\RoleSeparationEnabled 1
After executing this command, stop and restart the Certificate Service service. There are five different CA roles that can be assigned:
- Auditor - The user or group assigned to this role is allowed to view and maintain the audit logs associated with the certificate services. You can get to it by clicking OS role (Local or Domain Security Policy | Security Settings | Local Policies | User Rights Assignment | Manage auditing and security log). See Figure L.
- Backup Operator - The user or group in the role can back up and restore the certificate store. You can get to it by clicking OS role (Local or Domain Security Policy | Security Settings | Local Policies | User Rights Assignment | Back up files and directories). See Figure M.
- CA Administrator - The user or group is allowed to maintain the CA including the ability to renew the CA certificate. You can get to it by clicking CA role (Security tab in CA properties) | Manage CA.
- Certificate Manager- The user or group can approve certificate enrollment and revocation requests. You can get to it by clicking (Security tab in CA properties) | Issue and Manage Certificates. See Figure N.
- Enrollees - These users and group can request certificates from the CA by virtue of OS/AD membership.
|Assign members to the CA Audit role.|
|Assign members to the Backup Operators role.|
|Assign members to CA roles.|
OS roles related to CA are handled in either the Local or the Domain Security Policy tool at Start | Administrative Tools | Domain (or Local) Security Policy | Security Settings | Local Policies | User Rights Assignment | Manage Auditing And Security Log or Back Up Files And Directories. Add users or groups by double-clicking the role and clicking the Add User Of Group button. Select the user or group to add to the role.
CA roles are handled on the Certificate Authority tool’s Security tab. You can add a user or group to the security list by clicking the Add button and selecting the user or group. To assign a role to a user, select the desired role from the Permissions for user or group box and click Apply.
PKI services are critical to today’s business needs. You need to know who you’re doing business with, and username/password just doesn’t cut it for truly sensitive information. PKI can help with this endeavor by helping to verify that the people with access to your information are who they say they are.