Implementing an OCSP responder

[patris1]

http://blogs.technet.com/askds/archive/2009/06/24/implementing-an-ocsp-responder-part-i-introducing-ocsp.aspx

Part I - Introducing OCSP

Chris here again. For those Security Architects and PKI implementers, you may have known that since Windows Server 2008 we have an Online Certificate Status Protocol (OCSP) responder, and since Windows Vista we have an OCSP client that is integrated with the operating system. I wanted to cover the in and outs of the OCSP responder, and walk through the installation.
So, you may be asking the question “OCSP what?” First a little background. One of the capabilities of a PKI and in particular a Certificate Authority, aside from issuing certificates, is to publish revocation information.
For example, let’s say you issue a User certificate to a user for authentication. When the user leaves the company you will most likely want to make sure no one can use that certificate for authentication so you log onto the Certificate Authority and revoke that certificate. Each CA has a period specified when it publishes what are called Certificate Revocation Lists or CRLs for short. When the next CRL is published it will contain the serial number of the certificate, the date and time it was revoked, and the reason that the certificate was revoked. Depending on the configuration the CA it will publish the CRL to a repository such as an LDAP server or a web server. In some instances a task or job must be created to copy the CRL to a repository.
Aside from CRLs, there are also delta CRLs. Delta CRLs simply contain the revocation information for certificates that have been revoked since the last Base CRL was published. In order to determine revocation status an application would examine the last base CRL, and the latest delta CRL. The reason for publishing delta CRLs is to provide revocation information that has more current data. Also, it can reduce bandwidth since if the base CRL is already cached on the client, just the delta CRL can be downloaded. More on this later.
In order for applications to determine if a certificate has been revoked, the application examines the CRL Distribution Point (CDP) extension in the certificate. This extension will have information on locations where the CRL can be obtained. These locations are normally either HTTP or LDAP locations.
The application then can go to those locations to download the CRL. There are, however, some potential issues with this scenario. CRLs over time can get rather large depending on the number of certificates issued and revoked. If CRLs grow to a large size, and many clients have to download CRLs, this can have a negative impact on network performance. More importantly, by default Windows clients will timeout after 15 seconds while trying to download a CRL. Additionally, CRLs have information about every currently valid certificate that has been revoked, which is an excessive amount of data given the fact that an application may only need the revocation status for a few certificates. So, aside from downloading the CRL, the application or the OS has to parse the CRL and find a match for the serial number of the certificate that has been revoked.
With the above limitations, which mostly revolve around scalability, it is clear that there are some drawbacks to using CRLs. Hence, the introduction of Online Certificate Status Protocol (OCSP). OCSP reduces the overhead associated with CRLs. There are server/client components to OCSP: The OCSP responder, which is the server component, and the OCSP Client. The OCSP Responder accepts status requests from OCSP Clients. When the OCSP Responder receives the request from the client it then needs to determine the status of the certificate using the serial number presented by the client. First the OCSP Responder determines if it has any cached responses for the same request. If it does, it can then send that response to the client. If there is no cached response, the OCSP Responder then checks to see if it has the CRL issued by the CA cached locally on the OCSP. If it does, it can check the revocation status locally, and send a response to the client stating whether the certificate is valid or revoked. The response is signed by the OCSP Signing Certificate that is selected during installation. If the OCSP does not have the CRL cached locally, the OCSP Responder can retrieve the CRL from the CDP locations listed in the certificate. The OCSP Responder then can parse the CRL to determine the revocation status, and send the appropriate response to the client.
OCSP Components

OCSP Client

The OCSP Client is a component that generates OCSP requests based on information stored in the AIA extension of the certificate it is validating. The Windows OCSP client supports the Lightweight OCSP Profile as specified in RFC 5019.
OCSP Responder

Web Proxy Cache
Web Proxy Cache is the Web service that receives requests, sends and caches responses.
Online Responder Service
The Online Responder Service is the component that is responsible for managing the configuration of the OCSP responder, retrieving revocation information from the Revocation Providers, signing responses, and auditing changes to the configuration of the OCSP responder (if configured to do so).
The Online Responder service runs under the Network Service account. When you create the Revocation Configuration you will assign the Signing Certificate that will be used by the Online Responder Service to digitally sign the responses sent back to a requesting client. If you are utilizing the OCSP in conjunction with an Enterprise CA you can choose to enroll for the signing certificate during the Revocation Configuration setup, and you can also choose to automatically reenroll for signing certificates. This eases management because the Signing Certificates are generally set to be valid for a short period of time.
The reason for the short validity periods is that the OCSP signing certificate contains the id-pkix-ocsp-nocheck extension. This extension tells the client that the certificate is valid for its entire lifetime so the revocation status of the certificate is never checked. The reason why this extension is included is to avoid circular revocation checking. If this extension was not included, the client would contact the OCSP Responder to verify the revocation status for a certificate. The OCSP Responder would then respond with a signed request. The client would then have perform revocation checking for the certificate that signed the response, before finishing revocation checking for the original certificate. At this point if there was an OCSP location specified for the signing certificate, you would run into a loop where the OCSP client would ask for the revocation status for the signing certificate from the OCSP and get a signed response. Then the client would again have to validate the revocation status for the signing certificate. This would occur over and over again. Or alternatively, if a CDP location was specified for the signing certificate, you would then need to download the CRL, and verify the signing certificate, in effect making the OCSP pointless, since you would have to download a CRL to validate the OCSP Signing Certificate. We avoid all of this with the inclusion of the id-pkix-ocsp-nocheck extension.
So, since we are not checking revocation status for the OCSP Signing certificate you should have a short validity period for the OCSP Signing Certificate to increase security.
Regardless you will have to the give permissions to the private key of the OCSP Signing Certificate to the Network Service Account since that is the identity under which the service runs. If you are using the OCSP with a Windows Server 2008 Enterprise CA, in the Request Handling tab of a Version 3 Certificate Template there is the option to Add Read permissions to Network Service on the private key. This option is enabled by default on the OCSP Response Signing template.

