Certificate revocation is a necessary part of the process of managing the certificates issued by your CAs. The most common means of communicating certificate revocation status is by distributing certificate revocation lists (CRLs). However, in public key infrastructures (PKIs) where the use of conventional CRLs is not an optimal solution, the Online Responder role service can manage and distribute revocation status information by using the Online Certificate Status Protocol (OCSP).
The primary disadvantage of conventional CRLs is their potentially large size, which limits the scalability of the CRL approach. The large size adds significant bandwidth and storage burdens to the CA and relying party, and therefore limits the ability of the system to distribute the CRL. Bandwidth, storage space, and CA processing capacity can also be negatively affected if the publishing frequency gets too high.
Numerous attempts have been made to solve the CRL size issue through the introduction of partitioned CRLs, delta CRLs, and indirect CRLs. All these approaches have added complexity and cost to the system without providing an ideal solution to the underlying problem.
Another drawback of conventional CRLs is latency. Because the CRL publishing period is predefined, information in the CRL might be out of date until a new CRL or delta CRL is published.
Note Microsoft natively supports only CRL and delta CRL in operating systems prior to the Windows Vista operating system. Windows Vista and the Windows Server 2008 will natively support CRL, delta CRL, and OCSP as a method of determining certificate status. The OCSP support includes both the client component as well as the Online Responder, which is the server component.
The Online Responder role service decodes revocation status requests for specific certificates, evaluates the status of these certificates, and then sends back a signed response containing the requested certificate revocation status information.
To install the Online Responder role service, membership in local Administrators, or equivalent, is the minimum requirement to complete this procedure. To configure a CA to support the Online Responder role service, membership in Domain Admins or Enterprise Admins, or equivalent, is the minimum requirement to complete this procedure. For more information about these aspects of administering a PKI, see "Implement Role-Based Administration" in the Help and Support for Windows Server 2008.
For more information about the Online Responder role service, see AD CS: Online Certificate Status Protocol Support.
Attack Surface
The Online Responder role service is susceptible to many of the same security attacks as any server computer that publishes CRLs. To identify the attack surface for this role service, you need to identify the:
Installed files. The files that are installed as a part of the Online Responder role service.
Running services. The services that run as a part of the Online Responder role service.
Note You can use the RootkitRevealer and Sigcheck utilities that are part of Windows Sysinternals to verify the integrity of the installed files and the files that the services run.
Firewall rules. The Windows Firewall rules that the Online Responder role service uses.
Role dependencies. The dependencies for the Online Responder role service.
Security Measures
This section describes the security measures that you can incorporate into your Online Responder role service configuration to protect the server against malicious attacks. The recommendations that follow assume that you have only selected the Online Responder role service option on the Select Role Services page of the Add Roles Wizard. Recommendations for other role services are not included.
The following table summarizes the recommended security configuration tasks for hardening servers performing the Online Responder role service. If you need help to complete any of the checklist items, see the following sections in this chapter for additional details and recommendations.
Table 9.3 Configuration Checklist
|
Configuration tasks
|
|
Enable Windows Authentication for intranet-based requests.
|
|
Protect certificate revocation status requests and responses by using SSL encryption.
|
|
Protect the OCSP signing keys by using an HSM.
|
|
Protect the Online Responder in extranet deployment scenarios.
|
|
Perform the hardening recommendations for the Web Services (IIS) server role.
|
|
Configure a user account as the designated registration authority.
|
Enable Windows Authentication for Intranet-Based Requests
When you install the Online Responder role service, the ocsp virtual directory is created in the Default Web Site. By default, anonymous authentication is used to access this virtual directory. When the Online Responder only services intranet-based computers, you can configure the ocsp virtual directory to use Windows Authentication.
Windows authentication uses the NTLM or Kerberos protocols to authenticate client computers. Windows authentication is best suited for an intranet environment. Windows authentication is typically not suited for use over the Internet. Instead use either Basic or Digest authentication for use over the Internet and encrypt all traffic by using SSL.
For more information about configuring a Web site to use Windows Authentication, see IIS 7.0: Configuring Authentication in IIS 7.0.
Protect Certificate Revocation Status Requests and Reponses by Using SSL Encryption
By default, the ocsp virtual directory created in the Default Web Site uses HTTP. The HTTP protocol sends the certificate revocation status requests and responses in plaintext. Microsoft strongly recommends that you protect this traffic by using SSL encryption.
For more information about how to configure a Web site to protect traffic by using SSL encryption, see "Encrypt data sent between the Web server and client" in the Help and Support for Windows Server 2008.
Protect the OCSP Signing Key by Using an HSM
OCSP digitally signs each successful request so that the requestor knows the revocation response came from a legitimate server. The Online Responder role service signs the responses by using an OCSP signing key. The signing key can be obtained from a CA or an HSM.
An HSM can be a plug-in card (PCI) or external device, such as a USB, PCMCIA, SCSI, or RS232 device that generates and stores long term secrets for use in cryptography. An HSM also physically protects access to the secrets. The primary advantage of an HSM is that it provides stronger security for the signing keys that the Online Responder role uses because the HSM is a physical device.
Another advantage is that most HSMs are also hardware cryptographic accelerators. Since the HSMs do not allow the keys to be removed from the device in an unencrypted form, they must be able to perform common cryptographic operations, and they provide better performance than a normal software-based cryptographic system.
For more information about how to configure the Online Responder to use an HSM to protect OCSP signing keys, see "Using an HSM to protect OCSP signing keys" in the Online Responder Installation, Configuration, and Troubleshooting Guide.
When you deploy extranet-facing Online Responders, one of the design considerations is to define the level of protection to provide for the Online Responder signing key. The following figure shows two options for protecting the Online Responder.
Figure 9.2 Extranet deployment options
In diagram 1 of the previous figure, the Online Responder is located in a protected local area network (LAN), while all requests are redirected by an authenticated server that is running IIS, which is located in a perimeter network (also known as DMZ, demilitarized zone, and screened subnet).
The advantage of such a deployment model is that the firewall configuration requires only pass-through traffic for TCP port 80 for HTTP traffic or TCP port 443 for HTTPS traffic between IIS and the Online Responder. You can achieve similar results by using the reverse-proxy capability of Microsoft Internet Security and Acceleration (ISA) Server as demonstrated in diagram 2 in the previous figure.
For more information about how to protect the Online Responder in extranet deployment scenarios, see "Using an HSM to protect OCSP signing keys" in the Online Responder Installation, Configuration, and Troubleshooting Guide.
Perform the Hardening Recommendations for the Web Services (IIS) Server Role
Because this role service runs on IIS 7.0, ensure to perform the hardening recommendations for the Web Services (IIS) server role. For more information about hardening the Web Services (IIS) server role, see Chapter 6, "Hardening Web Services" in this guide.
Configure a User Account as the Designated Registration Authority
The Online Responder role service needs a set of credentials that it uses to authenticate with the Certification Authority when requesting a certificate, which is known as the designated registration authority.
Microsoft recommends creating a user account to serve as the designated registration authority instead of using the network service account (NetworkService) for this purpose. This is because you can assign only the necessary rights and permissions to a user account, while the NetworkService account may have more rights and permissions than are necessary. In addition, you could affect other software running on the computer if you change the rights and permissions granted to the NetworkService account. The user account must be a member of the Domain and you must add it to the local IIS_IUSRS group.
|
