Securing for Certificate Authority Servers

---

Your CA server is vulnerable to attacks. You will need to harden it to prevent the risks to your authentication and encryption infrastructure if you choose to use a PKI solution. Hardening a CA server means looking at the additional services that are required. For example, you will have to install Internet Information Services (IIS) on your issuing CA servers. IIS is used to issue certificates to non-Windows clients, issue certificate revocation lists, and distribute certificate authority certificates. This means that you will need to harden IIS on these computers along with hardening the CA server.

Note

You will learn about hardening IIS in Chapter 7, “Designing Security for Internet Information Services.”

Design Scenario: Designing a Renewing and Revocation Strategy

Trinity Importers, Ltd. needs to decide how long the certificate should last and what the renewal process should be. The CSO states that the information in the POS is important but not sensitive.

1. Question: What should you suggest for a renewal strategy? Answer: You should recommend using a stronger key and renewing less frequently because the data is not sensiti ve. You would probably renew it two or three times before the key expires. The use of the stronger key should be enough to protect it. You should renew the key when the key expires.

Hardening your server will require the use of many of the security features included in Windows Server 2003. You will need to properly configure file system permissions on your CA, and you will need to pay attention to the administrative roles for the CAs. You will also need to secure well-known accounts on the CA servers, run only the services required on the server, and provide physical security for the server, and as we discussed earlier, you will need to audit the server.

You will want to pay attention to securing the root CA in your CA hierarchy. If the root CA is compromised, then all certificates issued by the root CA are compromised and will need to be revoked and renewed. Because the root CA is responsible for all certificates issued in your organization, this would mean a great deal of work. It is recommended that you install the root CA as a stand-alone CA that you keep physically secure and offline. You will need to bring it online only when you need to add a new CA server. This will minimize the chances for the root CA to be attacked.

Administrative access to a Windows Server 2003 CA server can be controlled through four roles:

• CA Administrator

• Certificate Manager

• Backup Operator

• Auditor

One person can assume all of these roles, but to minimize your exposure if one of these accounts is compromised, you should have different accounts associated with each role. The first two roles can be set using the Security tab of the CA server Properties dialog box, as shown in Figure 6.16. The third and fourth roles are granted through user rights that are set with the Group Policy MMC and are used to grant backup capabilities and rights to read and manage the audit logs.

Figure 6.16: The Security tab of a CA server Properties dialog box

The CA Administrator role is associated with the Manage CA permission on the CA server. This role will allow the account to configure the CA server, manage permissions, and renew CA certificates. The Certificate Manager role is associated with the Issue And Manage Certificates permission. This role will allow the account to initiate a key recovery, manage certificate enrollment, and revoke certificates.

You can also secure a CA server by limiting access to it. The Certificate Managers Restrictions tab of the CA Server Properties dialog box allows you to allow or deny groups and accounts that can manage certificates on the server, as shown in Figure 6.17. This is particularly useful to creating a CA hierarchy based on the organization.

Figure 6.17: The Certificate Managers Restrictions tab

Files on the file system are protected by using access control lists (ACLs) to prevent unauthorized access to the important files on your CA server. Encryption is a stronger form of protection for files that need to be used by only a single user. The NTFS file system provides for ACLs and encryption on a Windows Server 2003 server. The following table lists two paths that will need special attention when securing a CA server and the permissions required:

File path	Permissions
Systemroot\system32\CertLog	Administrators (Full Control), SYSTEM (Full Control)
Systemroot\system32\CertSrv	Administrators (Full Control), SYSTEM (Full Control), Users (Read, Execute, List Folder Contents)

You will need to secure well-known accounts like Administrator and Guest, which cannot be deleted. You should rename these accounts to prevent unauthorized attempts to use them to log on. You would also leave the Guest account disabled. You should not allow anyone to log on as the built-in administrator account. You will then audit the logon access with the unique name given to this account. Many scripts use the Security ID (SID) of the built-in administrator account to attempt attacks on the server. You will also want to use a different password and name for the built-in administrator account on each server to prevent access to more than one server on your network to contain the damage of a broken password.

Note

You should never configure the accounts used by the services to run under a domain security context, unless you must for reasons of authenticating with other services in the domain or if it is required by the service you are using. If an attacker is able to gain physical access to the server, the domain account can be compromised by a SAM password-breaking utility like L0phtcrack.

You should limit the services that are running on the server because it will limit the attack footprint of the server. You should install only the services necessary for the CA server by installing just the certificate services to the server and installing IIS only on the servers that support enrolling and distributing certificates.

You should provide physical security for the CA servers. Preferably, this security would be in a secure location that requires a key card to provide entry. You would also want to restrict access to the CD-RW drive and the floppy drive to those that are logged on locally so nobody can access the drives over the network. This is because sensitive information can be copied to a floppy or CD-RW (such as when backing up a private key used by the server), and if the box was infiltrated, the attacker might be able to read the information on the disk.

You will also want to change the default location for the CA installation. This will mean that the attacker cannot simply enter a well-known default path to the CA database or executables on your system. They would have to determine where the files are located, which would make the attack more difficult.

You should start by applying an appropriate security template through the Microsoft Server Baseline Policy (MSBP). Microsoft provides Legacy Client, Enterprise Client, and High Security Client templates. MSBP uses .inf file security templates to apply baseline security settings to the Windows Server 2003 roles. This is very useful tool to set up the auditing policy, event logging policy, group policies, and installed services.

You will learn more about this tool in Chapter 8, “Designing Security for Servers With Specific Roles.”

In the “Designing Security for a CA” Design Scenario, you will design security for a CA server.

Design Scenario: Designing Security for a CA

Trinity Importers is worried about security for its root CA server. The company doesn’t want to incur the cost of renewing all the certificates in the organization if the root CA server is compromised.

1. Question: What should be done to protect the root CA server? Answer: Trinity should install the root CA on a stand-alone CA server and lock it in a physically secure location, disconnected from the network. The server can be brought online whenever there is a need to sign a certificate with the root certificate or when it is time to renew the root CA certificate.

---