> ## Documentation Index
> Fetch the complete documentation index at: https://docs.futurex.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Configure Online Responder
> Procedural guide to configure the Online Responder (OCSP) role on the OCSP server and assign the HSM-backed signing certificate.
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
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`.
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.
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.
On the **Confirmation** page, select **\[ Configure ]**.
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.
Open an elevated PowerShell prompt and create the CertEnroll folder:
```powershell expandable lines wrap title="PowerShell" theme={null} theme={null}
New-Item -Path "C:\CertEnroll" -ItemType Directory
```
Create an IIS virtual directory pointing to the CertEnroll folder:
```powershell expandable lines wrap title="PowerShell" theme={null} theme={null}
New-WebVirtualDirectory -Site "Default Web Site" -Name "CertEnroll" -PhysicalPath "C:\CertEnroll"
```
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.
On the CA server, locate the CRL and CA certificate files:
```powershell expandable lines wrap title="PowerShell" theme={null} theme={null}
dir "C:\Windows\System32\CertSrv\CertEnroll\*"
```
Note the filenames of the `.crl` and `.crt` files.
Copy the following files from the CA server to `C:\CertEnroll\` on the OCSP server:
* `_.crt` — the CA certificate file
* `.crl` — the base CRL file
Replace `` and `` with the actual values from your environment.
Verify the files are present on the OCSP server:
```powershell theme={null}
dir "C:\CertEnroll\*"
```
Both the `.crl` and `.crt` files should be listed.
Import the CA certificate into the Trusted Root Certification Authorities store:
```powershell theme={null}
certutil -addstore Root "C:\CertEnroll\_.crt"
```
Replace the filename with your actual CA certificate filename.
The output should confirm the certificate was added successfully:
```Text theme={null}
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.
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:**
```powershell theme={null}
@"
[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):**
```powershell theme={null}
@"
[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**.
Generate the certificate request:
```powershell theme={null}
certreq -new C:\ocsp_request.inf C:\ocsp_request.req
```
Verify the request file was created:
```powershell expandable lines wrap title="PowerShell" theme={null} theme={null}
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
Copy `C:\ocsp_request.req` from the OCSP server to the CA server.
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`.
In the console tree, select **Pending Requests**. Right-click the submitted request and
select **All Tasks** > **Issue**.
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`.
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.
On the OCSP server, open an elevated PowerShell prompt and create a scheduled task that
submits the certificate request as SYSTEM:
```powershell theme={null}
$action = New-ScheduledTaskAction -Execute "cmd.exe" -Argument '/c certreq -submit -config "\" -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:
* `` — the fully qualified domain name of your CA server (e.g.
`ADCS.lab.local`).
* `` — 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`.
Run the scheduled task and wait for it to complete:
```powershell theme={null}
Remove-Item C:\certreq_output.txt -ErrorAction SilentlyContinue
Start-ScheduledTask -TaskName "CertReqSubmit"
sleep 30
Get-Content C:\certreq_output.txt
```
The output should contain:
```Text theme={null}
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:
```powershell theme={null}
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:
```powershell theme={null}
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:
```powershell theme={null}
Remove-Item C:\ocsp_response.rsp -ErrorAction SilentlyContinue
```
Clean up the scheduled task:
```powershell theme={null}
Unregister-ScheduledTask -TaskName "CertReqSubmit" -Confirm:$false
```
#### Install the Certificate
Applies to both Standalone CA and Enterprise CA. Run these on the OCSP server.
Install the certificate into the machine personal store:
```powershell theme={null}
certutil -addstore My C:\ocsp_response.cer
```
Find the serial number of the issued certificate:
```powershell theme={null}
certutil -dump C:\ocsp_response.cer | findstr "Serial Number"
```
Link the certificate to the HSM private key:
```powershell theme={null}
certutil -repairstore My ""
```
Replace `` with the value from the previous step.
Verify the certificate was installed and linked to the HSM key:
```powershell theme={null}
certutil -store My
```
Locate the OCSP Signing certificate in the output and confirm the following fields are
present:
```Text theme={null}
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
Open the **Online Responder Management** console:
```powershell expandable lines wrap title="Command Prompt" theme={null} theme={null}
ocsp.msc
```
In the console tree, right-click **Revocation Configuration** and select **Add Revocation
Configuration**.
On the **Getting Started** page, select **\[ Next > ]**.
On the **Name the Revocation Configuration** page, enter a name for the configuration. It is
recommended to include the CA name. Select **\[ Next > ]**.
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 > ]**.
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 > ]**.
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:///CertEnroll/.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:///CertEnroll/.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**.
In the **Online Responder Management** console, expand **Array Configuration** and select
your OCSP server.
In the center pane, right-click the Revocation Configuration you created and select **Assign
Signing Certificate**.
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
In the **Online Responder Management** console, right-click **Array Configuration** and
select **Refresh Revocation Data**.
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`).
Verify the CA service is reachable from the OCSP server:
```powershell theme={null}
certutil -ping -config "\"
```
Replace `` with the fully qualified domain name of your CA server and `` with your CA
name (e.g., `Futurex-CA`).
The output should confirm the CA is alive:
```Text theme={null}
CertUtil: -ping command completed successfully.
```