One of the most exciting features introduced in Windows 2000 was the ability to easily set up and maintain an internal Public Key Infrastructure (PKI) through the certificate services software built into Windows 2000 server products. Many companies seized on the opportunity to create their own structure for issuing and managing digital certificates instead of or as a supplement to using sometimes-expensive public certification authorities.
Now, with the release of Windows Server 2003, Microsoft has provided a number of enhancements and improvements to this popular feature. In this article, we will look at the new certificate services features included in the Standard, Enterprise and Datacenter editions of Server 2003 (Web Edition does not include certificate services, as it is designed to function as a web server only).
NOTE: As wireless networking has become the rage, concern has been growing over how to secure WLANs. Microsoft has published a useful guide to using Windows Server 2003 certificate services as the solution to the WLAN security problem. See http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/prodtech/windows/win2003/pkiwire/SWLAN.asp for more information.
Certificate Services and Role Based Administration
The new role-based administration feature included in Windows Server 2003 can be used to separate the roles of administrators responsible for managing and maintaining the Certification Authority (CA). This provides added security and allows you to use the Authorization Manager (discussed in my two-part article titled Authorization Manager and Role-Based Administration in Windows Server 2003 on this site).
In Windows 2000, all CA administrators could perform all tasks associated with managing the CA, but role-based administration provides for more granular control.
You can assign roles to CA administrators based on the specific tasks they perform, and associate particular security settings with each role. For example, you might give some administrators the ability to issue and manage certificates by assigning the permissions required for that task to one role, and allow other administrators to manage CA permissions by assigning permissions required for that task to a different role. Other administrators, in a third role, might be able to manage the auditing and security log. This separation of authority makes it more difficult for any one person to breach security. If you enable the role separation feature that is available on Enterprise and Datacenter editions (this is done by editing the registry), each user can only be assigned to one CA role. By default, users can be assigned to multiple roles.
Role-based administration works with both standalone and enterprise CAs. By default, on a standalone CA the local administrator account is assigned to the CA Administrator role. On an enterprise CA, domain admins and enterprise admins are also CA Administrators. The three CA roles designated by Microsoft are:
- CA Administrator: can configure and maintain the CA, renew CA certificates and assign all other CA roles. This role has the highest level of authority over the CA.
- Certificate Manager: can approve certificate enrollment and revocation requests, issue and manage certificates.
- Backup Operator: This is actually an operating system role, but is relevant to CA administration, as this role can back up and restore the CA.
- Auditor: This is another operating system role, and can configure, view and maintain the security log.
You can use the Certification Authority MMC snap-in to assign the CA Administrator and Certificate Manager roles.
Autoenrollment for Users
Windows 2000 certificate services supported autoenrollment for computer certificates and EFS certificates, but not for user certificates. Autoenrollment allows for certificates to be issued automatically for purposes specified by the administrator. In Windows Server 2003, this convenience has been extended to user certificates.
The administrator has more control than with manual enrollment, and the process is easier and more transparent for the user. Autoenrollment options are set on the certificate template for the type of certificate that will be issued via autoenrollment. No interaction – or even awareness of the process – is required on the part of the user (this is called “silent” autoenrollment). You can also set the certificate template to prompt the user during the enrollment process (for instance, to enter a PIN for smart card certificates).
The Autoenroll permission, along with Read and Enroll permissions, must be assigned to subjects before they can use this feature to autoenroll. Administrators add the users or groups they want to have these permissions in configuring the Security tab of the certificate template’s Properties sheet.
The Certificate Revocation List (CRL) is an important part of certificate services. It is a list of any certificates that have been revoked, which is published frequently by a CA so that all entities in the PKI that depend on the validity of the certificates issued by that CA will have up to date information as to certificates that are no longer valid. This list is replicated throughout the PKI.
In a large PKI, the CRL can be a fairly large file and publishing a new version of it on a frequent basis can use a lot of network bandwidth during the replication process and put a load on the clients that have to download it. Windows Server 2003 introduced the concept of “delta” CRLs. In mathematics, a delta refers to a change in a variable. A Delta CRL contains only the changes in revocation status that have been made since the last publication, instead of republishing the entire CRL (with those changes made) again. This especially improves processing time for applications that use a format other than the CRL structure to store the revocation information. Delta CRLs are implemented in Windows Server 2003 in compliance with the Internet standard specified in RFC 2459, Internet X.509 Public Key Infrastructure Certificate and CRL Profile (see http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2459.html#sec-5.2.4).
When the client downloads a Delta CRL, it is then combined with the most current “base” (full) CRL, which is generally cached locally on the client machine.
NOTE: The client application has to be aware of and able to use Delta CRLs; otherwise the client will continue to download the base CRL every time it goes for an update, even if you are publishing Delta CRLs. If you have clients that can’t use the Delta CRLs, you need to configure the CA to also publish a full CRL at the same time it publishes a Delta CRL. Delta CRLs are supported by all applications that use the CryptoAPI in Windows XP and Server 2003.
CA subordination allows you to create a hierarchy of CAs, with a root CA that issues certificates to subordinates, and the subordinates issuing certificates to users, computers and services (you can also have intermediate levels of subordination). Windows Server 2003 extends this ability with a new feature called qualified subordination, which allows you to define particular namespaces for which a subordinate CA can issue certificates, define particular acceptable uses for certificates issued by a subordinate CA, and create trust relationships between different CA hierarchies.
This gives you much more control over what each subordinate CA can and can’t do. By constraining the namespace, you are able to control which users and computers can get certificates from which CAs. Furthermore, you can use Active Directory distinguished names (DN), DNS domain names, email names, User Principal Names (UPN), or IP addresses to define the particular users and computers that can get certificates from a CA. You can either specify that certain names be included, or you specify that certain names be excluded. For example, you might want a particular subordinate CA to issue certificates only to users in a specific domain. You can configure both inclusion and exclusion lists, but if the same name is on both, the exclusion takes precedence.
Constraints other than those based on names are applied through application and issuance policies.
Both enterprise and standalone CAs can be qualified subordinate CAs. Enterprise qualified subordinates can identify users by Active Directory user attributes, whereas standalone qualified subordinates will use the information provided by the user on the certificate request web page to determine whether the certificate can be issued.
The new certificate services features discussed in this article include the most useful and exciting improvements in Windows Server 2003. Other enhancements include:
- The new -dspublish command for the certutil.exe utility, which allows you to publish a CA certificate or CRL to Active Directory from the command line.
- Key archival and recovery, which makes it easy to recover keys that are associated with issued certificates when they are lost.
- Event auditing for CA events (on Enterprise and Datacenter Edition CAs only).
- Ability to edit certificate templates.
Taken together, all these improvements to certificate services add up to yet another reason to upgrade to Windows Server 2003.