If you are using a certificate issued from a Windows Server 2008 Standalone CA, a Windows Server 2003 Enterprise CA or a Windows Server 2003 Standalone CA, you will need to manually grant permissions to the private Key of the OCSP Signing Response Certificate to the Network Service account.

1. To manually give the Network Service Account access to the private key, open up the Certificates MMC targeted for the Local Computer.
2. Right click on the certificate, then select All Tasks from the context menu, and then select Manage Private Keys…

3. Click Add on the Permissions dialog box.

4. Type Network Service, and then click Check Names to resolve the name. Then click OK.

5. The Network Service only needs read permissions to the Private Key, so deselect the Allow privilege for Full Control, and verify the Allow privilege is granted for Read, and click OK.

Revocation Configuration
A Revocation Configuration contains PKI components required to respond to an OCSP request. These include items such as the CA Certificate, OCSP Signing Certificate, and information about the Revocation Provider.
You can have multiple Revocation Configurations per OCSP Responder allowing the OCSP Responder to provide revocation information for multiple CAs.
When configuring the Revocation Configuration for the OCSP Responder you will designate the following

• The certificate of the CA for which you are providing revocation status
• The Signing Certificate (If the CA is an Enterprise CA, and you are using a certificate template)
• The Revocation Provider (Limited to Base and Delta CRLs in Windows Server 2008)

Revocation Provider is the component responsible for retrieving revocation information. In Windows Server 2008 the only revocation provider supported is the CRL based Revocation Provider. In other words the Windows Server 2008 OCSP Responder can only retrieve revocation information from published CRLs.
High Availability

OCSP Responders can be configured for high availability by placing the OCSP responders in an Array. The Array itself does not provide fault tolerances, but maintains the configurations of multiple OCSP responders that are part of the Array. The configuration is maintained by the OCSP Responder that is designated as the “Array Controller”.
Once the responders are arranged in an Array you can use Network Load Balancing to provide a highly available configuration.
I will cover the process of creating a highly available OCSP configuration in a future blog article.
Conclusion

I hope you found the information in this posting helpful. I plan on continuing the series on deploying an OCSP Responder. I will be posting the following blog entries soon, stay tuned:
Implementing an OCSP responder: Part I Introducing OCSP
Implementing an OCSP responder: Part II Preparing Certificate Authorities
Implementing an OCSP responder: Part III Configuring OCSP for use with Enterprise CAs
Implementing an OCSP responder: Part IV Configuring OCSP for use with Standalone CAs
Implementing an OCSP Responder: Part V High Availability
Implementing an OCSP Responder: Part VI Configuring Custom OCSP URIs via Group Policy

- Chris Delay

---

موضوعات مشابه:

• Implementing Reverse Proxy Using Squid
• Implementing Private VLANs - How They REALLY Work

---

[patris1]

http://blogs.technet.com/askds/archive/2009/06/25/implementing-an-ocsp-responder-part-ii-preparing-certificate-authorities.aspx

Part II - Preparing Certificate Authorities

Chris here again. In Part I we covered some of the basics and background information on the reason for the OCSP Responder and a basic understanding of how the OCSP Responder functions. So now we look towards implementing the OCSP Responder. However, before we move forward with the Install of the OCSP Responder we must first configure the CA to support OCSP for revocation status checking.
As discussed in the first part of this series, the OCSP Responder provides revocation information to clients or application requesting revocation status for a specific certificate. In order for this to be accomplished there are certain prerequisites that need to be in place.
Some of the prerequisites are different depending on which version of the CA you are using, and whether you are using a Standalone or Enterprise CA.
Configuring AIA Extension to support OCSP

To advertise that revocation status information for a particular CA can be obtained via OCSP, the CA must include a pointer to the OCSP Responder in the certificate. This is done by adding an OCSP URI to the AIA extension of the certificate.
Although this is mentioned as a prerequisite, you may want to do this after the OCSP Responder is configured. The reason being is that if you issue certificates before the Responder is available you will create unnecessary traffic to the soon to be OCSP location.

1. Open the Certification Authority Snap-in on the CA, as an Enterprise Administrator.
2. Right click on the CA name, and select Properties

3. Click on the Extension Tab. From the Select Extension drop down Box, select Authority Information Access (AIA).

4. Then click on the Add… button to add the OCSP location
5. Type the location for the OCSP responder. This will typically be:
http://<fqdn of the ocsp responder>/ocsp
6. Then click OK.

7. Check the Checkbox for Include in the online certificate status protocol (OCSP) extension.

8. And click OK, to close the CA Properties.

Preparing Windows Server 2003 Standalone CA for use with OCSP Responder

OCSP Signing Certificates
In order to be able to deploy the OCSP Signing Certificate used by the OCSP Responder, there are some configuration changes that need to be made on a Windows Server 2003 CA.
A signing certificate includes the id-pkix-ocsp-nocheck extension. This extension informs the OCSP client that the OCSP signing certificate should not be checked for revocation during the lifetime of the certificate. The OCSP Signing certificate should therefore have a short lifetime. By default, a Windows Server 2003 CA will ignore the id-pkix-ocsp-nocheck extension in a certificate request and will not include that extension in the issued certificate. To change this behavior, you must allow custom extensions to be used in certificate requests.
To enable support for custom extensions, run the following command on the CA:

