Skip to main content
Configure the Online Responder (OCSP) role on the OCSP server and assign the HSM-backed signing certificate so the responder can sign revocation responses using a key protected in CryptoHub.

​
Step 1: Configure the AD CS Configuration Wizard for Online Responder

1
In Server Manager, select the flag icon to the left of Manage and select Configure Active Directory Certificate Services on the destination server.
If the notification flag does not appear, the Online Responder role service may already be activated. In this case, proceed directly to Step 6: Configure the Revocation Configuration by opening ocsp.msc.
2
On the Credentials page, verify your credentials meet the requirements and select [ Next ].
Enterprise CA only. Configure the Online Responder while logged in as a domain administrator (for example, LAB\Administrator). Local administrator credentials are not sufficient.
3
On the Role Services page, check Online Responder only and select [ Next ].
Do not check Certification Authority on the OCSP server. The CA role is only installed on the CA server.
4
On the Confirmation page, select [ Configure ].
5
On the Results page, select [ Close ].

​
Step 2: Set Up CertEnroll on the OCSP Server

Standalone CA only. Skip this step if you are using an Enterprise CA. On an Enterprise CA, the CRL is served from the CA server’s CertEnroll directory (see Serve the CRL via IIS). On a dedicated Standalone OCSP server without the CA role, the CertEnroll folder is not created automatically and must be created manually.
1
Open an elevated PowerShell prompt and create the CertEnroll folder:
PowerShell
    New-Item -Path "C:\CertEnroll" -ItemType Directory
2
Create an IIS virtual directory pointing to the CertEnroll folder:
PowerShell
    New-WebVirtualDirectory -Site "Default Web Site" -Name "CertEnroll" -PhysicalPath "C:\CertEnroll"
3
Verify the virtual directory was created successfully by opening IIS Manager and confirming that CertEnroll appears under Default Web Site.

​
Step 3: Copy CA Files to the OCSP Server

Standalone CA only. Skip this step if you are using an Enterprise CA.
1
On the CA server, locate the CRL and CA certificate files:
PowerShell
    dir "C:\Windows\System32\CertSrv\CertEnroll\*"
Note the filenames of the .crl and .crt files.
2
Copy the following files from the CA server to C:\CertEnroll\ on the OCSP server:
  • <ServerHostname>_<CAName>.crt — the CA certificate file
  • <CAName>.crl — the base CRL file
Replace <ServerHostname> and <CAName> with the actual values from your environment.
3
Verify the files are present on the OCSP server:
    dir "C:\CertEnroll\*"
Both the .crl and .crt files should be listed.
4
Import the CA certificate into the Trusted Root Certification Authorities store:
    certutil -addstore Root "C:\CertEnroll\<ServerHostname>_<CAName>.crt"
Replace the filename with your actual CA certificate filename.
The output should confirm the certificate was added successfully:
      CertUtil: -addstore command completed successfully.

​
Step 4: Create the OCSP Signing Certificate Request

RSA or ECC. This guide documents both an RSA and an ECC (ECDSA) OCSP signing key. Choose one and use the matching INF below. The choice must be consistent across the INF, the certificate template’s Cryptography tab (Enterprise CA — see Create and Publish the OCSP Response Signing Template), and your test certificate (see Verify the Integration). If you mix them — for example, an ECDSA template with an RSA request — issuance or signing will fail.
1
On the OCSP server, create a new file named ocsp_request.inf by running the matching command in an elevated PowerShell prompt.
The ProviderName value must exactly match the Futurex CNG provider name as it appears in the output of certutil -csplist. Verify this before proceeding.
RSA variant:
    @"
    [Version]
    Signature="`$Windows NT`$"

    [NewRequest]
    Subject = "CN=OCSP Signing"
    KeyAlgorithm = RSA
    KeyLength = 2048
    HashAlgorithm = SHA256
    MachineKeySet = TRUE
    Exportable = FALSE
    RequestType = CMC
    ProviderName = "Futurex FXCL KMES CNG"
    KeyUsageProperty = NCRYPT_ALLOW_SIGNING_FLAG

    [EnhancedKeyUsageExtension]
    OID = 1.3.6.1.5.5.7.3.9

    [Extensions]
    1.3.6.1.5.5.7.48.1.5 = Empty
    "@ | Out-File -FilePath C:\ocsp_request.inf -Encoding ASCII
ECC variant (ECDSA P-384):
    @"
    [Version]
    Signature="`$Windows NT`$"

    [NewRequest]
    Subject = "CN=OCSP Signing"
    KeyAlgorithm = ECDSA_P384
    KeyLength = 384
    HashAlgorithm = SHA384
    MachineKeySet = TRUE
    Exportable = FALSE
    RequestType = CMC
    ProviderName = "Futurex FXCL KMES CNG"
    KeyUsageProperty = NCRYPT_ALLOW_SIGNING_FLAG

    [EnhancedKeyUsageExtension]
    OID = 1.3.6.1.5.5.7.3.9

    [Extensions]
    1.3.6.1.5.5.7.48.1.5 = Empty
    "@ | Out-File -FilePath C:\ocsp_request.inf -Encoding ASCII
