Chapter 11: The Certificate Services Server Role

Published: December 31, 2003   |   Updated: April 26, 2006

Overview

This chapter provides guidance that will help you harden servers that run Microsoft® Windows Server™ 2003 with Service Pack 1 (SP1) and Microsoft Certificate Services in your environment. Although this chapter includes all of the information you need to secure these types of servers, it does not provide any details about how to create a secure Certificate Services infrastructure in your environment or how to deploy a certification authority (CA). These topics are discussed in detail in the Windows Server 2003 product documentation. They are also discussed in the Windows Server 2003 Resource Kit and in white papers that are available on the Microsoft Web site. Additional information can be found in a companion guide: Securing Wireless LANs with Certificate Services, which is available at https://go.microsoft.com/fwlink/?LinkId=14843.

The settings in this chapter are configured and applied through Group Policy. A Group Policy object (GPO) that complements the Member Server Baseline Policy (MSBP) can be linked to the appropriate organizational units (OUs) that contain the CA servers to provide the required security setting changes for this server role. This chapter only discusses those policy settings that vary from the MSBP.

Where possible, these settings are gathered in an incremental Group Policy template that will be applied to the CA Servers OU. Some of the settings in this chapter cannot be applied through Group Policy. Detailed information about how to configure these settings manually is provided.

The name of the CA Server security template for the EC environment is EC-CA Server.inf. This is the incremental CA Server template, which is used to create a new GPO that is linked to the CA Servers OU in the appropriate environment. Step-by-step instructions are provided in Chapter 2, "Windows Server 2003 Hardening Mechanisms"  to help you create the OUs and Group Policies and then import the appropriate security template into each GPO.

For information about settings in the MSBP, see Chapter 4, “The Member Server Baseline Policy.” For information on all default settings, see the companion guide, Threats and Countermeasures: Security Settings in Windows Server 2003 and Windows XP, which is available at https://go.microsoft.com/fwlink/?LinkId=15159.

Note: The policy setting recommendations for the Certificate Services server role were tested for the Enterprise Client environment only. For this reason, the denial of service (DoS) information that was specified for most of the other server roles in this guide is not included in this chapter.

You might install Microsoft Internet Information Services (IIS) on some of the Certificate Services servers in your environment so that these servers can distribute CA certificates and certificate revocation lists (CRLs). IIS is also used to host the Certificate Services server Web enrollment pages, which allow non-Microsoft Windows® clients to enroll certificates. Before you act on the information in this chapter, make sure you understand how to securely install IIS, which is described in Chapter 9, "The Web Server Role" in this guide. If you install IIS on your CAs, the security configuration template that was developed for Chapter 9 must be applied to your Certificate Services servers before you configure the prescribed settings that are described in this chapter.

Note: In simplified environments, the issuing CA server can be used to host the Web server, the CA certificate, and the CRL download points. However, you should consider using a separate Web server in your own environment to improve the security of your CAs.

IIS is used to host the certificate server enrollment pages and to distribute CA certificates and CRL download points for non-Windows clients. Microsoft recommends that you not install IIS on the root CA server. If possible, you should not run IIS on your issuing CA and any intermediate CAs in your environment. It is more secure to host the Web download points for CA certificates and CRLs on a different server than the CA server itself. Many certificate users (internal and external) who need to retrieve CRLs or CA chain information should not necessarily be permitted access to the CA. However, you cannot isolate users from the CA if you host the download points on it.

Audit Policy Settings

Audit policy settings for Certificate Services servers in the Enterprise Client environment guide are configured through the MSBP. For more information about the MSBP, see Chapter 4, "The Member Server Baseline Policy." The MSBP settings ensure that all the relevant security audit information is logged on all Certificate Services servers.

User Rights Assignments

User rights assignment settings for Certificate Services servers in the Enterprise Client environment are also configured through the MSBP. For more information about the MSBP, see Chapter 4, "The Member Server Baseline Policy." The MSBP settings ensure that appropriate access to Certificate Services servers is uniformly configured across an enterprise.

Security Options

The Security Options section of Group Policy is used to enable or disable security settings for computers, such as digital signing of data, Administrator and Guest account names, floppy disk drive and CD-ROM drive access, driver installation behavior, and logon prompts.