The extension object ID (OID) for the id-pkix-ocsp-nocheck extension is1.3.6.1.5.5.7.48.1.5. The above command instructs the CA to include that extension in the issued certificate if it is found in the request.
Preparing Windows Server 2003 Enterprise CA for use with OCSP Responder

If you plan on using a Windows Server 2003 Enterprise CA to issue the OCSP Signing Certificate you will need to follow the instructions outlined in the previous section for enabling the use of custom extensions.
If you plan on using a certificate template on the Windows Server 2003 Enterprise CA, you must have at least 1 Windows Server 2008 Enterprise CA in the environment. The reason is you will be duplicating the Version 3 OCSP Signing Template on the Windows Server 2008 CA for use with the Windows Server 2003 CA. Both the Windows Server 2003 and Windows Server 2008 CA, must be running Enterprise Edition. This is due to the fact that only Version 1 templates are supported in the Standard Editions of the Server OS.
Duplicating the OCSP Signing Template

1. Logon to a Windows Server 2008 Enterprise CA, with an account that is a member of the Enterprise Admins group.
2. Open up the Certificate Template management console (certtmpl.msc).
3. Right click on OCSP Response Signing Template, and select Duplicate Template from the context menu, as illustrated below:

4. From the Duplicate Template dialog box, select Windows Server 2003 Server, Enterprise Edition, and click OK. Selecting Windows Server 2003 Server, Enterprise Edition, creates a Version 2 Template instead of a Version 3 Template.

5. Give a Name to the Duplicated Template, and click OK.

6. Log on to the Windows Server 2003 CA, and open the Certificate Authority Snapin (Certsrv.msc), and right click on Certificate Templates, and select New, then Certificate Template to Issue from the context menu.

7. Select the Duplicated Template, and click on OK.

Preparing Windows Server 2008 Standalone CA for use with OCSP Responder

In the previous section on preparing the Windows Server 2003 Standalone CA, we had to enable the CA to accept custom extensions sent in the request. This was to allow us to request a certificate with the id-pkix-ocsp-nocheck extension. Windows Server 2008 natively supports the id-pkix-ocsp-nocheck extension, so there is no need to allow custom extensions. On the Windows Server 2008 Enterprise CA there is no action necessary to support the id-pkix-ocsp-nocheck extension. However, on the Windows Server 2008 Standalone CA, we need to run the following command to add support for the id-pkix-ocsp-nocheck extension:

Preparing Windows Server 2008 Enterprise CA for use with OCSP Responder
The only preparation required for the Windows Server 2008 Enterprise CA, is to give permissions to the templates to the OCSP Servers, and to make the template available for issuance.

1. Open the Certificate Template Management console (certtmpl.msc)
2. Locate the OCSP Certificate Template, Right-click, and select Properties
3. On the Security Tab, add the hostname of the soon to be OCSP Server, and give the server Read and Enroll permissions to the template. Note: A more scalable solution, as seen in the illustration below, is to create a security group, assign permissions to the security group, and add any OCSP servers to the Security Group.

4. Go back to the Certification Authority management console, Right-click on the Certificates Templates node, and from the context menu, select New and then "Certificate Template to issue.

5. Select the OCSP Response Signing Template, and select OK.

Conclusion

You should now have your Certificate Authorities configured to support the OCSP Responder as a source of revocation status. In the next part of this series I will cover installing and the configuring the OCSP Responder to support Enterprise CAs.
Implementing an OCSP responder: Part I Introducing OCSP
Implementing an OCSP responder: Part II Preparing Certificate Authorities
Implementing an OCSP responder: Part III Configuring OCSP for use with Enterprise CAs
Implementing an OCSP responder: Part IV Configuring OCSP for use with Standalone CAs
Implementing an OCSP Responder: Part V High Availability
Implementing an OCSP Responder: Part VI Configuring Custom OCSP URIs via Group Policy

- Chris Delay

[patris1]

http://blogs.technet.com/askds/archive/2009/06/29/implementing-an-ocsp-responder-part-iii-configuring-ocsp-for-use-with-enterprise-cas.aspx

Part III - Configuring OCSP for use with Enterprise CAs

Chris here again. As promised I will be covering configuring an OCSP Responder to support Enterprise CA. I will also be covering validating your OCSP Configuration.
Installing OCSP Responder Role

The first step is to install the OCSP Responder Role.
To install the OCSP Responder: Open a command prompt and type: servermanagercmd.exe –install ADCS-Online-Cert.
Configuring the OCSP Responder

First we will add a Revocation Configuration to the OCSP Responder.
Right click on the Revocation Configuration and select Add Revocation Configuration from the context menu.

The Add Revocation Configuration wizard opens. Click Next to continue.

Give a Friendly Name to the Revocation Configuration, and click Next. It is a good idea to include the name of the CA for which you are setting up this Revocation Configuration, especially if this OCSP Responder will handle requests for multiple CAs.

On the Select CA Certificate page, you will need to select a CA certificate. This is where you determine the CA for which you will be providing revocation information.
Select a certificate for an Existing enterprise CA, and click Next

Select Browse CA certificates published in Active Directory, and click Browse.

Select the appropriate CA, and click OK

