First published on TechNet on Jan 07, 2014
Hello all, my name is Jesse Esquivel and I’m a platforms PFE with one of my specialty’s being security/PKI. I’ve been working with PKI in the Department of Defense (DoD) and Federal spaces for the last 7 years, designing, installing, upgrading, and troubleshooting both DoD and Microsoft PKI certificate services as well as certificate validation server infrastructures (OCSP, CRL). Revocation checking is one of the key components of PKI. Traditionally it can be done by fetching certificate revocation lists (CRLs) that are published in LDAP or HTTP or by using a newer http method dubbed Online Certificate Status Protocol (OCSP). OCSP is a lightweight http protocol that can potentially be faster and more efficient than downloading a traditional CRL. An OCSP responder can be configured to download CRLs and provide digitally signed real time certificate revocation status responses to clients based on a given certificate authority’s CRL.
In the DoD, it’s a requirement for each entity to host their own internal “CRL/OCSP” cache of the DoD PKIs CRLs. This requirement has been around for some time and is in place for a couple of reasons. The DoD CRLs can become quite large and cause applications and services to freeze or become unresponsive while a given system is downloading a CRL. Another reason is that the DoD’s revocation status infrastructure can come under heavy load at peak times and time outs to the service (both crl and ocsp) may occur. Having an internal crl/ocsp cache (or responder) can also help in situations where you have a potential WAN outage, as the responder will still be able to provide revocation status locally for the life of the CRLs it has.
Today I’m writing to you about a pretty important milestone for us as well as most people in IT working in these spaces. Microsoft’ Online Certificate Status Protocol or “OCSP” responder server role was certified by the Joint Interoperability Test Command (JITC) on 08NOV2013. This certification covers the OCSP responder role on both Windows Server 2008 R2 and Windows Server 2012. For more information on the certification process please contact JITC. Our certification status is now listed with the other vendors on JITCs status page here:
http://jitc.fhu.disa.mil/pki/pke_lab/ocsp_testing/ocsp_testing.html
What this means for our DoD customers is that they will be able to leverage their existing investment in the Windows Server platform to provide certificate revocation checking via our OCSP Responder role. Customers can now use Windows Server 2008 R2/2012 to provide an internal OCSP responder service for their infrastructures as required by the Defense Information Systems Agency (DISA). A couple of things to note here:
- A Microsoft CA is required to issue the responder its OCSP Response signing certificate(s).
- Third party X.509 compliant OCSP clients can be pointed to a Microsoft OCSP responder for certificate revocation checking.
- Hardware Security Modules (such as nCipher, Thales) can be used with the OCSP responder role (HSMs are used to encapsulate and protect a private key at a hardware assurance level – usually FIPS 140-2 or 3 certified).
- OCSP responders can scale for load by putting multiple responders in an NLB or a hardware load balanced pool.
- Revocation configurations can be scripted on one responder, additional responders can be added to a Windows OCSP responder array to have their configuration synced.
- OCSP responder role is IIS based so it can also be used to host CRLs via IIS if desired
The official JITC certification letter can be downloaded from the following URL, however a DoD Common Access Card is required:
https://jit.fhu.disa.mil/products/2014/11/20131129501.pdf
So how do we get started then in setting this up for some testing ? First off you need a Windows PKI and an OCSP responder installed . The links I provided are excellent posts on how to get these boxes checked. The OCSP responder installation is an excellent resource that covers load balancing multiple responders and configuring custom OCSP URIs via group policy (more on that later). Now that we have our PKI and our OCSP responder installed let’s get down to business! Remember test first !
Configuring the Responder to provide revocation information for DoD Certificates
Configuring the OCSP responder with a full load out of DoD revocation configurations can be cumbersome, time consuming, and frankly a little monotonous. Enter PowerShell. Here is a function I’ve written that can be used in your custom code/scripts that will configure our OCSP responder for DoD use. Grab the zip file and extract it on the responder, ensure all of the certificates are in the same directory as the script:
The script is located here. Open the script for editing, I like to use the PowerShell ISE; it’s much more intuitive and easier on the eyes. If you don’t have it, add it quickly with the add-windowsfeature powershell-ise cmdlet (you will need to run import-module servermanager in 2008 R2). You need to modify lines 20 and 22 to reflect your environment. We need to provide the name of the OCSP response signing template, and the output of the certutil –cainfo command for your CA.
For the OCSP Response Signing template value, ensure you grab the template name and not the template display name. Open your certificate templates snap-in and view the properties of the template:
Login to the certificate authority and Issue the certutil –cainfo command to get the string needed for the CAConfig$ variable in line 23. The output is as follows:
The value for the variable must be in the format, so for this example it would be: “WIN-RP6C8JRDRLB.treyresearch.com\treyresearch-CA” So our script now reflects the following:
Now that we’re all set up, let’s take a look at the Online Responder MMC snap-in. Note there are no revocation configurations:
Let’s execute the script to configure the responder for its OCSP response signing certificate enrollments, import the DoD CA certificates, set the CRL fetch URLs, and configure the other revocation provider parameters (don’t forget to check your execution policy on the server).
Back to the Online Responder snap-in let’s refresh the revocation configurations. We should see all of the CA certificates that were specified in the function calls, and that the responder has auto enrolled for an OSCP response signing certificate:
You can also check the status of the revocation configurations from the main page, hopefully we have a status of “working.”
Now that you have your first responder configured for all of the DoD CAs, it’s as easy as adding additional responders into an array and they will sync their configuration from the array controller!
Configuring OCSP Logging for Client and Server
For the Responder side we’ve released a hotfix for Server 2008 R2 SP1 and Server 2012 that adds additional logging to the system event log when a client requests revocation status of a certificate via OCSP – specifically we’ve added the certificate serial number, Issuer CA Name, and revocation status in a more consumable format to event ID 5125. Grab the hotfix here and install it on your responders (a reboot is required):
http://support.microsoft.com/kb/2891347/en-us
Additionally if you want to log requests submitted to the responder you must turn it on in the auditing tab of the online responder properties:
Additionally you need to turn on auditing for certification services in the local security policy as well:
To enable CryptoAPI logging on the client side we can enable the CAPI2 log in the event viewer under the following path: Applications and Services Logs | Microsoft | Windows | CAPI2 | Operational
Checking Revocation Status against the Responder
Now that we have our logging setup and configured let’s see about testing revocation status of a DoD certificate against this responder! There are two options on how to tell Windows to now go to your internal responder for revocation status of certificates issued by these DoD CAs:
1. Configure custom OCSP URIs in group policy. Essentially we are adding the OCSP URI to each of the DoD certificates that are specified in group policy, likely most folks in the space are already deploying the DoD trust chain via group policy, so we just need to crack open the GPO and add the URI to each of the CA certificates.
2. If you are using a third party OCSP client all you need to do is reconfigure the OCSP URI in that client to point to your new responder. Hint: you can use the Root CA or Sub-CA’s certificate as the OCSP signing certificate in your OCSP configuration, you don’t want to add each individual OCSP signing certificate into your config – especially since OCSP signing certificates have a shorter validity period than most.
Finally let’s check revocation status of a DoD leaf certificate. For this use case scenario I’ll use the certutil -verify command to do a revocation check on my signing certificate. Note the serial number of the certificate.
On the client you can review the result of the revocation check in the CAPI2 log, note the location is “ wire ,” the URL reflects our OCSP responder, and the process name that made the call to CryptoAPI for the revocation check. Remember a revocation status checking involves checking every certificate in the leaf certificates chain. In this case we see a revocation check for my leaf certificate and a revocation check for the Issuing CAs certificate.
On the responder end we have two Event ID 5125 entries that log the OCSP requests in the security event log. Leaf certificate check (note the serial number):
And the CA Certificate revocation check:
Well folks, that about wraps it up for this post; hopefully this enables you to quickly and efficiently evaluate and test the OCSP responder role in your labs!
Script can be located at https://github.com/JesseEsquivel/PKI
Jesse Esquivel
Disclaimer
The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.