OCSP Responder Signing Certificate from a Stand Alone CA + Configs


Hello All,

Recently I came across a scenario that required a manually enrolled and assigned OCSP signing certificate for the online responder service and configurations, and wanted to share a couple things on this topic.  So today I’m going to talk about manually requesting an OCSP signing certificate from a stand-alone CA, and some PowerShell snippets to help accelerate testing.  MSFT Stand Alone CAs don’t have the luxury of using certificate templates like an enterprise CA does, so the certificate signing request is created manually with the required parameters on the OCSP responder and then signed by the stand alone CA.  By default if an OCSP responder is setup for auto enrollment against an enterprise CA for its OCSP signing certificate(s), it enrolls for an ocsp signing certificate per revocation configuration, so if you had 10 revocation configurations you would have 10 OCSP response signing certificates etc.  You can view those by opening the certificate store for the online responder service on the machine:

defaultocspsigningcerts_01_14_2017

On the contrary you can use 1 OCSP response signing certificate for all of your revocation configurations.  What’s the use case scenario for this?  One that stands out would be if you wanted to use a Hardware Security Module (HSM) to encapsulate and protect the OCSP response signing key.  Configuring an HSM for 20+ OCSP signing certificates that have a 2 week expiration/rollover can become a very high touch situation.  Using an HSM is out of scope of this article, so you’ll want to work with your HSM vendor to get that installed and integrated if you so choose to use one.

So in this lab scenario I have one Server 2012 R2 OCSP responder, and one Server 2012R2 stand alone CA.  First things first we want to create the certificate signing request on the OCSP responder.  To do that we’ll generate an INF file that has all of the certificate parameters that we need and use the certreq.exe command to generate the request.  This request inf is a good place to start.  I recommend adding the required key size to the INF (highlighted below), otherwise you end up with a 1024 bit RSA key which is considered a weak RSA key.  Notice there are two required OIDs present in the inf, the OCSP signing OID (1.3.6.1.5.5.7.3.9), and the OCSPNOREVCHECK OID (1.3.6.1.5.5.7.48.1.5).  In order for the online responder to use the certificate for OCSP response signing BOTH of these OIDs must be present in its certificate.

ocsprequestinf_01_14_2017

Once we have our inf file ironed out we generate the request with certreq.exe:

createcsr

Now take the request file, in this case “ocsp.req” and get it over to your stand alone CA, which hopefully is an offline CA ; )  Once you have it on the stand alone CA there are a few things to be aware of here.  The first being that in order to include the id-pkix-ocsp-nocheck extension in the issued OCSP response signing certificate you MUST enable this flag on a stand alone CA first.  Enable the flag with the certutil command:

certutil -v -setreg policy\editflags +EDITF_ENABLEOCSPREVNOCHECK

enableocsprevnocheck_01_14_2017

Take note of the old and new values above, values that are enabled are NOT in parenthesis.  Not quite done here yet though!  The registry parameters for the CA are only read-in at service startup, so if you make a registry change it will not take effect until you restart the CA service.  Once the CA service is restarted we can submit the request to the CA and issue the certificate.  Here I’ll just use the UI to submit the request by browsing to the request file, you can of course use certreq to submit the request as well.

submitrequest

Once it’s submitted we can go to pending requests and issue the certificate.

issueocspcert

Now lets go to issued certificates and double click the freshly minted certificate.  Click the details tab and lets make sure we have the required OCSP response signing EKU, and the required id-pkix-ocsp-nocheck extension.  As you can see below both requirements are met!

ocsprevnocheckissued_01_14_17

Now click the copy to file button at the bottom of the details tab, export the certificate out, and get it moved back to the OCSP responder.  Once we have it on the OCSP responder we can install the certificate by again using the certreq command.

acceptonresponder_01_14_17

Now that we have the certificate installed we must give the network service read access to the OCSP response signing certificates private key, this is required as the online responder service runs as the network service identity.  We can do this in the certificate snap-in for the local machines personal store.  Once we are there we can right click on the OCSP response signing certificate and click “manage private keys.”

signingcertprivatekey_01_14_17

Add the network service and give it allow read access.

networkservice_01_14_17

Now that we have the OCSP signing certificate requested, issued, and installed we can move over to configuring the online responder to use this certificate for its revocation configurations.  We can use either the UI to create them, or PowerShell.   Likely you will be creating quite a number of them so you’ll likely want to use PowerShell, but we’ll go through creating one manually for awareness.  So here we go, open the online responder snap-in and right click revocation configuration and click add.  Here I will call this one DoD CA-28.

addrev2_01_14_17

On the next screen it wants the CA certificate that you will be providing OCSP responses for, so I’m going to select import from a file click next and then browse to the DoD CA-28 certificate, then click next.

addrev3_01_14_17