Next you will need to select a certificate that will be used for signing OCSP responses. For a particular Revocation Configuration, the OCSP Signing certificate must be issued by the CA for which the OCSP Responder will answer revocation status requests.
Select Automatically select a signing certificate. If you wish to automatically enroll for the OCSP Response Signing Certificate, make sure the Auto-Enroll for an OCSP signing certificate is checked. Select the certificate template that you configured for use with the OCSP Responder, then click Next.

On the Revocation Provider page, you can click Provider to select revocation providers. The Windows Server 2008 OCSP Responder can only use CRLs for revocation information. If you have the CDP Extension available in the signing certificate, the Revocation Providers will be populated from the information in the CDP Extension from the OCSP Response Signing Certificate.

You can add the repository locations for your CRLs and Delta CRLs if appropriate. By default these will be populated from information included in the CDP extension of the Signing certificate. After you have reviewed the configuration or made any changes, click OK.

That completes the initial Configuration of the OCSP Responder. If you would like to modify the configuration of the OCSP Responder, you can right click on the Revocation Configuration and select Properties from the context menu.

The Local CRL tab allows you to configure a Local CRL. You can add revocation information for certificates which you wish to consider revoked. It is recommended that you do not use this option, as it adds unnecessary complexity to the revocation configuration.

The Revocation Provider tab allows you to modify the location of the CRLs and Delta CRLs that will be used for providing revocation information.

Signing Tab
In the signing tab you can:

• Modify the hash algorithm used to sign responses.
• Do not prompt for credentials for cryptographic operations. This setting may need to be disabled if you are using an HSM to protect the private key of the OCSP Signing certificate. Disabling this setting allows you to be prompted for the password that is associated with the operator card on the HSM.
• Use renewed certificates for signing certificates. This option is enabled by default, when you use the OCSP Responder with an Enterprise CA and automatically renew certificates. If you use OCSP Responder with a standalone CA, the OCSP responder will use renewed signing certificates even if this setting is not enabled.
• Enable NONCE extension support allows the user to attach the NONCE sent in the request with the OCSP response. If this setting is used, you will not be able to utilize cached responses.
• Use any valid OCSP signing certificate. Not recommended if the OCSP Responder is supporting Vista clients since they do not support this option. This allows the OCSP responder to use any certificate that the OCSP Signing configured in the Extended Key Usage extension of the certificate. Vista clients will only accept OCSP responses that are signed by the same CA for which the OCSP Responder is providing revocation information.
• All responses will included the following Online Responder identifies: This setting determines whether a Key Hash or Subject will be included in the response. RFC 2560 specifies the structure of the response. In section 4.2.1 of the RFC it is specified that the Responder ID field can either be populated with a Name or Key hash. This setting determines which is included in the response. The Key hash is a hash of the OCSP Responder’s public key. The Name is the distinguished name of the subject of the OCSP signing certificate.

Verify OCSP Configuration

After configuring the OCSP Responder, you will want to verify that the OCSP responder is functioning properly. The easiest way to verify that the OCSP is functioning is to use the Certutil URL Retrieval tool.
First request a certificate from the CA. Place a copy of that cert on the file system, and run the following command: certutil –URL <Certificate Name>. This will open the URL Retrieval Tool

Select OCSP, and click on the Retrieve button.

If the certificate is valid you will get the following response.

If the certificate is revoked, you will get the following response.

And if it fails, the status will be listed as Failed.

You can also use the PKIView tool to verify the configurations of the OCSP Responder.

Conclusion

This concludes configuring an OCSP Responder to support an Enterprise CA. If you follow the steps listed here you now have your OCSP configured to support your Windows Server 2003 or Windows Server 2008 CA. In the next part of this series, I will be configuring an OCSP Responder to support Standalone CA.
Implementing an OCSP responder: Part I Introducing OCSP
Implementing an OCSP responder: Part II Preparing Certificate Authorities
Implementing an OCSP responder: Part III Configuring OCSP for use with Enterprise CAs
Implementing an OCSP responder: Part IV Configuring OCSP for use with Standalone CAs
Implementing an OCSP Responder: Part V High Availability
Implementing an OCSP Responder: Part VI Configuring Custom OCSP URIs via Group Policy

- Chris Delay

[patris1]

http://blogs.technet.com/askds/archive/2009/06/30/implementing-an-ocsp-responder-part-iv-configuring-ocsp-for-use-with-standalone-cas.aspx

Part IV - Configuring OCSP for use with Standalone CAs

Chris here again. In part I of this series we covered the basics of how OCSP works. We also covered the underlying reasons for deploying an OCSP Responder. In Part II we covered configuring the Certificate Authorities for whom which the OCSP Responder will check revocation status for on behalf of the clients. In Part III we covered configuring and OCSP Responder to support an Enterprise CAs. You may use Standalone CAs in your environment. In this blog post, I will be covering deploying a Revocation Configuration to support a Standalone CA.
Enterprise CAs are very tightly integrated with Active Directory. As such the certificates for the Root CA and for intermediate CAs are published to Active Directory. These certificates are automatically placed in the appropriate certificate stores on the clients. If you publish the Root CA certificate that the issuing CA chains up to; in Active Directory the clients will have that Root CA certificate published to the Trusted Root Certification Authorities container in the user and machine store. If you have not, or do not plan to deploy the Root CA certificate through Active Directory and Group Policy you will need to manually publish the Root Certificates in the Trusted Root Certification Authority store.
Installing OCSP Responder Role

