Jorge's Quest For Knowledge!

All about Windows Server, ADDS, ADFS & FIM (It Is Just Like An Addiction, The More You Have, The More You Want To Have!)

Archive for the ‘Active Directory Certificate Services (ADCS)’ Category

(2012-09-13) Designing And Implementing An OCSP Responder (Part 6)

Posted by Jorge on 2012-09-13


For a PKI project that I’m working on I wanted to refresh my mind about Microsoft OCSP. I found these great articles/posts on the ASKDS blog providing information/guidelines about designing a OCSP infrastructure. Because this stuff is SO GOOD, reposted everything here also. Of course the credits of all these posts go to the original writers from ASKDS. Also make sure to read all the comments in the original source as those have not been copied. The information in the comments is also quite useful!

Have I already said, this stuff is quite good! Smile

————————————————————————————————————————————————————————————————–

ORIGINAL SOURCE: Implementing an OCSP Responder: Part VI Configuring Custom OCSP URIs via Group Policy

Implementing an OCSP Responder: Part VI Configuring Custom OCSP URIs via Group Policy

Previous part: (2012-09-13) Designing And Implementing An OCSP Responder (Part 5)

-

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.

image

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.

image

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.

image

-

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.

————————————————————————————————————————————————————————————————–

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Certificate Services (ADCS), Blog Post Series, Design Guides, OCSP | Leave a Comment »

(2012-09-13) Designing And Implementing An OCSP Responder (Part 5)

Posted by Jorge on 2012-09-13


For a PKI project that I’m working on I wanted to refresh my mind about Microsoft OCSP. I found these great articles/posts on the ASKDS blog providing information/guidelines about designing a OCSP infrastructure. Because this stuff is SO GOOD, reposted everything here also. Of course the credits of all these posts go to the original writers from ASKDS. Also make sure to read all the comments in the original source as those have not been copied. The information in the comments is also quite useful!

Have I already said, this stuff is quite good! Smile

————————————————————————————————————————————————————————————————–

ORIGINAL SOURCE: Implementing an OCSP Responder: Part V High Availability

Implementing an OCSP Responder: Part V High Availability

Previous part: (2012-09-13) Designing And Implementing An OCSP Responder (Part 4)

-

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.

image

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.

image

-

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.

image

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.

image

-

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.

Note: if using OCSP Responders on hyper-V guests, see extra steps here on how to configure NLB virtual guests.

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.

image

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

image

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.

image

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.

image

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

image

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.

image

Select the appropriate certificate, and click OK.

image

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.

image

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

image

-

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.

image

-

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.

image

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.

image

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.

Next part: (2012-09-13) Designing And Implementing An OCSP Responder (Part 6)

————————————————————————————————————————————————————————————————–

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Certificate Services (ADCS), Blog Post Series, Design Guides, OCSP | 1 Comment »

(2012-09-13) Designing And Implementing An OCSP Responder (Part 4)

Posted by Jorge on 2012-09-13


For a PKI project that I’m working on I wanted to refresh my mind about Microsoft OCSP. I found these great articles/posts on the ASKDS blog providing information/guidelines about designing a OCSP infrastructure. Because this stuff is SO GOOD, reposted everything here also. Of course the credits of all these posts go to the original writers from ASKDS. Also make sure to read all the comments in the original source as those have not been copied. The information in the comments is also quite useful!

Have I already said, this stuff is quite good! Smile

————————————————————————————————————————————————————————————————–

ORIGINAL SOURCE: Implementing an OCSP responder: Part IV – Configuring OCSP for use with Standalone CAs

Implementing an OCSP responder: Part IV – Configuring OCSP for use with Standalone CAs

Previous part: (2012-09-13) Designing And Implementing An OCSP Responder (Part 3)

-

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: http://technet.microsoft.com/en-us/library/cc736326.aspx.

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.

image

-

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.

image

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.

image

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.

image

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

image

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.

image

-

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.

image

-

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….

image

3. Click Add on the Permissions dialog box.

image

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

image

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.

image

-

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.

image

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

image

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.

image

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

image

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

image

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

image

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

image

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.

image

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.

image

-

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.

image

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

image

-

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:

image

-

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

image

-

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.

image

-

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

image

-

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

image

-

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.

Next part: (2012-09-13) Designing And Implementing An OCSP Responder (Part 5)

————————————————————————————————————————————————————————————————–

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Certificate Services (ADCS), Blog Post Series, Design Guides, OCSP | 1 Comment »

(2012-09-13) Designing And Implementing An OCSP Responder (Part 3)

Posted by Jorge on 2012-09-13


For a PKI project that I’m working on I wanted to refresh my mind about Microsoft OCSP. I found these great articles/posts on the ASKDS blog providing information/guidelines about designing a OCSP infrastructure. Because this stuff is SO GOOD, reposted everything here also. Of course the credits of all these posts go to the original writers from ASKDS. Also make sure to read all the comments in the original source as those have not been copied. The information in the comments is also quite useful!

Have I already said, this stuff is quite good! Smile

————————————————————————————————————————————————————————————————–

ORIGINAL SOURCE: Implementing an OCSP responder: Part III – Configuring OCSP for use with Enterprise CAs

Implementing an OCSP responder: Part III – Configuring OCSP for use with Enterprise CAs

Previous part: (2012-09-13) Designing And Implementing An OCSP Responder (Part 2)

-

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.

image

-

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

image

-

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.

image

-

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

image

-

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

image

-

Select the appropriate CA, and click OK

image

-

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.

image

-

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.

image

-

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.

image

-

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.

image

-

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.

image

-

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

image

-

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.

image

-

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

image

-

Select OCSP, and click on the Retrieve button.

image

-

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

image

-

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

image

-

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

image

-

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

image

-

-

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.

Next part: (2012-09-13) Designing And Implementing An OCSP Responder (Part 4)

————————————————————————————————————————————————————————————————–

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Certificate Services (ADCS), Blog Post Series, Design Guides, OCSP | 1 Comment »

(2012-09-13) Designing And Implementing An OCSP Responder (Part 2)

Posted by Jorge on 2012-09-13


For a PKI project that I’m working on I wanted to refresh my mind about Microsoft OCSP. I found these great articles/posts on the ASKDS blog providing information/guidelines about designing a OCSP infrastructure. Because this stuff is SO GOOD, reposted everything here also. Of course the credits of all these posts go to the original writers from ASKDS. Also make sure to read all the comments in the original source as those have not been copied. The information in the comments is also quite useful!

Have I already said, this stuff is quite good! Smile

————————————————————————————————————————————————————————————————–

ORIGINAL SOURCE: Implementing an OCSP responder: Part II – Preparing Certificate Authorities

Implementing an OCSP responder: Part II – Preparing Certificate Authorities

Previous part: (2012-09-13) Designing And Implementing An OCSP Responder (Part 1)

-

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

image

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

image

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.

image

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

image

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:

image

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:

image

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.

image
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.

image

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

image

-

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:

image

-

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.

image

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.

image

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.

Next part: (2012-09-13) Designing And Implementing An OCSP Responder (Part 3)

————————————————————————————————————————————————————————————————–

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Certificate Services (ADCS), Blog Post Series, Design Guides, OCSP | 1 Comment »

(2012-09-13) Designing And Implementing An OCSP Responder (Part 1)

Posted by Jorge on 2012-09-13


For a PKI project that I’m working on I wanted to refresh my mind about Microsoft OCSP. I found these great articles/posts on the ASKDS blog providing information/guidelines about designing a OCSP infrastructure. Because this stuff is SO GOOD, reposted everything here also. Of course the credits of all these posts go to the original writers from ASKDS. Also make sure to read all the comments in the original source as those have not been copied. The information in the comments is also quite useful!

Have I already said, this stuff is quite good! Smile

————————————————————————————————————————————————————————————————–

ORIGINAL SOURCE: Implementing an OCSP responder: Part I – Introducing OCSP

Implementing an OCSP responder: 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.

image_thumb9

-

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

image_thumb7

3. Click Add on the Permissions dialog box.

image_thumb5

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

image_thumb3

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.

image_thumb1

-

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

Next part: (2012-09-13) Designing And Implementing An OCSP Responder (Part 2)

————————————————————————————————————————————————————————————————–

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Certificate Services (ADCS), Blog Post Series, Design Guides, OCSP | 1 Comment »

(2012-09-12) Windows Server 2008 R2 CAPolicy.inf Syntax

Posted by Jorge on 2012-09-12


In the past I posted a blog containing information about designing your PKI infrastructure. That blog post can be found here.