You can configure the security options settings in Windows Server 2003 at the following location within the Group Policy Object Editor:

Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

The following table includes the recommended security options setting for the Certificate Services server role in the Enterprise Client environment. Detailed information about the setting is provided in the text that follows the table.

Table 11.1 Recommended Security Options Settings

System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing

This policy setting determines whether the Transport Layer Security/Secure Sockets Layer (TLS/SSL) Security Provider supports only the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher suite. In effect, support for this cipher suite means that the provider only supports the TLS protocol as a client and a server (if applicable).

The TLS/SSL Security Provider uses the following algorithms:

• The Triple Data Encryption Standard (3DES) encryption algorithm for the TLS traffic encryption.
• The Rivest, Shamir, and Adelman (RSA) public key algorithm for the TLS key exchange and authentication. (RSA is a public-key encryption technology that was developed by RSA Data Security, Inc.)
• The SHA-1 hashing algorithm for the TLS hashing requirements.

For the Encrypting File System Service (EFS), the TLS/SSL Security Provider supports only the Triple DES encryption algorithm to encrypt file data that is stored in the Windows NTFS file system. By default, in Windows 2000 and Windows XP with no service packs, EFS uses the DESX algorithm to encrypt file data, however in Windows XP SP1 and later, and Windows Server 2003, the default algorithm is Advanced Encryption Standard (AES) using a 256-bit key.

If you enable this policy setting, computers that fulfill this server role in your environment will use the most powerful algorithms that are available for digital encryption, hashing, and signing. Use of these algorithms minimizes risk because they limit the ability of an unauthorized user to compromise digitally encrypted or signed data.

For these reasons, the System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing setting is configured to Enabled for the Enterprise Client environment.

Note: Client computers that have this policy setting enabled will be unable to communicate through digitally encrypted or signed protocols with servers that do not support these algorithms. Network client computers that do not support these algorithms will not be able to use servers that require the algorithms for network communications. For example, many Apache–based Web servers are not configured to support TLS. If you enable this setting you must also configure Internet Explorer to use TLS. To do so, open the Internet Options dialog box from the Internet Explorer Tools menu, click the Advanced tab on the Internet Options dialog box, scroll towards the bottom of the Settings list, and then click the Use TLS 1.0 checkbox. It is also possible to configure this functionality through Group Policy or with the Internet Explorer Administrators Kit.

Event Log Settings

The event log settings for Certificate Services servers in the Enterprise Client environment are configured through the MSBP. For more information on the MSBP, see Chapter 4, "The Member Server Baseline Policy."

Additional Registry Entries

Additional registry entries were created for the EC-CA Server.inf template file. These entries are not defined within the Administrative Template (.adm) files for the Enterprise Client environment as defined in this guide. The .adm files define the system policies and restrictions for the desktop, shell, and security settings for Windows Server 2003 with SP1.

The additional registry entries are configured within the security template to automate their implementation. If the Incremental Certificate Services Group Policy for this environment is removed, its settings are not automatically removed and must be manually changed with a registry editing tool such as Regedt32.exe.

You can configure the registry entries in Windows Server 2003 at the following location within the Group Policy Object Editor:

MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration

Additional Security Settings

The following ACLs are suggested and can be assigned through Group Policy. However, these ACLs are not included in the security templates that are provided with this guide because the path for the database and logs will differ from server to server. For example, your Certificate Servers server could have a C:\, D:\, and E:\ drive. Details about how to manually implement these policy settings are provided in the following section.

File System ACLs

Files that are not protected by access control lists (ACLs) can be easily viewed, changed, or deleted by unauthorized users who can access them locally or over the network. Although ACLs can help protect files, encryption provides much more protection and is a viable option for files that only need to be accessible to a single user.

The following table includes the file system ACLs for Windows Server 2003–based Certificate Services servers in the Enterprise Client environment. In this environment, the Certificate Services servers use D:\CertSrv as the certificate database directory and the database logs are stored in the default folder %SystemRoot%\system32\CertLog. It is also possible to move the logs from the system drive to a physically separate mirrored drive, such as E:\CertLog. Security considerations do not require separation of the database and logs onto different physical disk drives, but this configuration is recommended for added protection from disk failures and to improve performance. The Certificate Services default installation folders %SystemRoot%\system32\CertLog and %SystemRoot%\system32\CertSrv have the correct ACLs by default, which are shown in the following table.