The first step is to install the OCSP Responder Role.
To install the OCSP Responder: Open a command prompt and type: servermanagercmd.exe –install ADCS-Online-Cert
Requesting and Installing the OCSP Responder Signing Certificate

The next step is to request the OCSP Response Signing Certificate from the Standalone CA. Since a Standalone CA does not have certificate templates we must manually request the attributes we would like in the certificate. To do this we use a utility called certreq.exe. More information for Certreq is available here: Appendix 3: Certreq.exe Syntax.
To use certreq we must first generate a configuration file. FIgure 1 shows a sample configuration file. The key items that must be included is the OCSP Signing OID, and the OCSP No Revocation Check Extension, otherwise known as the id-pkix-ocsp-nocheck extension.

Let us take a look at this configuration file.
· First we have [NewRequest] which is a required section indicating that this is for a new certificate request.
· Then we have the subject in X.500 format. You can also use the ldap format which is derived from X.500. For example: CN=FCOCSP01,DC=Fourthcoffe,DC=Com. Alternatively, you could use just the common name, such as CN=FCOCSP01.
· PrivateKeyArchive=False since we will not be archiving the private key.
· Exportable=True which gives us the option to export the private key if so desired.
· UserProtected=False which disables strong key protection.
· MachineKeySet =True which is used to indicte that the resulting certificate will be stored in the machine store.
· ProviderName=”Microsoft Enhanced Cryptographic Provider v1.0” specifies the Cryptographic Service Provider (CSP) that will be used.
· UseExistingKey Set=False indicates that this request is for a new certificate, with a new key pair.
· RequestType=CMC tells certreq to generate the request in CMC format.
· Then we specify the new section [EnhancedKeyUsageExtension] which indicates what extensions should be placed in the EKU Extension in the certificate. Under that extension we specify that this certificate can be used for OCSP Signing by specifying the OCSP Signing OID (OID=”1.3.6.1.5.5.7.3.9).
· We then start a new section called [Extensions] and specify that the id-pkix-ocsp-nocheck extension should be included in the certificate.
Below are the steps for generating the request and installing the signing certificate:

1. First we use certreq to generate the request file. We specify the configuration file and the output request file. The key pair for this certificate is generated at the same time the request file is created by Certreq.

2. Next, we must submit the request to the CA. Copy the request file over to the Standalone CA. From the Certification Authority MMC, right click on the CA Name, and select All Tasks from the context menu, and then Submit New Request.

3. Browse to the request file, and select Open.
4. The request will then show up in Pending Requests. Right click on the request, and select All Tasks from the context menu, then select Issue.

5. You will now find the requested Certificate under Issued Certificates. Double click on the certificate to view its properties.

6. Verify the certificate. Key things to look for here are the presence of the OCSP No Revocation Checking Extension. And that OCSP Signing is specified in the Enhanced Key Usage (EKU) Extension.

Exporting the Certificate from the CA

1. First select Copy to File from the Details Tab of the Certificate Properties. This will open the Certificate Export Wizard.
2. Click Next at the Welcome Screen.
3. Select DER encoded binary x.509 (.CER), and click Next.
4. Browse to the location where you which to save the resulting certificate, and give the certificate a name, and click on Save.
5. Click Finish at the Completing the Certificate Export Wizard screen.
6. You will be prompted that The export was successful. Click OK.

Installing the OCSP Response Signing Certificate
Copy the resulting certificate to the OCSP Server. Open up a command prompt. Navigate to the location where you saved the certificate file, and run certreq –accept <Certificate Name>, to complete the installation of the certificate.

Configuring Private Key Permissions
The Online Responder Service runs under the Network Service account. By default the Network Service account does not have access to private keys of certificates located in the Local Computer Personal store. To give the Network Service access, perform the following steps:

1. Open up the Certificates MMC targeted for the Local Computer.
2. Right click on the certificate, then select “All Tasks” from the context menu, and then select Manage Private Keys….

3. Click Add on the Permissions dialog box.

4. Type Network Service,and then click Check Names to resolve the name. Then click OK.

5. The Network Service only needs read permissions to the Private Key, so deselect the Allow privilege for Full Control, and verify the Allow privilege is granted for Read, and click OK.

Now that we have installed the OCSP Response Signing certificate, and configured Private Key permissions, we must now configure the Revocation Configuration for the CA, on the OCSP Responder. Open the OCSP Management Console. Follow the following steps to configure the Revocation Configuration:

1. Right click on Revocation Configuration, and select Add Revocation Configuration from the context menu.

2. This will start the Add Revocation Configuration wizard. Click Next, when presented with the Getting started with adding a revocation configuration screen.

3. On the Name the Revocation Configuration screen, give a name to the configuration, and click Next. Note: It is a good idea to name the configuration for the CA server, in case this Responder will be used for multiple CAs.

4. On the Select CA Certificate Location screen, Select a certificate from the Local certificate store, and click Next.

5. On the Choose CA Certificate screen, click Browse.

6. Select the CA certificate, for the CA you are configuring on the OCSP Responder, and click OK.

7. You will then be returned to the Choose CA Certificate screen. The CA that you selected will be displayed. Click Next to continue.

8. You will now need to select a signing certificate, on the Select Signing Certificate screen. Select Manually select a signing certificate, and click Next.

9. You will then be returned to the Revocation Provider screen, click Finish to complete the wizard.

Assigning the Signing Certificate

After completing the Wizard, you will notice under the “Revocation Configuration Status” portion of the “Online Responder Configuration” page that the OCSP Configuration that you just added has an error indicating “Bad Signing certificate on Array controller. No need to panic at this point. This error is generated because we have not assigned the OCSP Response Signing certificate yet.

