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 8 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.
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 Configure CA Server for
OCSP, “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.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:Note the filenames of the
PowerShell
.crl and .crt files.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
<ServerHostname> and <CAName> with the actual values from your environment.Step 4: Create the OCSP Signing Certificate Request
This step applies to both CA types. The same INF file is used to generate the request and the
HSM-backed key, regardless of how the request is later submitted (manual approval for
Standalone, machine-account submission for Enterprise).
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), and your test certificate. If you mix
them — for example, an ECDSA template with an RSA request — issuance or signing will fail.
CryptoHub provider support for ECC is the key unknown to validate. The Windows-side INF
and template syntax below are correct, but ECC signing only works if the Futurex FXCL KMES
CNG provider advertises the chosen ECDSA curve to Windows. Before relying on the ECC path,
confirm the provider supports it (see the verification note at the end of this step). If the
provider does not advertise the curve, key generation or the
Signature test in Step 6 will
fail, and you should fall back to the RSA path.On the OCSP server, create a new file named ECC variant (ECDSA P-384):
ocsp_request.inf by running the matching
command in an elevated PowerShell prompt.RSA variant: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.The
ProviderName value must exactly match the Futurex CNG provider name as it appears in
the output of certutil -csplist. Verify this before proceeding.Enterprise CA. The same INF (RSA or ECC) works for Enterprise CA. Do not add a
Subject Alternative Name to the INF — the CA builds the subject and DNS SAN from Active
Directory (configured on the template’s Subject Name tab). Supplying a SAN in the request,
or submitting as a user account, will result in
CERTSRV_E_SUBJECT_DNS_REQUIRED. The
request is submitted as the machine account in Step 6.For ECC, the template’s Cryptography tab must also be set to an ECDSA algorithm — see
“Create and Publish the OCSP Response Signing Template,” which includes the ECC settings.Step 6: 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
Standalone CA only. Skip to Enterprise CA below if you are using an Enterprise CA.
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.Enterprise CA
Enterprise CA only. Skip to Install the Certificate below if you are using a
Standalone CA.
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, create the certificate request INF file. Choose the variant matching
your desired key algorithm.
RSA variant:ECC variant (ECDSA P-384):
Do not include
ProviderType in the INF for either variant. ProviderType is a
legacy CryptoAPI field. For CNG KSP requests it must be omitted — its presence causes
ERROR_INVALID_DATA for ECDSA requests.Enterprise CA — do not add a Subject Alternative Name to the INF. The CA builds the
subject and DNS SAN from Active Directory (configured on the template’s Subject Name tab).
Supplying a SAN in the request, or submitting as a user account, will result in
CERTSRV_E_SUBJECT_DNS_REQUIRED. The request is submitted as the machine account in the
next step.Generate the certificate request:
The output should show Only the OCSP signing key should be listed. If orphaned
Loading Futurex Provider. followed by CertReq: Request Created,
confirming the key was generated in CryptoHub.For the ECC variant, also verify no cngtest-* orphaned keys were left behind:cngtest-* keys are present from
previous failed attempts, delete them:On the OCSP server, open an elevated PowerShell prompt and create a scheduled task that
submits the certificate request as SYSTEM: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 incertsrv.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:
The output should contain:If the output is empty after 30 seconds, check whether certreq is still running:If a certreq process is present, it is hanging — most likely because the If
-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:ocsp_response.rsp already exists from a previous run, delete it before retrying:Install the Certificate
Applies to both Standalone CA and Enterprise CA. Run these on the OCSP server.Link the certificate to the HSM private key:Replace
<Serial_Number> with the value from the previous step.Verify the certificate was installed and linked to the HSM key:
Locate the OCSP Signing certificate in the output and confirm the following fields are
present: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 7: Configure the Revocation Configuration
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.
On the Select Signing Certificate page, select Manually select a signing
certificate.Select [ Next > ].
For both CA types in this guide, the HSM-backed signing certificate was enrolled and
installed manually in Step 6 (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. The signing certificate is assigned in
Step 9.
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>.crlThen 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.
15 minutes was used.Select [ OK ] then [ Finish ].Step 9: Assign the Signing Certificate
Applies to both CA types in this guide, because the HSM-backed signing certificate was
enrolled manually in Step 6.
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.
Step 10: 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).