This screen is where we select manual assignment of a signing certificate.

addrev4_01_14_17

On the next screen you’ll likely receive the following error, this is because the online responder has no information on where to fetch the CAs CRL.

addrev5_01_14_17

So we click the provider button and enter in the crl distribution point information.  At the bottom you can tell the responder how frequently to fetch the CRL, this is based on minutes.

addrev6_01_14_17

Once you’ve entered in your information you can click finish.  Now in the snap-in left pane we need to expand array configuration and click on the responder.  In the right pane click on the newly created revocation configuration and click “Assign Signing Certificate.”

addrev7_01_14_17

You should get a Windows Security dialogue box that displays available OCSP signing certificates.  Select your certificate and click OK.  Now to submit a request to the responder and test it.  Here I’m using group policy to assign my OCSP responder URL to the CA certificate that issued my leaf certificate.  I’ll then use certutil -verify to submit an OCSP request to the responder.  We can see the entry generated in the security event log for the request, with a response status of “Good.”

addrev9_01_14_17

Now about those revocation configurations, creating all of those can be cumbersome and not very fun.  If you’re doing some serious testing then you probably want to remove and re-create your revocation configurations multiple times.  Here’s a handy PowerShell snippet that will remove all of your current OCSP revocation configurations.

001
002
003
004
005
006
007
008
009
010
011
012
013
014
015
016
017
018
019
$ocsp = New-Object -ComObject CertAdm.OCSPAdmin                                                                       
$ocsp.GetConfiguration($env:computername, $true)
$rcCount = $ocsp.OCSPCAConfigurationCollection.Count
if($rcCount -gt 0)
{
    Write-Host “Deleting” $rcCount “Revocation Configuration entries…”
    $entries = $ocsp.OCSPCAConfigurationCollection | select Identifier
    foreach ($e in $entries) 
    {
        Write-Host “`tDeleting” $e.Identifier
        $ocsp.OCSPCAConfigurationCollection.DeleteCAConfiguration($e.Identifier)
    }
    $ocsp.SetConfiguration($env:computername, $true)
    Write-Host “All entries deleted.”
}
else
{
    Write-Host “No entries found.”
}

 

I also modified the existing OCSP responder function to create the revocation configurations with a manually assigned signing certificate.  Here are the changes you’ll want to make if you want to do this.  Comment out the following lines and replace them with the ones below it.  Be sure to modify the Subject name value to match the Subject value in your OCSP response signing certificate.

001
002
003
004
005
006
007
008
#if using autoenrollment Modify the following two values to match your environment
#$OCSPSigningTemplate = “ProsewareAzure-OCSPResponseSigning”
#Get the certificate template name from the certificate templates snap-in
#login to your MSFT issuing CA and issue the certutil -cainfo command to get the following values for the next line in this format: <DNS NAME>\<CA Name>
#$CACOnfig = “proazureca01.proseware.com\Proseware Azure Subordinate Certificate Authority”
#if you want to manually assign a signing certificate use these instead of above, enter the subject value of your signing certificate
$signingCert = dir cert:\LocalMachine\My | where {$_.Subject -eq “CN=PROAZURERD01”}
$signingCert = $SigningCert.GetRawCertData()

 

Also we want to comment out the lines that configure auto enrollment and replace them with the manual assignment configs.  You can see there are 3 signing flags that we are using to manually assign the OCSP signing certificate, the signing flags are documented on msdn here.

001
002
003
004
005
006
007
008
009
010
011
012
#OCSP Signing Cert Autoenrollment settings
#$NewConfig.SigningFlags = 0x294
#$NewConfig.CAConfig = $CAConfig
#$NewConfig.SigningCertificateTemplate = $OCSPSigningTemplate                                                          
     
#OCSP Signing Cert manual assignment settings <———-
#SigningFlags for manual assignment – if you have enrolled an OCSP signing certificate manually
#OCSP_SF_SILENT 0x001
#OCSP_SF_MANUAL_ASSIGN_SIGNINGCERT 0x020
#OCSP_SF_RESPONDER_ID_NAME 0x080
$NewConfig.SigningFlags = 0xa1 
$newConfig.SigningCertificate = $signingCert

 

I like to use the Responder ID name flag instead of the responder ID key hash flag (the RFC dictates that an OCSP response must have one of the two in it).  This flag corresponds to the following setting for a revocation configuration:

addrev10_01_14_17

I like to use the subject ID flag because it can be handy to easily identify the responder that sent a response when looking at logs or network captures.  Once you’ve made these changes you can execute the function to create your revocation configs.  You should end up with a bunch that say “manual assignment” under revocation configurations, and those configurations should be ready to service requests.  I hope this helps clear things up for using a manually enrolled OCSP signing certificate.

See you next time!

Jesse


Comments (1)

Skip to main content