Now let us go ahead and assign the Signing certificate.

1. In the OCSP MMC, expand Array Configuration, and click on the name of the OCSP Server. Then in the center pane of the console, select the appropriate Revocation Configuration, then right click on that revocation configuration, and elect Assign Signing Certificate from the context menu.

2. You will then be prompted select the Signing certificate. Select the appropriate Signing certificate, and click OK.

At this point you will now see some warnings. If you look under the Revocation Configuration Status for the Revocation Configuration you are configuring, you will notice this error:

Also, on the Online Responder Configuration page you will notice this error:

This is due to the fact that the Revocation Provider has not yet been verified. To verify the Revocation Provider, right click on Array Configuration, and select Refresh Revocation Data.

Once the Revocation Provider has been verified, you should see this under Revocation Configuration Status for the Revocation Configuration you are configuring.

And that OCSP Signing is specified in the Enhanced Key Usage (EKU) Extension.

Verify OCSP Configuration

To verify your ocsp configuration please follow the Verify OCSP Configuration section in Part III of this series.
Conclusion

This concludes Part IV of this Series. I hope you enjoyed the first four parts of the series and find them useful. I plan to cover other PKI topics in the near future.
Implementing an OCSP responder: Part I Introducing OCSP
Implementing an OCSP responder: Part II Preparing Certificate Authorities
Implementing an OCSP responder: Part III Configuring OCSP for use with Enterprise CAs
Implementing an OCSP responder: Part IV Configuring OCSP for use with Standalone CAs
Implementing an OCSP Responder: Part V High Availability
Implementing an OCSP Responder: Part VI Configuring Custom OCSP URIs via Group Policy

- Chris Delay

[patris1]

http://blogs.technet.com/askds/archive/2009/08/20/implementing-an-ocsp-responder-part-v-high-availability.aspx

Part V High Availability

Chris Here Again. In the four previous parts of this series we covered the basics of OCSP, as well as the steps required to prepare the CA and implement the OCSP Responder. In this section I would like to talk about how to implement a High Availability OCSP Configuration.
There are two major pieces in implementing the High Availability Configuration. The first step is to add the OCSP Responders to what is called an Array. When OCSP Responders are configured in an Array, the configuration of the OCSP responders can be easily maintained, so that all Responders in the Array have the same configuration. The configuration of the Array Controller is used as the baseline configuration that is then applied to other members of the Array.
The second piece is to load balance the OCSP Responders. Load balancing of the OCSP responders is what actually provides fault tolerance. I am going to demonstrate using the built in Windows Network Load Balancing feature of Windows Server 2008. You can of course use a third party hardware load balancer if you wish. In this example, we are going to deploy two OCSP Servers in a highly available configuration.
Firewall Exceptions

In Windows Server 2008 the Windows Firewall is enabled by default. Depending on the requirements of your enterprise, you may have the firewall in its default state, you may have it turned off, or you may have a custom configuration.
If you are unfamiliar with Windows Firewall with Advanced Security, you may want to review Windows Firewall with Advanced Security and IPSEC, which has links to a variety of sources for learning about as well configuring and implementing the Windows Firewall with Advanced Security. The document includes a link on how to deploy firewall settings with Group Policy.
The Windows Firewall with Advanced Security there are three types of profiles:

• Domain. Windows automatically identifies networks on which it can authenticate access to the domain controller for the domain to which the computer is joined in this category. No other networks can be placed in this category.
• Public. Other than domain networks, all networks are initially categorized as public. Networks that represent direct connections to the Internet or are in public places, such as airports and coffee shops should be left public.
• Private. A network will only be categorized as private if a user or application identifies the network as private. Only networks located behind a NAT device (preferably a hardware firewall) should be identified as private networks. Users will likely want to identify home or small business networks as private.

http://technet.microsoft.com/en-us/library/cc748991(WS.10).aspx
In a higher security environment you may want to configure this setting for a specific profile. For example inside an enterprise you may want to enable the rule just for the Domain Profile.
In this example when we configure the rules, we are configuring them for Any profile, which will allow the responder to be managed regardless of which profile is applied.
When you install the OCSP Role the following Inbound Rules will be configured on the Windows Firewall:
World Wide Web Services (HTTP Traffic-IN)
World Wide Web Services (HTTPS Traffic-IN)
Also, the following Outbound Rule will be enabled:
Online Responder Service (TCP-Out)
These rules allow the OCSP Responder to receive the OCSP requests from the client and to respond to the OCSP clients.
You will also need to enable the following rules to manage the OCSP Responders as well as allowing the OCSP Responder to sync the configuration with the Array Controller:
Online Responder Service DCOM-In
Online Responder Service RPC-In
To enable the rules, open the Windows Firewall with Advanced Security MMC (WF.msc) and click on Inbound Rules. Find the rule, right click on the rule and select Enable Rule from the context menu.

You should perform this action on every OCSP Responder that will be a member of the array. A more scalable solution is to place all of the OCSP Responders in a common OU, and use group policy to maintain a consistent configuration.
CA Preparation