Table 11.2 File System ACLs

Because of the security-sensitive nature of CAs, file auditing is enabled on the Certificate Services folders that are listed in the preceding table. The audit entries are configured as shown in the following table:

Table 11.3 Certificate Services File and Registry Audit Configuration

These policy settings will audit any type of failure access (read or modify) from any user and also audit any successful modification by any user.

Securing Well-Known Accounts

Windows Server 2003 with SP1 has a number of built-in user accounts that cannot be deleted, but can be renamed. Two of the most well known built-in accounts in Windows Server 2003 are Guest and Administrator.

By default, the Guest account is disabled on member servers and domain controllers. This configuration should not be changed. Many variations of malicious code use the built-in Administrator account in an initial attempt to compromise a server. Therefore, the built-in Administrator account should be renamed and the description altered to help prevent compromise of remote servers by attackers who try to use this well-known account.

The value of this configuration change has diminished over the past few years since the release of attack tools that specify the security identifier (SID) of the built-in Administrator account to determine its true name and then break into the server. A SID is the value that uniquely identifies each user, group, computer account, and logon session on a network. It is not possible to change the SID of this built-in account. However, your operations groups can easily monitor attempted attacks against this Administrator account if you rename it with a unique name.

To secure well-known accounts on CA servers

• Rename the Administrator and Guest accounts, and change their passwords to long and complex values on every domain and server.
• Use different names and passwords on each server. If the same account names and passwords are used on all domains and servers, an attacker who gains access to one member server will be able to gain access to all others.
• Change the account descriptions to something other than the defaults to help prevent easy identification of the accounts.
• Record these changes in a secure location.

Note: You can rename the built-in Administrator account through Group Policy. This policy setting was not implemented in any of the security templates that are provided with this guide because every organization should choose a unique name for this account. However, you can configure the Accounts: Rename administrator account setting to rename the Administrator account in the EC environment. This policy setting is a part of the Security Options settings of a GPO.

Securing Service Accounts

Never configure a service to run under the security context of a domain account unless it is unavoidable. If the server is physically compromised, domain account passwords could be easily obtained by dumping LSA secrets. For more information about how to secure service accounts, see The Services and Service Accounts Security Planning Guide at https://go.microsoft.com/fwlink/?LinkId=41311.

Creating the Policy Using SCW

To deploy the necessary security settings, you must use both the Security Configuration Wizard (SCW) and the security templates that are included with the downloadable version of this guide to create a server policy.

When you create your own policy, be sure to skip the "Registry Settings" and “Audit Policy” sections. These settings are provided by the security templates for your chosen environment. This approach is necessary to ensure that the policy elements that are provided by the templates take precedence over those that would be configured by SCW.

You should use a new installation of the operating system to begin your configuration work, which helps ensure that there are no legacy settings or software from previous configurations. If possible, you should use hardware that is similar to the hardware that is used in your deployment to help ensure as much compatibility as possible. The new installation is called a reference computer.

During the server policy creation steps you will probably remove the File server role from the list of detected roles. This role is commonly configured on servers that do not require it and could be considered a security risk. To enable the File server role for servers that require it, you can apply a second policy later in this process.

To create the Certificate Services server policy

1. Create a new installation of Windows Server 2003 with SP1 on a new reference computer.
2. Install the Security Configuration Wizard component on the computer through Control Panel, Add/Remove Programs, Add/Remove Windows Components.
3. Join the computer to the domain, which will apply all security settings from parent OUs.
4. Install and configure only the mandatory applications that will be on every server that shares this role. Examples include role-specific services, software and management agents, tape backup agents, and antivirus or antispyware utilities.
5. Launch the SCW GUI, select Create new policy, and point it to the reference computer.
6. Ensure that the detected server roles are appropriate for your environment—for example the Certificate Services role.
7. Ensure that the detected client features are appropriate for your environment.
8. Ensure that the detected administrative options are appropriate for your environment.
9. Ensure that any additional services that are required by your baseline, such as backup agents or antivirus software, are detected.
10. Decide how to handle unspecified services in your environment. For extra security, you may wish to configure this policy setting to Disable. You should test this configuration before you deploy it to your production network because it may cause problems if your production servers run additional services that are not duplicated on your reference computer.
11. Ensure the Skip this section checkbox is unchecked in the "Network Security" section, and then click Next. The appropriate ports and applications identified earlier are configured as exceptions for Windows Firewall.
12. In the "Registry Settings" section, click the Skip this section checkbox and then click Next. These policy settings are imported from the supplied INF file.
13. In the "Audit Policy" section, click the Skip this section checkbox and then click Next. These policy settings are imported from the supplied INF file.
14. Include the appropriate security template (for example, EC-CA Server.inf).
15. Save the policy with an appropriate name (for example, Certificate Services.xml).