ECC key algorithm and key length. Valid CNG ECDSA algorithm names are ECDSA_P256, ECDSA_P384, and ECDSA_P521. The KeyLength must match the curve in the algorithm name: 256 for ECDSA_P256, 384 for ECDSA_P384, 521 for ECDSA_P521. Pair the hash with the curve (SHA256 with P-256, SHA384 with P-384, SHA512 with P-521) so the signature strength is balanced. Adjust all three values together if you choose a different curve.
Enterprise CA. The same INF (RSA or ECC) works for Enterprise CA. Do not add a Subject Alternative Name to the INF — supplying a SAN in the request will result in CERTSRV_E_SUBJECT_DNS_REQUIRED. The request is submitted as the machine account in Step 5: Submit, Issue, and Install the Signing Certificate.
2
Generate the certificate request:
    certreq -new C:\ocsp_request.inf C:\ocsp_request.req
Verify the request file was created:
PowerShell
      Test-Path C:\ocsp_request.req
The output should return True. You should also see Loading Futurex Provider. and CertReq: Request Created in the command output, confirming the key was generated in CryptoHub.

​
Step 5: Submit, Issue, and Install the Signing Certificate

This step differs depending on your CA type:
  • Standalone CA — The request is manually copied to the CA server, approved, and the certificate copied back.
  • Enterprise CA — The request is submitted directly from the OCSP server using a scheduled task running as SYSTEM (the machine account). No file copying or manual approval is required. SYSTEM context is mandatory because the template builds the DNS name from the machine’s AD computer object.

​
Standalone CA

1
Copy C:\ocsp_request.req from the OCSP server to the CA server.
2
On the CA server, open the Certification Authority console (certsrv.msc). Right-click your CA name and select All Tasks > Submit New Request. Browse to and select ocsp_request.req.
3
In the console tree, select Pending Requests. Right-click the submitted request and select All Tasks > Issue.
4
In the console tree, select Issued Certificates. Open the newly issued certificate, go to the Details tab, and select Copy to File. Export the certificate as a DER encoded binary .cer file named ocsp_response.cer.
5
Copy ocsp_response.cer back to the OCSP server, then proceed to Install the Certificate below.

​
Enterprise CA

For Enterprise CA, the certificate request must be submitted as the machine account (SYSTEM) rather than as a domain user. This is required because the Enterprise CA looks up the dNSHostName attribute from the requesting computer’s Active Directory object to populate the DNS Subject Alternative Name — a user account does not have this attribute, and the request will be denied with CERTSRV_E_SUBJECT_DNS_REQUIRED. A Windows scheduled task running as SYSTEM is used to submit the request without requiring interactive tools like PsExec.
1
On the OCSP server, open an elevated PowerShell prompt and create a scheduled task that submits the certificate request as SYSTEM:
    $action = New-ScheduledTaskAction -Execute "cmd.exe" -Argument '/c certreq -submit -config "<CA-Server-FQDN>\<CA-Name>" -attrib "CertificateTemplate:OCSPResponseSigningHSM" C:\ocsp_request.req C:\ocsp_response.cer > C:\certreq_output.txt 2>&1'
    $principal = New-ScheduledTaskPrincipal -UserId "SYSTEM" -RunLevel Highest
    $task = Register-ScheduledTask -TaskName "CertReqSubmit" -Action $action -Principal $principal
Replace the following:
  • <CA-Server-FQDN> — the fully qualified domain name of your CA server (e.g. ADCS.lab.local).
  • <CA-Name> — the name of your CA as shown in certsrv.msc (e.g. Futurex-CA-ECDSA).
The -config flag is required to specify the CA directly using its FQDN, not its IP address. Without it, or if an IP is used, certreq opens an interactive CA-selection popup which has nowhere to appear in the SYSTEM session and causes the task to hang indefinitely with an empty output file.
The -attrib "CertificateTemplate:..." value uses the template’s internal name (no spaces), OCSPResponseSigningHSM, not the display name OCSP Response Signing HSM.
2
Run the scheduled task and wait for it to complete:
    Remove-Item C:\certreq_output.txt -ErrorAction SilentlyContinue
    Start-ScheduledTask -TaskName "CertReqSubmit"
    sleep 30
    Get-Content C:\certreq_output.txt
The output should contain:
      Certificate retrieved(Issued) Issued
Note: the repeated word is expected — (Issued) is the status code returned by certreq and Issued is the CA’s disposition string.If the output is empty after 30 seconds, check whether certreq is still running:
      Get-Process | Where-Object { $_.Name -match "certreq" }