In Part II of this series we discussed preparing the certificate authorities for use with the OCSP Responder. One of the configuration steps was to configure the Authority Information Access (AIA) extensions with the OCSP Extension that included the URL that points to the OCSP Responder. When configuring an OCSP Responder in a Load Balanced Configuration you will need to specify the name of the Load Balancer. Below is a diagram of the OCSP Infrastructure that I will walk through implementing in this blog posting. Notice that the name of the two OCSP Responders are FCOCSP01.FourthCoffee.Com and FCOCSP02.FourthCoffee.com. You will also notice that I have decided to assign the name of FCOCSP.FourthCoffee.Com to the NLB Cluster. Since I want clients to access the load balancer and let the load balancer determine which OCSP Responder that the OCSP Requests goes to, I must specify FCOCSP.FourthCoffee.Com in the OCSP URI.

DNS Configuration

As mentioned above, you will want OCSP clients to send the OCSP Requests to the Load Balancer. This allows the Load Balancer to balance requests, this is especially important if one of the OCSP Responders is offline. To ensure that clients can resolve the DNS name of the cluster you will want to register the hostname in DNS.
To register the A record for the NLB cluster in DNS, perform the following steps:

1. Open up the DNS Manager MMC (dnsmgmt.msc)
2. Right click on the appropriate zone and select New Host (A or AAAA)… from the context menu.

3. In the New Host dialogue box enter the hostname that will be used for the NLB Cluster, and enter the appropriate IP address. You can provide additional configuration such as Create associated (PTR) record if appropriate for your environment.

Configuring OCSP Responder Array

In the upcoming section we will configure two OCSP Responders in an array. The purpose of configuring an array is to maintain the same configuration between OCSP Responders. It is important to be aware of what Revocation Configurations you will be supporting with the Array. In the case of Revocation Configurations that support Enterprise CAs and that are configured to automatically enroll for an OCSP signing certificate, the process is somewhat transparent since the responders added to the array will automatically request the OCSP signing certificate. In the case of Revocation Configuration’s that support Standalone CA’s, an OCSP Signing certificate will need to be manually requested, installed and configured. And of course the OCSP Responder can support both types of Revocation Configurations on the same responder.
OCSP Responder Array Setup

Prerequisites: The Windows Firewall has been configured as shown in the Firewall Exceptions sections above.
Steps:

1. OCSP Signing Certificate must of course be available on the Enterprise CA that the array is going to provide revocation information for. All OCSP Responders that are going to be members of the Array must have Read and Enroll permissions for the OCSP Signing Certificate. Alternatively if the Array is going to support a Revocation Configuration for a Standalone CA, the OCSP signing certificate will need to be installed manually. Remember to give read permission to the Private Key for any OCSP Signing certificates that are installed manually. If you are unfamiliar with this process, instructions for giving the Network Service read permissions to the private key of the OCSP signing certificate are available in Part I of this series.
2. Configure the OCSP Responder that will become the Array Controller. For guidance on deploying an OCSP Responder please see Part III and Part IV of this series.
3. Configure the first OCSP Responder as an Array Controller.
4. Add additional OCSP Responders to the array.

I will be covering the final two steps as the other steps are covered elsewhere in this Blog Series.

1. In the Online Responder Management Console, expand Array Configuration. Select the Responder that you wish to make the Array Controller, right click on the responder name, and select Set as Array Controller from the context menu.

2. To add an OCSP Responder to the array, right click on Array Configuration, and select Add Array Member from the context menu.

3. You will then receive the Select Computer dialog box. Click on the Browse… button.
4. Enter the name of the OCSP Responder that you wish to add, and click on the Check Names button.
5. Once the computer name of the OCSP Responder has been resolved, click OK.
6. The Select Computer dialogue box will now be populated with FQDN of the computer that is hosting the Online Responder, click OK.
7. You will then be prompted to confirm that you wish to add the array member. This dialogue box will give you one last chance to abort before the configuration of the OCSP Responder is overwritten with the configuration of the Array Controller. Click Yes to continue.

8. To verify the configuration expand Array Configuration in the OCSP MMC and select the name of the Responder that was just added. The Revocation Configuration Status should be the same as illustrated in the figure below.

Note: If you are using a manually installed certificate, such as from a Standalone CA, you will receive the error in the figure below.

To rectify this issue you will need to manually assign the certificate after it is installed in the Local Machine Store. Expand Array Configuration, click on the name of the OCSP Server that was just added to the Array, and Right click on the Revocation Configuration that will be using a manually assigned signing certificate. Select Assign Signing Certificate from the context menu.

Select the appropriate certificate, and click OK.

You will then get the error listed below. This error simply indicates that the OCSP Responder has not yet retrieved revocation information, so it can not verify that the configuration is correct.

If you would like to clear this error, Right click on Array Configuration and select Refresh Revocation Data.

Installing the Network Load Balancing Feature

Before you install and configure the NLB cluster, there are some key items you will need to know ahead of time:

• What is the IP address you are going to assign to the NLB cluster?
• What DNS name you are going to associate with this cluster?

Before you can configure the NLB Cluster, you must first install the Network Load Balancing feature on all of the OCSP Responders that will be a member of the NLB cluster.
To install the NLB feature, open a command prompt, and type ServerManagerCmd –install NLB, as illustrated below.

Configuring the NLB Cluster

1. Once the Network Load Balancing feature is installed, open the Network Load Balancing Manager.
2. Select Cluster from the Menu Bar, and then select New. This will start the New Cluster Wizard.

3. Enter the hostname of the first node and click Connect, then click Next.
4. This will open the Host Parameters page of the New Cluster Wizard. Accept the defaults and click Next.
5. Next on the Cluster IP address page of the Wizard, click Add…
6. Here you will add the IP address and subnet mask of the Load Balancer. After you enter the network information, click OK.
7. Then click Next.
8. On the Cluster Parameters page add the FQDN of the cluster in the Full Internet Name text box. Configure the Cluster Operation Mode as appropriate for your environment. In this example I have selected Unicast.
9. On the Port Rules Page click Finish.