Test the Policy Using SCW

After you create and save the policy, Microsoft strongly recommends that you deploy it to your test environment. Ideally, your test servers will have the same hardware and software configuration as your production servers. This approach will allow you to find and fix potential problems, such as the presence of unexpected services that are required by specific hardware devices.

Two options are available to test the policy. You can use the native SCW deployment facilities, or deploy the policies through a GPO.

When you start to author your policies, you should consider using the native SCW deployment facilities. You can use SCW to push a policy to a single server at a time, or use Scwcmd to push the policy to a group of servers. The native deployment method allows you to easily roll back deployed policies from within SCW. This capability can be very useful when you make multiple changes to your policies during the test process.

The policy is tested to ensure that the application of this policy to the target servers will not adversely affect their critical functions. After you apply the configuration changes, you should begin to verify the core functionality of the computer. For example, if the server is configured as a certification authority (CA), ensure that clients can request and obtain certificates, download a certificate revocation list, and so on.

When you are confident in your policy configurations, you can use Scwcmd as shown in the following procedure to convert the policies to GPOs.

For more details about how to test SCW policies, see the Deployment Guide for the Security Configuration Wizard at https://technet2.microsoft.com/WindowsServer/en/Library/5254f8cd-143e-4559-a299-9c723b3669461033.mspx and the Security Configuration Wizard Documentation at https://go.microsoft.com/fwlink/?linkid=43450.

Convert and Deploy the Policy

After you thoroughly test the policy, complete the following steps to convert it into a GPO and deploy it:

1. At the command prompt, type the following command:

   scwcmd transform /p:<PathToPolicy.xml> /g:<GPODisplayName>
   

   and then press ENTER. For example:Note: The line has been split into multiple lines for readability. However, while trying it out on a system you must enter it as one line without breaks.

   scwcmd transform /p:"C:\Windows\Security\msscw\Policies\
   Certificate Services.xml" /g:"Certificate Services Policy"
   

   Note: The information to be entered at the command prompt shows on more than one line here because of display limitations. This information should all be entered on one line.

2. Use the Group Policy Management Console to link the newly created GPO to the appropriate OU.

Note that if the SCW security policy file contains Windows Firewall settings, Windows Firewall must be active on the local computer for this procedure to complete successfully. To verify that Windows Firewall is active, open Control Panel and then double-click Windows Firewall.

You should now perform a final test to ensure that the GPO applies the desired settings. To complete this procedure, confirm that the appropriate settings were made and that functionality is not affected.

Summary

This chapter explained the policy settings that can be used to harden Certificate Services servers that run Windows Server 2003 with SP1 in the Enterprise Client environment as defined in this guide. The settings are configured and applied through a Group Policy object (GPO) that complements the MSBP. GPOs can be linked to the appropriate organizational units (OUs) that contain the Certificate Services servers to provide additional security.

More Information

The following links provide additional information about topics that relate to hardening servers that run Windows Server 2003 with SP1 and Certificate Services.

• For a good introduction to public key infrastructure (PKI) concepts and the features of Windows 2000 certificate services, see "An Introduction to the Windows 2000 Public Key Infrastructure" at www.microsoft.com/technet/archive/windows2000serv/evaluate/featfunc/pkiintro.mspx.
• For more detailed information about PKI functionality in Windows Server 2003 and Windows XP, see "PKI Enhancements in Windows XP Professional and Windows Server 2003" at www.microsoft.com/technet/prodtechnol/winxppro/plan/pkienh.mspx.
• For more background information about key PKI concepts, see the Public Key Infrastructure page at https://technet2.microsoft.com/WindowsServer/en/Library/32aacfe8-83af-4676-a45c-75483545a9781033.mspx.