If a certreq process is present, it is hanging. Most likely because the -config value uses an IP instead of an FQDN, or the task already exists from a previous run. Kill the process, unregister the task, and retry with the correct FQDN:
      Stop-Process -Name "certreq" -Force
      Unregister-ScheduledTask -TaskName "CertReqSubmit" -Confirm:$false
If ocsp_response.rsp already exists from a previous run, delete it before retrying:
      Remove-Item C:\ocsp_response.rsp -ErrorAction SilentlyContinue
3
Clean up the scheduled task:
    Unregister-ScheduledTask -TaskName "CertReqSubmit" -Confirm:$false

​
Install the Certificate

Applies to both Standalone CA and Enterprise CA. Run these on the OCSP server.
1
Install the certificate into the machine personal store:
    certutil -addstore My C:\ocsp_response.cer
2
Find the serial number of the issued certificate:
    certutil -dump C:\ocsp_response.cer | findstr "Serial Number"
3
Link the certificate to the HSM private key:
    certutil -repairstore My "<Serial_Number>"
Replace <Serial_Number> with the value from the previous step.
4
Verify the certificate was installed and linked to the HSM key:
    certutil -store My
Locate the OCSP Signing certificate in the output and confirm the following fields are present:
      Provider = Futurex FXCL KMES CNG
      Private key is NOT exportable
      Signature test passed
If Signature test passed does not appear, the certificate is not properly linked to the HSM key — repeat the certutil -repairstore command and verify again.

​
Step 6: Configure the Revocation Configuration

1
Open the Online Responder Management console:
Command Prompt
    ocsp.msc
2
In the console tree, right-click Revocation Configuration and select Add Revocation Configuration.
3
On the Getting Started page, select [ Next > ].
4
On the Name the Revocation Configuration page, enter a name for the configuration. It is recommended to include the CA name. Select [ Next > ].
5
On the Select CA Certificate Location page:
  • Standalone CA: Select A certificate from the Local certificate store and select [ Next > ], then [ Browse… ] to select your CA certificate from the list.
  • Enterprise CA: Select Select a certificate for an Existing Enterprise CA and select [ Next > ], then [ Browse… ] to select your CA from those published in Active Directory.
Select [ Next > ].
6
On the Select Signing Certificate page, select Manually select a signing certificate.
For both CA types in this guide, the HSM-backed signing certificate was enrolled and installed manually in Step 5: Submit, Issue, and Install the Signing Certificate so that the Futurex CNG provider could be specified. Do not use the wizard’s auto-enroll option — it would attempt to enroll a new key outside the INF workflow and would not use the HSM provider.
Select [ Next > ].
7
On the Revocation Provider page, select [ Provider… ].
An error pop-up may appear saying Element not found. This can be ignored by selecting [ OK ].
  • Standalone CA: Select [ Add ] under Base CRLs and enter your CA’s CRL URL: http://<OCSP-server-FQDN-or-IP>/CertEnroll/<CAName>.crl Then select [ OK ].
  • Enterprise CA: CRL URLs are populated automatically from Active Directory and from the CDP extension. Verify they are correct. The HTTP entry should point to the CA server (e.g. http://<CA-server-IP>/CertEnroll/<CAName>.crl). If an old or incorrect URL is present and the Edit/Delete buttons are unavailable, delete the revocation configuration and recreate it — recreating pulls the current URLs from the updated CA certificate.
Set the Update CRLs at this refresh interval (min) to your organization’s needs. In this example, 15 minutes was used.Select [ OK ] then [ Finish ].

​
Step 7: Assign the Signing Certificate

Applies to both CA types in this guide, because the HSM-backed signing certificate was enrolled manually in Step 5: Submit, Issue, and Install the Signing Certificate.
1
In the Online Responder Management console, expand Array Configuration and select your OCSP server.
2
In the center pane, right-click the Revocation Configuration you created and select Assign Signing Certificate.
3
Select the OCSP signing certificate you installed in Step 5: Submit, Issue, and Install the Signing Certificate and select [ OK ].

​
Step 8: Verify the Configuration

1
In the Online Responder Management console, right-click Array Configuration and select Refresh Revocation Data.
2
Expand Array Configuration and select your OCSP server. In the center pane, verify that the Revocation Configuration Status shows Working (green checkmark) and that a signing certificate is present.
If you see leftover revocation configurations from earlier attempts showing errors (for example, Bad signing certificate on Array controller), delete them. If an old array controller (a previous server name) is listed, remove it as well — your new configuration must appear under the current OCSP server node (e.g. OCSP.lab.local).
3
Verify the CA service is reachable from the OCSP server:
    certutil -ping -config "<CA-Server-FQDN>\<CA-Name>"
Replace <CA-Server-FQDN> with the fully qualified domain name of your CA server and <CA-Name> with your CA name (e.g., Futurex-CA).
The output should confirm the CA is alive:
      CertUtil: -ping command completed successfully.