Add Nodes to the cluster

For each node that you would like to add to the NLB cluster you will need to perform the following steps.

1. Expand Network Load Balancing Clusters in the Network Load Balancing Manager. Right click on the name of the cluster and select Add Host to Cluster from the context menu. This will start the Add Host to Cluster Wizard.

2. On the Connect Page of the Wizard, enter the hostname of the node you wish to add to the cluster and click Connect.
3. On the Host Parameters page click Next.
4. On the Port Rules page of the Wizard click Finish.

Conclusion

In this posting we covered implementing a highly available OCSP Responder. In the next part of this series I will be covering how to configure clients to obtain revocation information from an OCSP Responder that is not listed in the OCSP URI of the certificate.
Implementing an OCSP responder: Part I Introducing OCSP
Implementing an OCSP responder: Part II Preparing Certificate Authorities
Implementing an OCSP responder: Part III Configuring OCSP for use with Enterprise CAs
Implementing an OCSP responder: Part IV Configuring OCSP for use with Standalone CAs
Implementing an OCSP Responder: Part V High Availability
Implementing an OCSP Responder: Part VI Configuring Custom OCSP URIs via Group Policy
-Chris ‘Tickle Fight’ Delay

[patris1]

http://blogs.technet.com/askds/archive/2009/08/21/implementing-an-ocsp-responder-part-vi-configuring-custom-ocsp-uris-via-group-policy.aspx

Part VI Configuring Custom OCSP URIs via Group Policy

Chris here again. If you have read the previous five part of the series you are at this point very familiar with the installation and configuration of the OCSP Responder. I covered implementing the OCSP Responder to support a variety of scenarios. One thing I have not covered, however, is the configuration of the OCSP Client.
If you have read my blog series on Implementing and OCSP Responder you will be aware that one of the configuration steps is to specify the OCSP URI on the CA so that it is included in issued certificates. This would definitely help with newly issued certificates, but how about certificates that have already been issued? If you could point clients to an OCSP Responder, you would now be able to use OCSP with previously issued certificates.
After some leg work by my colleague, he was able to determine that this feature already exists as of Service Pack 1. Needless to say, I felt ecstatic and dumb at the same time. Ecstatic that the feature was already implemented, and dumb that I was not aware of it. As of Windows Vista Service Pack 1, you can point clients to a specific OCSP server. You will need Windows 2008 servers or Windows Vista clients with RSAT installed to have the ability to implement this setting as a Group Policy. In other words, there is no requirement to have Windows 2008 domain controllers, only a requirement to manage the group policy with a Windows Vista SP1 /Windows Server 2008 computer.
Directing clients to an OCSP URL for certificates

The first step is to export the Certification Authority certificate from the CA. Logon to the CA and open a command prompt, then type certutil -ca.cert <CA Name>.cer and press Enter.

1. Open up the Group Policy Management Console. Find the GPO for which you would like to make the change and right click on that policy and select Edit.

2. In the Group Policy Editor navigate to Computer Configuration\Windows Settings\Security Settings\Public Key Policies\Trusted Root Certification Authorities if your issuing CA for example is not a Root CA the CA certificate would be located in the Intermediate Certification Authorities container. So, you can import the CA cert to that container in the Group Policy and add the appropriate OCSP URI.

3. This will start the Certificate Import Wizard, click Next
4. Then on the File to Import page of the wizard, click Browse…
5. Then browse to the CA certificate that was previously exported, select the certificate and then select Open
6. Then click Next
7. On the Certificate Store page, verify that Trusted Root Certification Authorities is selected and select Next
8. Then click Finish to close the wizard.
9. When prompted that The import was successful click OK
10. Then right click on the certificate that was just imported and select Properties.
11. Then click on the OCSP Tab, enter the URL for the OCSP server I want clients to query (FCOSP.FourthCoffee.com/ocsp) in the text box, and select Add URL. Also, if you want to disable CRL checking, you can check the Disable Certificate Revocation Lists (CRL) check box. I then Click OK when finished.

After group policy is updated you see two CA certificates for the CA in the Trusted Root Certification Authorities store. This is because the CA certificate is already in that store prior to adding it to Group Policy. The net result of which is that you will have two of the CA certificates in the Trusted Root Certification Authorities store. Regardless, when the chain is built, the OCSP location that was added via the group policy will be incorporated in the revocation checking process. Now clients will check the OCSP URL that you configured for revocation status even if the OCSP URI is not included in certificates.

Conclusion

The option to add the OCSP URI via group policy adds additional flexibility when using the OCSP Client included in Windows Vista. This feature will also be extremely helpful to customers that do have isolated networks as well as those customers that want OCSP support and are not ready to renew their CA hierarchy. It is also useful if you need to change the DNS name of your OCSP Responder which may occur for many reasons, including transitioning to a load balanced array, or adding additional OCSP responders.
Implementing an OCSP responder: Part I Introducing OCSP
Implementing an OCSP responder: Part II Preparing Certificate Authorities
Implementing an OCSP responder: Part III Configuring OCSP for use with Enterprise CAs
Implementing an OCSP responder: Part IV Configuring OCSP for use with Standalone CAs
Implementing an OCSP Responder: Part V High Availability
Implementing an OCSP Responder: Part VI Configuring Custom OCSP URIs via Group Policy
-Chris “TGIOCSP” Delay