For a PKI project that I’m working on I wanted to refresh my mind about Microsoft PKI technologies. I found these great articles/posts on the ASKDS blog providing information/guidelines about designing a PKI infrastructure. Because this stuff is SO GOOD, reposted everything here also. Of course the credits of all these posts go to the original writers from ASKDS. Also make sure to read all the comments in the original source as those have not been copied. The information in the comments is also quite useful!

Have I already said, this stuff is quite good! Smile

————————————————————————————————————————————————————————————————–

ORIGINAL SOURCE: Windows Server 2008 R2 CAPolicy.inf Syntax

Windows Server 2008 R2 CAPolicy.inf Syntax

-

Greetings! This is Jonathan again. I was reviewing Chris’ excellent blog post series on designing and implementing a PKI when I realized that it would be helpful to better document the CAPolicy.inf file. The information in this post relies heavily on the information published in the Windows Server 2003 Help File, but this information is updated to include information pertinent to Windows Server 2008 R2.

Another helpful document that discusses many of these settings is available on Technet.

-

Background

First, what is a CAPolicy.inf file? The CAPolicy.inf contains various settings that are used when installing the Active Directory Certification Service (ADCS) or when renewing the CA certificate. The CAPolicy.inf file is not required to install ADCS with the default settings, but in many cases the default settings are insufficient. The CAPolicy.inf can be used to configure CAs in these more complicated deployments.

Once you have created your CAPolicy.inf file, you must copy it into the %systemroot% folder (e.g., C:\Windows) of your server before you install ADCS or renew the CA certificate.

I’m not going to discuss what settings you need for your particular configuration, nor will I offer guidance on how you should set up your PKI to meet whatever your needs may be. Please follow Chris’ series for that sort of information. I’m simply going to document the available settings in the CAPolicy.inf which, if you follow Chris’ guidance, you’ll find will come in handy.

Let’s get started, shall we?

As I mentioned earlier, the CAPolicy.inf file uses the .INF file structure to specify sections, settings, and values for those settings. It will be impossible here to define a default template suitable for all purposes, so I’m just going to describe all the options and allow you to decide which settings meet your needs. Not all the settings below are required in the file, but those that are required will be called out.

The following key words are used to describe the .INF file structure.

  • A section is an area in the .INF file that covers a logical group of keys. A section always appears in brackets in the .INF file.
  • A key is the parameter that is to the left of the equal sign.
  • A value is the parameter that is to the right of the equal sign.

-

Version

The first two lines of the CAPolicy.inf file are:

[Version]
Signature=”$Windows NT$”

  • [Version] is the section.
  • Signature is the key.
  • “$Windows NT$” is the value.

Version is the only required section, and must be at the beginning of your CAPolicy.inf file.

-

PolicyStatementExtension

Next is the PolicyStatementExtension section. This section lists the name of the policies for this CA. Multiple policies are separated by commas. The names LegalPolicy and ManagementPolicy are used here as examples, but the names can be whatever the CA administrator chooses when creating the CAPolicy.inf file.

NOTE: Administrator defined section names must observe the following syntax rules:

  • A section name cannot have leading or trailing spaces, a linefeed character, a return character, or any invisible control character, and it should not contain tabs.
  • A section name cannot contain either of the bracket ([]) characters, a single percent (%) character, a semicolon (;), or any internal double quotation () characters.
  • A section name cannot have a backslash (\) as its last character.

The names have meaning in the context of a specific deployment, or in relation to custom applications that actually check for the presence of these policies.

[PolicyStatementExtension]
Policies=LegalPolicy,ManagementPolicy

For each policy defined in the PolicyStatementExtension section there must be a section that defines the settings for that particular policy. For the example above, the CAPolicy.inf must contain a [LegalPolicy] section and a [ManagementPolicy] section.

For each policy, you need to provide a user-defined object identifier (OID) and either the text you want displayed as the policy statement or a URL pointer to the policy statement. The URL can be in the form of an HTTP, FTP, or LDAP URL. Continuing on with the example started above, if you are going to have text in the policy statement, then the next three lines of the CAPolicy.inf will be:

[LegalPolicy]
OID=1.1.1.1.1.1.1
Notice=”Legal policy statement text”

If you are going to use a URL to host the CA policy statement, then next three lines would instead be:

[ManagementPolicy]
OID=1.1.1.1.1.1.2
URL=http://pki.wingtiptoys.com/policies/managementpolicy.asp

Please note that the OID above is arbitrary and is used as an example. In a true deployment, you would obtain an OID from your own OID gatekeeper.

In addition:

  • Multiple URL keys are supported
  • Multiple Notice keys are supported
  • Notice and URL keys in the same policy section are supported.
  • URLs with spaces or text with spaces must be surrounded by quotes. This is true for the URL key, regardless of the section in which it appears.
  • The Notice text has a maximum length of 511 characters on Windows Server 2003 [R2], and a maximum length of 4095 characters on Window Server 2008 [R2].

An example of multiple notices and URLs in a policy section would be:

[LegalPolicy]
OID=1.1.1.1.1.1.1
URL=http://pki.wingtiptoys.com/policies/legalpolicy.asp
URL=ftp://ftp.wingtiptoys.com/pki/policies/legalpolicy.asp
Notice=”Legal policy statement text”

-

CRLDistributionPoint

You can specify CRL Distribution Points (CDPs) for a root CA certificate in the CAPolicy.inf. This section does not configure the CDP for the CA itself. After the CA has been installed you can configure the CDP URLs that the CA will include in each certificate that it issues. The URLs specified in this section of the CAPolicy.inf file are included in the root CA certificate itself.

[CRLDistributionPoint]
URL=http://pki.wingtiptoys.com/cdp/WingtipToysRootCA.crl

Some additional information about this section:

  • Multiple URLs are supported.
  • HTTP, FTP, and LDAP URLs are supported. HTTPS URLs are not supported.
  • This section is only used if you are setting up a root CA or renewing the root CA certificate. Subordinate CA CDP extensions are determined by the CA which issues the subordinate CA’s certificate.
  • URLs with spaces must be surrounded by quotes.
  • If no URLs are specified – that is, if the [CRLDistributionPoint] section exists in the file but is empty – the CRL Distribution Point extension will be omitted from the root CA certificate. This is usually preferable when setting up a root CA. Windows does not perform revocation checking on a root CA certificate so the CDP extension is superfluous in a root CA certificate.

-

Authority Information Access

You can specify the authority information access points in the CAPolicy.inf for the root CA certificate.

[AuthorityInformationAccess]
URL=http://pki.wingtiptoys.com/Public/myCA.crt

Some additional notes on the authority information access section:

  • Multiple URLs are supported.
  • HTTP, FTP, LDAP and FILE URLs are supported. HTTPS URLs are not supported.
  • This section is only used if you are setting up a root CA, or renewing the root CA certificate. Subordinate CA AIA extensions are determined by the CA which issued the subordinate CA’s certificate.
  • URLs with spaces must be surrounded by quotes.
  • If no URLs are specified – that is, if the [AuthorityInformationAccess] section exists in the file but is empty – the CRL Distribution Point extension will be omitted from the root CA certificate. Again, this would be the preferred setting in the case of a root CA certificate as there is no authority higher than a root CA that would need to be referenced by a link to its certificate.

-

Enhanced Key Usage

Another section of the CAPolicy.inf file is [EnhancedKeyUsageExtension], which is used to specify the Enhanced Key Usage extension OIDs placed in the CA certificate.

  • Multiple OIDs are supported.
  • This section can be used during CA setup or CA certificate renewal.
  • This section can be used for both the root CA and for subordinate CAs.
  • This extension can be marked as Critical.

An example of this section is:

[EnhancedKeyUsageExtension]
OID=1.2.3.4.5
OID=1.2.3.4.6
Critical=No

If this section is omitted from the CAPolicy.inf file, the Enhanced Key Usage extension will be omitted from the root CA certificate. If this extension does not exist in a root CA certificate then that root CA certificate can be trusted for all purposes.

By populating this section with specific OIDs, you are limiting the purposes for which the root CA certificate can be trusted. For example, consider the following section:

[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.4        ; Secure Email
OID=1.3.6.1.4.1.311.20.2.2    ; Smart Card Logon
Critical=No

During the setup of the CA, the root CA certificate will be created with the two OIDs above in the Enhanced Key Usage extension. This root certificate, because of the OIDs specified, can only be trusted for Secure Email (signing and encrypting) and Smart Card Logon. Any certificate issued for some other purpose, such as Client or Server Authentication, would be considered invalid. This restriction would apply not only to this root CA, but also to any CA subordinate to this root.

-

Basic Constraints

You can use the CAPolicy.inf file to define the PathLength constraint in the Basic Constraints extension of the root CA certificate. Setting the PathLength basic constraint allows you to limit the path length of the CA hierarchy by specifying how many tiers of subordinate CAs can exist beneath the root. A PathLength of 1 means there can be at most one tier of CAs beneath the root. These subordinate CAs will have a PathLength basic constraint of 0, which means that they cannot issue any subordinate CA certificates.

This extension can be marked as Critical.

[BasicConstraintsExtension]
PathLength=1
Critical=Yes

It is not recommended to use this section in the CAPolicy.inf file for a subordinate CA. To add a PathLength constraint to a subordinate CA certificate if the parent CA has no PathLength constraint in its own certificate, you can set the CAPathLength registry value on the parent CA. For example, to issue a subordinate CA certificate with a PathLength constraint of 1, use the following command to configure the parent CA.

Certutil –setreg Policy\CAPathLength 2

Setting this value causes the CA to behave as though its own certificate had a PathLength constraint of whatever number you specify. Any subordinate CA certificate issued by the parent CA will have a PathLength constraint set appropriately in its Basic Constraints extension.

You must restart Active Directory Certificate Services for this change to take effect.

-

Cross Certificate Distribution Points

The cross certificate distribution points (CCDP) extension identifies where cross certificates related to the CA certificate can be obtained and how often that location is updated. The CCDP extension is useful if the CA has been cross-certified with another PKI hierarchy. Windows XP and later operating systems would use this extension for the discovery of cross-certificates that might be used during the path discovery and chain building process.

The SyncDeltaTime key indicates how often, in seconds, the locations referred to by the URL key(s) are updated. While this entire section is optional, if it exists, and if the SyncDeltaTime key is present, then at least one URL key must also be present.

This extension can be marked as Critical.

[CrossCertificateDistributionPointsExtension]
SyncDeltaTime=600    ; in seconds
URL=http://pki.wingtiptoys.com/ccdp/PartnersCA.crt
Critical=No

-

Request Attributes

The [RequestAttributes] section, when implemented on a subordinate CA, allows you to specify a custom subordinate certification authority template. There is already the default Subordinate Certificate Authority template that is published in Active Directory the first time an Enterprise CA is installed in the forest. This default template, however, is a v1 template (Windows 2000-style) and cannot be edited. The CertificateTemplate key allows you specify a different template for your subordinate CA certificate request, one that you created by duplicating the default template.

[RequestAttributes]
CertificateTemplate=WingtipToysSubCA

-

Server Settings

Another optional section of the CAPolicy.inf is [certsrv_server], which is used to specify renewal key length, the renewal validity period, and the certificate revocation list (CRL) validity period for a CA that is being renewed or installed. None of the keys in this section are required. Many of these settings have default values that are sufficient for most needs and can simply be omitted from the CAPolicy.inf file. Alternatively, many of these settings can be changed after the CA has been installed.

An example would be:

[certsrv_server]
RenewalKeyLength=2048
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=5
CRLPeriod=Days
CRLPeriodUnits=
2
CRLDeltaPeriod=Hours
CRLDeltaPeriodUnits=
4
ClockSkewMinutes=
20
LoadDefaultTemplates=
True
AlternateSignatureAlgorithm=0
ForceUTF8=0
EnableKeyCounting=0

RenewalKeyLength sets the key size for renewal only. This is only used when a new key pair is generated during CA certificate renewal. The key size for the initial CA certificate is set when the CA is installed.

When renewing a CA certificate with a new key pair, the key length can be either increased or decreased. We in Support see this most often when a customer has set a root CA key size of 4096 bytes or higher, and then discover that they have Java apps or network devices that can only support key sizes of 2048 bytes. In that situation, we can use this setting in the CAPolicy.inf file to reduce the key size of the CA. Of course, that means that we have to reissue all the certificates issued by that CA. The higher up in the hierarchy the CA resides, the more inconvenient this procedure is.

RenewalValidityPeriod and RenewalValidityPeriodUnits establish the lifetime of the new root CA certificate when renewing the old root CA certificate. It only applies to a root CA. The certificate lifetime of a subordinate CA is determined by its superior. RenewalValidityPeriod can have the following values: Hours, Days, Weeks, Months, and Years.

CRLPeriod and CRLPeriodUnits establish the validity period for the base CRL, while CRLDeltaPeriod and CRLDeltaPeriodUnits establish the validity period of the delta CRL. CRLPeriod and CRLDeltaPeriod can have the following values: Hours, Days, Weeks, Months, and Years. Each of these settings can be configured after the CA has been installed:

Certutil -setreg CA\CRLPeriod Weeks
Certutil -setreg CA\CRLPeriodUnits
1
Certutil -setreg CA\CRLDeltaPeriod Days
Certutil -setreg CA\CRLDeltaPeriodUnits 1

Restart Active Directory Certificate Services for any changes to take effect.

ClockSkewMinutes allows you to accommodate possible clock synchronization issues. The CA will set the effective time of the published base CRL and delta CRL to the current time less the ClockSkewMinutes. For example, if the clock skew is set to 5 minutes, and the current time is 4:00pm, then the effective time of a newly published CRL would be 3:55pm.

This value can also be set after the CA has been installed.

Certutil -setreg CA\ClockSkewMinutes 10

Restart Active Directory Certificate Services for any changes to take effect.

The default value for ClockSkewMinutes is 10 minutes; if this interval is sufficient then this key can be omitted from the CAPolicy.inf file.

LoadDefaultTemplates only applies during the install of an Enterprise CA. This setting, either True or False (or 1 or 0), dictates whether or not the CA is configured with any of the default templates.

In a default installation of the CA, a subset of the default certificate templates is added to the Certificate Templates folder in the Certification Authority snap-in. This means that as soon as the ADCS service starts after the role has been installed a user or computer with sufficient permissions can immediately enroll for a certificate. This behavior is not always desirable.

To illustrate the point, the Domain Controller and Domain Controller Authentication templates are among the default templates added to the CA as it is installed. The default permissions on these two templates allow all domain controllers in the forest to enroll for certificates based those two templates. Finally, the default behavior of a domain controller is to immediately enroll for a Domain Controller or Domain Controller Authentication template as soon as an Enterprise CA is detected in the forest (Windows 2000 DCs will attempt to enroll for a Domain Controller certificate; Windows Server 2003 and higher will attempt to enroll for a Domain Controller Authentication certificate).

You may not want to issue any certificates immediately after a CA has been installed, so you can use the LoadDefaultTemplates setting to prevent the default templates from being added to the Enterprise CA. If there are no templates configured on the CA then it can issue no certificates.

On Windows Server 2003 and Windows Server 2003 R2, the LoadDefaultTemplates setting only applies to a root Enterprise CA. It is ignored on a subordinate Enterprise CA.

On Windows Server 2008 and Windows Server 2008 R2, the LoadDefaultTemplates setting applies to both root and subordinate Enterprise CAs.

AlternateSignatureAlgorithm configures the CA to support the PKCS#1 V2.1 signature format for both the CA certificate and certificate requests. When set to 1 on a root CA the CA certificate will include the PKCS#1 V2.1 signature format. When set on a subordinate CA, the subordinate CA will create a certificate request that includes the PKCS#1 V2.1 signature format.

ForceUTF8 changes the default encoding of relative distinguished names (RDNs) in Subject and Issuer distinguished names to UTF-8. Only those RDNs that support UTF-8, such as those that are defined as Directory String types by an RFC, are affected. For example, the RDN for Domain Component (DC) supports encoding as either IA5 or UTF-8, while the Country RDN (C) only supports encoding as a Printable String. The ForceUTF8 directive will therefore affect a DC RDN but will not affect a C RDN.

Finally, EnableKeyCounting configures the CA to increment a counter every time the CA’s signing key is used. Do not enable this setting unless you have a Hardware Security Module (HSM) and associated cryptographic service provider (CSP) that supports key counting. Neither the Microsoft Strong CSP nor the Microsoft Software Key Storage Provider (KSP) support key counting.

For more caveats to be aware of when using key counting, please review the following KB article:

951721 The certification authority startup event in the Security log always reports a usage count of zero for the signing key on a computer that is running Windows Server 2008 or Windows Server 2003

-

Conclusion

There we go. We’ve finally finished the list of all the settings you can configure via the CAPolicy.inf file.

I had at first considered putting all the sections I talked about above into one file so you could see how a “finished” CAPolicy.inf file would look. Then I realized that would be a monumentally bad idea seeing as, with the exception of the [Version] section, everything covered above is totally optional – perhaps with some settings even being contradictory. I’d hate to be responsible for a bad sample CAPolicy.inf file bouncing around the Internet.

The settings that you will want to configure in your CAPolicy.inf file will completely depend on your needs, and will vary between root CAs and subordinate CAs. I certainly hope that you find this information useful.

- Jonathan ‘Small bills only’ Stephens

-

You can also get DOCX, XPS and PDF versions of the articles/posts using the following links:

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Certificate Services (ADCS), CAPOLICY.INF | 2 Comments »

(2012-09-12) Designing And Implementing A PKI (Part 5)

Posted by Jorge on 2012-09-12


In the past I posted a blog containing information about designing your PKI infrastructure. That blog post can be found here.

For a PKI project that I’m working on I wanted to refresh my mind about Microsoft PKI technologies. I found these great articles/posts on the ASKDS blog providing information/guidelines about designing a PKI infrastructure. Because this stuff is SO GOOD, reposted everything here also. Of course the credits of all these posts go to the original writers from ASKDS. Also make sure to read all the comments in the original source as those have not been copied. The information in the comments is also quite useful!

Have I already said, this stuff is quite good! Smile

————————————————————————————————————————————————————————————————–

ORIGINAL SOURCE: Designing and Implementing a PKI: Part V Disaster Recovery

Designing and Implementing a PKI: Part V Disaster Recovery

Previous part: (2012-09-12) Designing And Implementing A PKI (Part 4)

-

Chris here again. We are now going to move onto Disaster Recovery. One of the many tasks you want to complete during the planning phase is to plan for disaster recovery. When planning for disaster recovery not only is the backup/restore process important, but the actual design of the PKI can affect how resilient your PKI infrastructure is. Additionally, proper planning can alleviate the impact of a system failure.

When the system hosting Certificates Services becomes unusable due to a failure, there are a couple of consequences of that failure.

1. The CA can no longer sign its Certificate Revocation List(CRL) or delta CRL(dCRL)

2. The CA can no longer issue certificates.

3. The CA database includes a record of certificates that have been issue or revoked, and is unavailable until the CA is recovered.

-

Signing CRLs and Delta CRLs

CRLs and delta CRLs are used by clients to determine if a certificate has been revoked. In general, applications will fail when they cannot determine the revocation status for a certificate, though some applications have the ability to disable revocation checking while others do not.

Like certificates, CRLs and delta CRLs have a period during which they are valid. Once the CRL and/or delta CRL expires an application checking the revocation status of a certificate against the expired CRL will fail. The point of this discussion is that typically the first impact you will see when a Certification Authority fails is the inability of applications to the check revocation status of any certificates.

When you design and implement a PKI you configure the validity period of the CA’s CRL and delta CRL. This design consideration has an impact in terms of disaster recovery. The maximum time you have after a CA failure to institute your recovery process without impacting certificate validation is determined by these settings.

Example 1. You have an issuing Certification Authority and it is publishing a base CRL once every 7 days and delta CRL once every day. You have approximately 24 hours since the last delta CRL was published to either restore the CA or re-sign the delta CRL before certificate validation starts failing.

Example 2. You have an issuing Certification Authority and it signs a CRL once every 7 days, but is not configured to publish a delta CRL. In this scenario you have 7 days – (the number of days since the base CRL was signed) before validation will begin to fail due to the inability to check revocation status against a valid CRL.

-

Mitigation

There are several ways that you can minimize the impact that a CA failure will have on certificate validation.

One way is to install a clustered issuing certification authority. If the active node of the cluster fails the CA can be failed over to the second node. Clustering, however, will not protect against the failure of a shared component such as storage or a Hardware Security Module (HSM). So these devices should have methods to provide failover as well, if possible.

Another option is to increase the period the base and delta CRL publication intervals (and hence, their validity periods). This can potentially give you more time to kick off your recovery process, but if the CA fails shortly before the new base or delta CRL is about to be published increasing the publication interval has done little good. One must also realize there is a trade-off involved here. Increasing the publication interval means that it will take longer for certificate consumers to become aware that a certificate has been revoked and added to the CRL.

A more complicated strategy is to set the automatic publishing interval to a longer period, and then manually publish the CRL more often. In other words you set the CRL publication interval to 7 days, and then publish a new CRL every day. This way, if the CA fails you have 6 or 7 days recognize the problem and start your recovery process. The Windows CA does not automatically publish CRLs in this fashion, but you can set up a scheduled task on the CA server to publish the CRL every 24 hours using the command line utility, certutil.exe. The command certutil -crl will will instruct the CA to publish a new base CRL with the validity period defined in the CA configuration.

There are also some group policies that you can consider as part of your overall disaster recovery planning. If you have workstations and servers running Windows Vista, 7, Server 2008, or Server 2008 R2 there is a group policy setting that extends the period of time for which the OS will consider a given CRL valid, independent of the actual validity period of the CRL. The group policy setting is located in the following location:

Computer Configuration\Windows Settings\Security Settings\Public Key Policies\Certificate Path Validation Settings.

This setting forces the client to consider the CRL or OCSP response to be valid for longer than it actually is. Below is a screenshot of the specific settings:

image

-

Recovery

In terms of recovery there is a short term workaround and a long term resolution. The short term workaround is to use a process called CRL re-signing to manually re-sign an existing CRL and extend its validity period. By doing this, you can give yourself additional time to recover the CA. CRL re-signing requires that you have a backup of the CA’s public/private key pair. I will be covering this process later in this blog posting.

The longer term fix is to restore the certification authority. This of course is not possible unless you have previously backed up the certification authority. I will also cover this later in the blog post.

CA can no longer issue certificates

Another issue that occurs when you have a CA failure is that it can no longer issue certificates. In some scenarios where certificates are issued less frequently, the inability to issue certificates may not have a business impact. In other cases, however, the impact could be considerable. For example, if a CA dedicated to issuing certificates for Network Access Protection (NAP) fails the problem would be almost immediately noticeable. NAP certificates have a lifetime of only 24 hours, so a failed CA can be a considerable problem.

-

Mitigation

One way to eliminate this issue completely is to have multiple CAs that are issuing certificates based on the same certificate templates. In this way, if one CA fails clients can still enroll for certificates on one of the other certificate authorities.

A clustered issuing certification authority is another way to mitigate against a failed CA. If one of the CAs in the cluster fails the cluster will fail over to the second node. Clustering, as mentioned earlier, will not protect against the failure of a shared component such as storage or an HSM. I’ll re-iterate the need for these devices to have methods for failover as well.

-

Recovery

Ultimately, recovering from the inability to issue certificates can be resolved by recovering the failed certification authority or installing a new issuing certification authority to issue certificates. The preferred method would be to restore the failed certification authority since it already has information about issued certificates in its CA Database.

-

CA Database

By default, the CA database contains a copy of every certificate issued, every certificate that has been revoked, and a copy of failed and pending requests. The CA Manager may decide, however, to clear out any expired certificates from the CA database in order to recover free space in the database.

Note: In Windows Server 2008 R2 you can configure a template such that issued certificates based on that template are not stored in the CA database. These so call “ephemeral certificates” generally have validity periods shorter than the publication interval of the issuing CA, so recording them so they can be later revoked makes little sense. Further, these short-lived certificates may be issued in great numbers and with great frequency. Storing them in the database can dramatically increase the database’s rate of growth. Certificates issued for NAP are examples of these ephemeral certificates.

If a CA is configured for key Archival and Recovery, the CA database will also contain the private keys for any certificates whose templates are configured for archival. Failure to recover the CA database in this case would result in losing all of these archived keys.

When a certificate authority fails the database is unavailable which makes it difficult to revoke certificates that were previously issued by the CA. It also makes it impossible to recover any certificates that have been archived in the database. Again, the database will be unavailable when the CA is unavailable. However, in rare circumstances it is possible that the CA database can become corrupted. Like all ESE databases, the CA database can be affected by hardware or disk issues that impact the database or log files.

-

Mitigation

One option to mitigate the database becoming unavailable due to a CA failure is to set up a clustered certification authority. Another option is to take regular backups of the CA. If the CA fails, you can then restore the CA from the backup. Below I discuss options for backing up the CA as well as for restoring the CA.

-

Recovery

For corrupt databases, repairs can be made with esentutil.exe. However, in most case it would be preferred to restore from a backup to avoid data loss that can be incurred when using some of the functions in esentutil.exe. Esentutil.exe can repair the structure of the database, but usually at the expense of the data stored within that structure.

-

CA Backup
System State

There are two different ways to backup the Certification Authority. The first is through a System State backup. A system state backup will back up the entire CA as well as its configuration. If the private key is stored on the CA and not on an HSM, the private key will be backed up as well. Here is additional information on System State. A system state backup should be used when you will need to restore to the same hardware.

Backing up system state in Windows Server 2003.

1. To start NT Backup, click Start then Run, type ntbackup.exe and press Enter.

2. If this is the first time you’ve run this tool, it will start the Welcome to the Backup or Restore Wizard.

3. Uncheck the Always start in wizard mode, and then click Cancel.

4. Launch NT Backup again.

5. Once NT Backup launches, select the Backup Tab, and check just System State as the item to backup.

6. Under the Backup media or file name section, select your backup media or file location where you wish to save the backup.

7. Click the Start Backup button. This will bring up the Backup Job Information dialogue box.

8. If you wish to start the backup immediately, click Start Backup.

9. If you wish to schedule the backup, click the Schedule button.

10. When prompted You must save the backup selections before you can schedule a backup. Do you want to save your current selections now?, click Yes.

11. Save the selection script.

12. After you save the selection script, the Scheduled Job Options dialogue box will open. Give the Job a name. Then click the Properties button.

13. Configure the desired schedule, and click OK. Then enter the credentials for the user that you wish the backup to run under. This account will need to either have Back up files and directories right or be a member of the Backup Operators group on the CA. Then click OK again. Click OK again, you will be prompted for the credentials again.

14. You can then click on the Schedule Jobs tab in NT Backup to check the schedule.

Restore System State in Windows Server 2003

1. On the Windows Server 2003 system on which you plan on restoring system state, open the NT Backup utility.

2. Click on the Restore and Manage Media tab.

3. Navigate to the backup of the system state, make sure that System State is checked. Under Restore files to, make sure Original location is selected, and click Start Restore.

4. You will then be prompted that Restoring System State will always overwrite current System State unless restore to an alternate location. Click OK. Then click OK, to Confirm Restore.

5. When the Restore completes, click Close.

6. You will then be prompted to restart your computer, click Yes.

Performing System State Backup Windows Server 2008 R2

1. If you have not installed Windows Backup, you will first have to install this feature. Open Server Manager, select the Features node, then click Add Features.

2. In the Add Features Wizard, select Windows Server Backup Features, then click Next, and then Install. When the installation completes, click Close.

3. You can then launch the Windows Server Backup tool, by clicking Start, then Administrative Tools, then Windows Server Backup.

4. Also, to use Windows Server Backup, you have to have an additional drive or a network location to backup to. In other words you cannot save the backup on the system drive.

5. The wizard allows you to configure a one-time backup, or schedule a backup.

6. To schedule a backup, click Backup Schedule…, under the Actions sections of the Windows Server Backup tool.

7. This will start the Backup Schedule Wizard, click Next.

8. On the Select Backup Configuration page, select Custom, and then click Next.

9. On the Select Items for Backup page of the wizard, click the Add Items button.

10. Select System State, and click OK, then click Next.

11. On the Specify Backup Time page of the wizard, select the time that you would like the backup to be scheduled for, and click Next.

12. On the Specify Destination Type page of the wizard, select either Hard Disk, Volume, or Shared Network Folder, and click Next. In this example, I am selecting Hard Disk

13. Select the Hard Disk you would like to use for backup, if it is not listed, click Show All Available Disks…, and select the appropriate disk, and click OK. Click Next.

14. You will be prompted that the disk will be reformatted and existing volumes will be deleted, click Yes if you are using this disk solely for backups, if not choose another backup destination.

15. On the Confirmation page, click Finish.

16. On the Summary page, click Close.

Restoring System State in Windows Server 2008 R2.

1. In the Actions page of the Windows Server Backup tool, click Recover…

2. This will start the Recovery Wizard, select the location of the backup, and click Next.

3. On the Select Backup Date of the wizard, select the date and time of the backup and click Next.

4. On the Select Recovery Type, select System state, and click Next.

5. On the Select Location for System State Recovery page, select Original location, and click Next.

6. On the Confirmation page of the wizard, click the Recover button.

7. You will be prompted that the recovery cannot be paused or cancelled once started, click Yes.

-

Manual Backup of the Certification Authority

A good guide to user for backing up and restoring a certification authority is:

298138 How to move a certification authority to another server
http://support.microsoft.com/default.aspx?scid=kb;EN-US;298138

Steps 1 through 3 of this document cover manually backing up the CA.

Essentially, you want to do a manual back up of the private key, CA certificate, and CA database. If you are using an HSM to protect the private key pair, you will either need to backup the private key through a method provide by the HSM vendor or have a highly available configuration for the HSMs. In general, if the private key is stored on an HSM, you do not want to backup the private key to any type of media, as this will degrade the overall security and protection of the private key. The configuration for the Certification Authority is stored in the registry so you would want to backup that registry location as well. The registry location is HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<CA Name>.

Generally the private key, CA certificate and CA configuration are going to remain relatively static. You will, however, need to perform a fresh backup should you ever renew the CA certificate or update the configuration. However, the CA database is going to grow over time as certificates are issued, requests are denied, and certificates are revoked, so you are going to want to periodically backup the database. How often you perform this back up will depend on how rapidly changes to the database are made and how tolerant you are to discrepancies between the back up and the live data.

The first time you run the backup you will want to back up the CA’s certificate and private key, the CA database, and the certificate database log. To perform this task through the GUI, open up the Certification Authority MMC snap-in (certsrv.msc).

1. Right click on the certification authority name and select All Tasks from the context menu, and then select Back up CA…

2. This will launch the Certification Authority Backup Wizard, click Next.

3. Select Private key and CA certificate and Certificate database and certificate database log. Browse to a local or network location to save the backup. The backup location must be an empty folder, and click Next.

4. Enter a password to protect the private key, and click Next, then Finish.

To backup the CA via the command line, open an elevated command prompt and type certutil –backup Path. Path is the empty directory where the backed up information will be stored. You will then be prompted for a password to protect the private key. Enter the password and then press the Enter key. You will then be prompted to confirm the password. Confirm the password and press the Enter key. A message will be sent to the console indicating what has been backed up and that the certutil –backup command completed successfully.

To backup the registry run the following command: REG EXPORT "HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<CA Name>" caconfig.reg

Copy caconfig.reg to your backup directory so that all the necessary data is in the same place.

Once you have completed a full back up of the Certification Authority, you can perform incremental backups of the CA database. Alternatively, you could choose to periodically backup the entire CA database.

Although, you can back up the database through the Certification Authority console, you will most likely want to use some sort of script of scheduled task to perform the backup periodically.

Manual Restore of the Certification Authority

Once you relocate the server that will serve as the replacement for the failed CA, you must do some initial configuration of the server. Give that server the same name as the failed CA and join it to the same domain

-

Configure AD permissions

Since you have brought online a new machine to be the CA we need to modify the security of Active Directory to allow the new machine to be able to update PKI configuration information in AD. This is because the new machine will have a new SID associated with the machine account, even though the machine account has the same name.

Open ADSIEDIT.MSC. Open the Configuration container of the Active Directory database. Browse to CN=Public Key Services, CN=Services, CN=Configuration. Next open the AIA container. Locate the object that is associated with the failed CA. Right click on that object, and select Properties from the context menu. Click on the Security Tab. Remove the CA’s computer account. Then re-add the CA’s computer account, and give it full control. This will associate the permissions with the new account.

Next open the CDP container. Locate the container associated with the failed CA. Open that container and then select the CRL object contained within that container. Right click on the CRL object, and select Properties from the context menu. Click on the Security Tab. Remove the CA’s computer account. Then re-add the CA’s computer account, and give it full control.

Next open the Enrollment Services container. Locate the object associated with the failed CA. Right click on that object, and select Properties from the context menu. Click on the Security Tab. Remove the CA’s computer account. Then click Advanced. In the Permissions tab of the Advanced Security Settings dialog box, click Add… Add the computer object for the CA. On the Permission Entry screen, select Allow for all Permissions except Full Control. Click OK 3 times.

Next open the KRA container. Locate the object that is associated with the failed CA. Right click on that object, and select Properties from the context menu. Click on the Security Tab. Remove the CA’s computer account. Then re-add the CA’s computer account, and give it full control. This will associate the permissions with the new account.

-

Installing the Certification Authority Role

Next we need to restore the Certification Authority. Log on with an account that has Enterprise Admin credentials. The first thing we will need to do is to install the Certification Authority Role. The instructions below are for a Windows Server 2008 and Windows Server 2008 R2 based CA. For exact procedures in Windows Server 2003. Please see the following article:

298138 How to move a certification authority to another server
http://support.microsoft.com/default.aspx?scid=kb;EN-US;298138

1. Open Server Manager.

2. Click on the Roles Node, then click Add Roles.

3. When the Add Roles Wizard opens, click Next.

4. Select Active Directory Certificate Services and click Next.

5. Then Click Next Again.

6. On the Select Role Services page of the wizard, select Certification Authority, and then click Next.

7. On the Specify Setup Type page of the wizard, Select Enterprise or Standalone depending on the configuration of the failed CA, and then click Next.

8. On the Specify CA Type page of the wizard, select either Root CA or Subordinate CA, depending on the configuration of the failed CA, and then click Next.

9. On the Set Up private key page of the wizard, select Use existing private key, and the sub-option of Select a certificate and use its associated private key, then click Next.

10. On the Select Existing Certificate page of the wizard, click Import.

11. Browse to the backup of the failed CA and select the P12 file from the backup, click Open. Then enter the password for the P12 file, and click OK.

12. Then click Next.

13. On the Configure Certificate Database page of the wizard, select the same database and log file locations as were specified on the failed CA, then click Next, then Install.

14. When the installation completes, click Close.

Open an elevated command prompt and use the following command to import the previously backed up CA configuration: REG IMPORT <Previously backed up registry file>.

-

Restore the CA Database

At this point, you can restore the CA database from your backup.

1. Right click on the certification authority name and select All Tasks from the context menu, and then select Restore CA…

2. You will be prompted to stop Certificate Services. Click Ok.

3. When the Certification Authority Backup Wizard starts, click Next.

4. Select Certificate database and certificate database log. Browse to a local or network location of your previously saved backup.

5. Click Next.

6. Click Finish.

7. You will be prompted to restart the CA. Unless you have further incremental backups to restore, click Yes. If you have incremental backups then click No, and walk through the steps above to restore your incremental backups.

Now if there were any additional Certificate Services roles such as Online Responder (OCSP) or Web Enrollment, you can go ahead and install those at this point.

-

CRL Re-signing

CRL re-signing is a manual process whereby the Administrator can use the CA’s backed up certificate and private keys to re-sign an existing CRL file. This process allows you to extend the lifetime of the existing CRL, and even add certificates to the CRL, effectively revoking them.

-

Importing the CA certificate and private key

To begin, you will need to have a backup of the private key of the CA. If you have the private key stored on an HSM, you will have to follow the HSM vendor’s instructions for making the private key available to another machine. If you are not using an HSM, perform the following to import the CA public and private key pair to the machine where you will be re-signing the CRLs.

1. Click Start, then Run, and type MMC, and the press Enter.

2. Select the File Menu, and then select Add/Remove Snap-in…

3. Select Certificates, and then click Add >.

4. Then select Computer account, and click Next.

5. Then select Local computer, and then click Finish.

6. Then click OK.

7. Expand the Certificates (Local Computer) node.

8. Right click on the Personal node, then select All Tasks from the context menu, and then select Import…

9. This will open the Certificate Import Wizard, click Next.

10. Click the Browse button, to browse to the P12 file located in the CA’s backup location.

11. In the drop down for the extension type, select Personal Information Exchange (*.pfx;*.p12)

12. Locate the P12 file that was previously backed up, and click Open.

13. Click Next.

14. Type the Password for the P12 file and click Next, click Next again, and click Finish.

15. Click OK to acknowledge that the import was successful.

To re-sign the CRL and Delta CRL with the same validity period as they have been previously published, use the following command:

certutil -sign <existing CRL file name> <re-signed CRL file name>

http://technet.microsoft.com/en-us/library/cc782041(WS.10).aspx

You will then have to manually publish the CRL to all CDP locations.

If you wish to adjust the validity period you can specify the validity period at the end of command in the following format DD:HH, where D=Days, and H=Hours. For example, the following command would re-sign a CRL that is valid for 14 days:

certutil -sign <existing CRL file name> <resigned CRL file name> 14:00

If you wish to add one or more issued certificates to the CRL, you specify the serial numbers in a comma separated list on the command line. For example, the following command would add serial numbers to the CRL:

certutil -sign <exiting CRL file name> <resigned CRL file name> +SerialNumber1,SerialNumber2,SerialNumber3

 

When building a PKI infrastructure it is critical to take into consideration how your design will have an effect on the availability of your PKI. However, the design also affects the way in which you may have to recover the CAs in the PKI.

You should definitely consider the criticality of PKI to your environment, and how much downtime is acceptable. This will help drive your decisions when designing the PKI and implementing the Certification Authorities.

Also, many customers make the mistake of either not being aware of how to recover a Certification Authority or do not have a documented process for doing so. When designing and implementing your PKI, I recommend that you test recovery and document the recovery steps for CAs in your PKI.

Chris "CLEAR!"

————————————————————————————————————————————————————————————————–

-

You can also get DOCX, XPS and PDF versions of the articles/posts using the following links:

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Certificate Services (ADCS), Blog Post Series, Design Guides | 2 Comments »

(2012-09-12) Designing And Implementing A PKI (Part 4)

Posted by Jorge on 2012-09-12


In the past I posted a blog containing information about designing your PKI infrastructure. That blog post can be found here.

For a PKI project that I’m working on I wanted to refresh my mind about Microsoft PKI technologies. I found these great articles/posts on the ASKDS blog providing information/guidelines about designing a PKI infrastructure. Because this stuff is SO GOOD, reposted everything here also. Of course the credits of all these posts go to the original writers from ASKDS. Also make sure to read all the comments in the original source as those have not been copied. The information in the comments is also quite useful!

Have I already said, this stuff is quite good! Smile

————————————————————————————————————————————————————————————————–

ORIGINAL SOURCE: Designing and Implementing a PKI: Part IV Configuring SSL for Web Enrollment and Enabling Key Archival

Designing and Implementing a PKI: Part IV Configuring SSL for Web Enrollment and Enabling Key Archival

Previous part: (2012-09-12) Designing And Implementing A PKI (Part 3)

-

Chris here again. Today we are going to cover configuring SSL for the Web Enrollment website which will allow Windows Server 2008 and Windows clients to use the Web Enrollment website. We are also going to cover enabling Key Archival.

-

Configuring SSL for Web Enrollment

Windows Server 2008 (R2) requires SSL in order to connect to the Web Enrollment pages. The first thing that must be done after installing the Web Enrollment role is to enable SSL on the web site within IIS. To begin, I am going to go through the process to request an SSL certificate for my web server.

-

Requesting an SSL Certificate

In Part III I covered implementing certificate templates. The fictional company, Fabrikam, created a customized template for web servers called Fabrikam WebServer. This template was configured to construct the certificate subject information from Active Directory. When a server requests a Fabrikam Webserver certificate from the CA, the CA will place the DNS name of the server in the Subject of the issued certificate. Below are the steps to follow in order to request a certificate based on the Fabrikam WebServer template.

1. Click Start button, then Run, and enter MMC in the Run box and click OK.

2. Click on File from the menu bar and select Add/Remove Snap-in…

3. Select Certificates and click the Add button

4. When prompted for the context that the Certificates MMC should run in select Computer Account, and then click Next, then Finish.

5. Click OK, to close the Add or Remove Snap-ins page.

6. Expand Certificates (Local Computer), right-click on Personal, and select Request New Certificate… from the context menu.

7. This starts the Certificate Enrollment wizard. Click Next to continue.

8. Select the Fabrikam WebServer certificate template, and then click Next to request the certificate.

9. As seen below, the certificate has been successfully requested. Click Finish to close the wizard.

clip_image001

-

Enabling SSL

Now that the certificate has been requested, the next step is to bind the certificate to the default web site in IIS.

To enable SSL for the Web Enrollment site on the CA server:

1. Launch the IIS Manager MMC located in Administrative Tools.

2. Expand the server name, then Sites, and then select Default Web Site.

clip_image002

3. In the Actions menu, select Bindings…

4. The Site Bindings settings will open. Click Add…

clip_image003

5. Select https for Type, and select the appropriate certificate from the SSL certificate drop down. Review the settings, and click OK.

clip_image004

6. Click Close to commit the changes to IIS. The selected server authentication certificate is now bound to port 443 on the IIS server.

clip_image005

-

The Web Enrollment website is now configured to support HTTP over SSL connections via the fully qualified domain name. Since the site is accessed via FQDN, the server, in this example https://fabca01.fabrikam.com, must be added to the list of trusted sites in Internet Explorer of clients that will attempt to access this page. This is so that so that user credentials are automatically passed to the Web Enrollment site. For domain clients, this can be done via Group Policy (see Site to Zone Assignment List policy).

-

Key Archival

Next, we’ll look at setting up Key Archival. There are two parts for setting up Key Archival. The first is designating a Key Recovery Agent for the CA. The second is configuring the Certificate Template for archival which we touched on in the previous part, Configuring Certificate Templates.

Key Archival is important for certificates that are used for encryption. If a user’s encryption private key is lost for some reason, any encrypted data can be recovered by extracting the archived private key from the CA database and returned to the user.

-

Designating a Key Recover Agent (KRA)

In the previous part, we configured the CA to issue KRA certificates. Specifically, we added the default KRA template to the list of certificate templates available on the CA, and set the permission on template to allow members of the Fabrikam KRA security group enroll. The next step is to have at least one member of that group request the KRA certificate.

The user, Magnus Hedlund, is a member of the Fabrikam KRA group. Here’s how he’d request a KRA certificate.

1. Connect to the Web Enrollment site and select Request a certificate from the Web Enrollment webpage.

clip_image006

2. Select Create and submit a request to this CA.

3. From the Certificate Template drop-down, select Key Recovery Agent. Magnus should also make sure the option Mark keys as exportable is selected, but the rest of the default settings can be accepted.

4. Set the friendly name to KRA Cert, and click Submit.

5. The default Key Recovery Agent template is configured to require Certificate Manager approval (on the Request Handling tab), meaning that a Certificate Manager (a local Administrator on the server, by default) must manually issue the certificate. As such, Magnus will see a message stating that his request is in a pending state. Magnus then emails the Certificate Manager to get the request approved.

6. The Certificate Manger launches the Certificate Services MMC, selects Pending Requests, and locates Magnus’ request. She then right-clicks on the request and selects All Tasks from the context menu and then selects Issue.

7. In order to retrieve his issued certificate, Magnus must returns to the Web Enrollment site. This time he must select View the status of a pending certificate request. REQUIRED: Magnus must reconnect to the site using the same client he used to submit the request. The Web Enrollment pages use a cookie to record pending requests.

8. Magnus then clicks on his request that is identified by the date and time that it was submitted.

9. Magnus then has a link to Install this certificate.

10. Magnus is then presented with a Potential Scripting Violation error asking if the certificate should be added to the certificate store He clicks Yes to acknowledge the warning.

clip_image007

The Certificate is then successfully installed.

User’s with Key Recovery Agent certificates should take care to protect their certificates and keys. One way of doing that is exporting the KRA certificate and private key to a PFX file – deleting the private key stored on the client – and keeping that password protected file in a safe location. The KRA certificate and private key can then be imported as needed.

To do this, Magnus follows these steps:

1. Open the Certificates MMC targeted to his user account (Certmgr.msc).

2. Expand Personal, then Certificates. Locate the KRA Cert, and right-click on it. Select Export from the context menu.

3. This launches the Certificate Export Wizard. Click Next to continue.

4. On the Export Private Key page of the wizard, select Yes, export the private key, and click Next.

5. On the Export File Format page, select Delete the private key if the export is successful and make sure all the other options are deselected. Click Next.

6. Enter a password to secure the Private Key, and click Next.

7. On the File to Export page, click Browse….

8. Browse to a secure location in the file system, give the PFX file a name, and click Save.

9. Click Next on the File to Export page.

10. Click Finish to complete the export.

11. He is then prompted that the export was successful, and clicks OK.

In a high security setting, one option may be to save the PFX file to removable media, and then secure that media in a locked safe until it is needed. Why are such measures necessary? Well, they may not be; it totally depends on your environment. What is important to realize is that Key Recover Agents can decrypt the encrypted key blob for any user with an archived key. The CA’s design tries to mitigate this risk somewhat by requiring a Certificate Manager to actually export the encrypted key blob from the CA database. A Key Recovery Agent can only decrypted the exported key blob, but he can’t actually export the key blob.

-

Enabling Key Archival

Now that we actually have a Key Recovery Agent published in Active Directory (any KRA certificate issued by the CA is published to the CN=KRA container in Active Directory), we can proceed to enable Key Archival on the CA.

To enable Key Archival:

1. Open the Certificate Services MMC. Right-click on the name of the CA in the tree-view pane and then select Properties from the context menu.

clip_image008

2. Select the Recovery Agents tab, and select Archive the key. In this case, we only have one Key Recovery Agent, so we’ll leave Number of recovery key agents to use at the default of 1. Click Add… to add the KRA certificate to the CA.

clip_image009

3. Select the appropriate KRA Certificate, and click OK.

clip_image010

4. Click OK to close the properties and commit the changes we’ve made to the CA.

clip_image011

5. When prompted to restart Certificate Services, click Yes.

clip_image012

Key archival is now enabled on the CA.

Additional information on the mechanics of Key Archival is available here: http://blogs.technet.com/pki/archive/2009/08/07/understanding-key-archival.aspx

-

Conclusion

And that’s it for this part of the series. Today, we configured the IIS server hosting our Web Enrollment pages to use SSL when serving the site. We also configured our CA with a Key Recovery Agent to enable Key Archival. Neither of these steps are required in order for the CA to issue certificates, but setting up the features properly will increase the usefulness of your PKI.

In the final segment in this series, I will cover Disaster Recovery Scenarios.

Chris "Ol’ Dusty" Delay

Next part: (2012-09-12) Designing And Implementing A PKI (Part 5)

————————————————————————————————————————————————————————————————–

-

You can also get DOCX, XPS and PDF versions of the articles/posts using the following links:

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Certificate Services (ADCS), Blog Post Series, Design Guides | 2 Comments »

(2012-09-12) Designing And Implementing A PKI (Part 3)

Posted by Jorge on 2012-09-12


In the past I posted a blog containing information about designing your PKI infrastructure. That blog post can be found here.

For a PKI project that I’m working on I wanted to refresh my mind about Microsoft PKI technologies. I found these great articles/posts on the ASKDS blog providing information/guidelines about designing a PKI infrastructure. Because this stuff is SO GOOD, reposted everything here also. Of course the credits of all these posts go to the original writers from ASKDS. Also make sure to read all the comments in the original source as those have not been copied. The information in the comments is also quite useful!

Have I already said, this stuff is quite good! Smile

————————————————————————————————————————————————————————————————–

ORIGINAL SOURCE: Designing and Implementing a PKI: Part III Certificate Templates

Designing and Implementing a PKI: Part III Certificate Templates

Previous part: (2012-09-12) Designing And Implementing A PKI (Part 2)

-

Chris here again. In this segment I will be covering setting up certificate templates on the newly created CA hierarchy. Enterprise Certification Authorities (CAs), as well as clients, utilize what are called certificate templates. Certificate templates contain properties that would be common to all certificates issued by the CA based on that template. Windows includes several predefined templates, but Administrators also have the ability to create their own templates specific for their enterprise. When requesting a certificate, a client can just specify the template name in the request and the CA will build the certificate based upon the requestor’s information in Active Directory and the properties defined in the template.

Certificate templates are also used to define the enrollment policy on the CA. First, an Enterprise CA can only issue certificates based upon the templates it is configure to use. For example, if the CorpUserEmail template is not available on the CA then the CA cannot issue certificates based on that template. Second, permissions set on the certificate template’s Active Directory object determine whether or not a user or computer is permitted to request a certificate based on that template. If a user does not have Enroll permissions on a particular template, the CA will deny any request submitted by the user for a certificate based on that template.

As the Windows Server operating system has evolved over the last ten years, so has the concept of the certificate template. Currently, there are three versions of templates:

Version 1 templates were introduced in Windows 2000, and can be used by Windows 2000, Windows Server 2003 (R2), and Windows Server 2008 (R2) Enterprise CAs. Version 1 templates Active Directory objects are created the first time an Enterprise CA is created in the forest. These templates were designed to reflect the most common scenarios for digital certificates in the Enterprise. Unfortunately, if you don’t like the settings we selected you’re pretty much out of luck. Creating new v1 templates, or editing the existing templates, is not supported. The only customization supported is to the permissions on the template.

Version 2 templates were introduced in Windows Server 2003 and are a vast improvement over v1 templates. First and foremost, v2 templates can be modified by an Enterprise Admin. In addition, the Admin can duplicate an existing v1 or v2 template to create a new v2 template, and then customize the result. Finally, v2 templates expose a larger number of properties that can be configured, and also expose some controls to take advantage of some other new features introduced in Windows Server 2003. One of these features, for example, is key archival. Version 2 templates can be used by Windows Server 2003 and Windows Server 2008 Enterprise or Datacenter Editions. On Windows Server 2008 R2, v2 templates can be used by a CA installed on Standard, Enterprise, Datacenter, Foundation and Server Core Editions.

Version 3 templates were introduced in Windows Server 2008. Version 3 templates have all the features of a version 2 template with two major additions. First, v3 templates support the use of Crypto Next Generation (CNG) providers, which means that the certificates support Suite B algorithms based on Elliptical Curve Cryptography (ECC). Second, v3 templates have a setting that instructs Windows to grant the Network Service account access to the private key created on the requesting computer. This is great for those certificates that will be used by applications or services that run as Network Service rather than Local System. Version 3 templates are supported by CAs installed on Windows Server 2008 Enterprise and Datacenter Editions. They are also supported by CAs installed on Windows Server 2008 R2 Standard, Enterprise, Datacenter, Foundation and Server Core Editions.

For a complete table of Windows Server SKU and the features supported by it, check out this blog post by the Windows PKI development team.

-

Deploying Certificate Templates

For the purpose of example, I am going to use a fictional company called Fabrikam. The diligent IT staff at Fabrikam have done their research, performed some testing, consulted the auguries, and they’ve determined what types of certificates they need to issue to meet the specified business needs. The next step is to look at what templates are available that they can use out of the box and which ones they need to modify to suit their purposes.

Here’s a quick overview of what Fabrikam determined:

CA Issuance: Domain Controller Authentication, Web Server, and User certificates
Key Archival: The private keys for User certificates should be archived
Doman Controller Authentication template: No additional requirements
Web Server template:

· A version 2 template must be created from the default Web Server template.

· The security group Fabrikam Web Servers should have Enroll permissions.

· The Subject name must contain the DNS name of the web server, and should be provided automatically.

User Certificate Template:

· A version 2 template must be created from the default User template

· Key Archival must be implemented for the template

-

Certificate Templates Setup

Fabrikam has decided that they need to deploy the following certificate templates: Domain Controller Authentication, Web Server, and User. In addition, the fact that Key Archival is to be enabled for the User template means that the CA should also be configured to issue certificates based on the Key Recovery Agent template (Actually, this is not a requirement if there is another Windows Enterprise CA in environment that is configured to issue Key Recovery Agent certificates, and is trusted to do so.)

Let’s assume that the PKI hierarchy has been set up and is functional. The next step is to configure the certificate templates. Let’s check the configuration of the templates before deploying them.

To manage the certificate templates, you use the Certificate Templates MMC snap-in. In the Certificate Services MMC snap-in, right-click on the Certificate Templates folder and select Manage from the context menu.

clip_image001

-

In the view pane of the Certificate Templates snap-in you’ll see all the certificate templates available in Active Directory. If you locate the Domain Controller Authentication template and double-click on it, you’ll see the properties available for that template. Our fictional IT staff has already reviewed the settings and determined that no changes need to be made, so we’ll just click Cancel, here.

clip_image002

-

Next, locate the Web Server template. The default Web Server template already meets the current requirements that arose from an analysis of business needs. However, to allow for future changes Fabrikam has decided that they need to duplicate this default template and create a v2 template.

clip_image003

-

To duplicate the existing Web Server template and create Version 2 template:

1. I right click on the Web Server template and select Duplicate Template from the context menu.
clip_image004

-
Fabrikam still has a lot of Windows Server 2003 servers and Windows XP workstations (But they are steadily upgrading. No, really! They are!! Trust me! Sigh.) This means that we can’t use the latest and greatest v3 templates available on our Windows Server 2008 CA. We’ll have to specify that we’re creating a template for Windows 2003 Server, Enterprise Edition which will create a v2 certificate template.
clip_image005

-

2. We’ll give a new name to the template: Fabrikam WebServer.
clip_image006

-

3. Clients within Fabrikam will connect to the web servers via the server’s DNS name. This means that the requesting server’s fully qualified DNS name must be in the Subject of the certificate it receives. To meet this requirement, click on the Subject Name tab and select Build from this Active Directory information. For the Subject Name Format, select DNS Name. Finally, deselect all of the check boxes under Include this information in the alternate Subject name.
clip_image007

-

Now that the new template is configured per the specified requirements, we need to set the security. The computer account for a particular web server will be the principal enrolling for the Fabrikam WebServer template, so we have to make sure that all the web server computer accounts have Enroll permission on the new template. Fabrikam, luckily, has a Security Group containing all of their web servers called, oddly enough, Fabrikam Web Servers. We can simply grant the necessary permissions to that group.

1. In the template properties, elect the Security tab, and click Add…

2. Enter the group name (Fabrikam Web Servers) and click the Check Names button.

3. After the name of the security group is resolved, click OK.

4. Grant the group Enroll permission.
The permissions in the security tab should like this when these changes are complete.
clip_image008

-
Once all the necessary changes have been made, click Ok to commit the new template and save it to Active Directory. The Fabrikam WebServer template is now ready to be added to the CA.

User Certificate Template

We’ll use essentially the same process to duplicate the default User template and modify the resulting v2 template to suit Fabrikam’s requirements.

Just as with the default WebServer, we’ll duplicate the existing User template to create the custom v2 template. We need to do this because the default User template is a v1 template, so its properties cannot be modified. One of our requirements is to enable Key Archival which requires configuring a setting in the template, so in order to do this a v2 template is required.

To create and configure our new User template:

1. Select the User template, right click on it, and select Duplicate Template from the context menu.
clip_image009

-

2. Select Windows 2003 Server, Enterprise Edition to create a v2 template.
clip_image010

-

3. Change the Template Display name to Fabrikam User.
clip_image011

-

4. Navigate to the Request Handling Tab, and select Archive subject’s encryption private key to enable key archival for this template.
clip_image012

-

5. Next, set permissions on the new template. Domain Users will already have Enroll permission, but since this certificate will be deployed via user Autoenrollment, Domain Users will also require Autoenroll permission. The permissions, when set properly, should look like this:
clip_image013

-
Once all the necessary changes have been made, click Ok to commit the new template and save it to Active Directory. The Fabrikam User template is now ready to be added to the CA.

-

Key Recovery Agent Certificate Template

Although this template was not mentioned as one of Fabrikam’s requirements, it is a requirement to issue at least one Key Recovery Agent certificate to support Key Archival. This step is only necessary if there is not another Windows Enterprise CA configured to issue certificates based on the Key Recovery Agent template.

For this example, however, let’s assume that there is not and go ahead and configure the Key Recovery Agent template. The only setting that requires modification is the permissions. We’ll assign enroll permissions to the Fabrikam KRA security group so that members of that group can enroll for a Key Recovery Agent certificate.

1. Open up the Key Recovery Agent certificate template by double-clicking on it and selecting the Security tab. I click Add…

2. Enter the name Fabrikam KRA and click the Check Names button.

3. After the name of the security group is resolved, click OK.

4. Check the Enroll permission.

-

Configuring the CA to issue certificates

To configure the CA to issue the desired certificate templates, I right-click on the Certificate Templates folder, select New, then select Certificate Templates to Issue from the context menu.

clip_image014

-

Then I select the certificate templates I wish to issue, by holding down the control key and selecting multiple templates, and then clicking OK.

clip_image015

-

This CA can now issue certificates based on the selected certificated templates.

clip_image016

-

Conclusion

That’s really all there is to it. While in this segment we only modified a few properties of our templates, in the vast majority of cases there should be no need for making extreme changes. The default templates should be sufficient for most implementations, and the changes we made were more to ease certificate deployment than actually create truly custom templates. Perhaps in a later blog post we’ll cover some of the more esoteric settings. However, this shouldn’t stop you from exploring on your own using the online help.

In Part IV of this series we’ll cover implementing Web Enrollment and Key Archival.

Next part: (2012-09-12) Designing And Implementing A PKI (Part 4)

————————————————————————————————————————————————————————————————–

-

You can also get DOCX, XPS and PDF versions of the articles/posts using the following links:

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Certificate Services (ADCS), Blog Post Series, Design Guides | 2 Comments »

 
%d bloggers like this: