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 Configure the CA server
for OCSP, “Serve the CRL through 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
2
Create an IIS virtual directory pointing to the CertEnroll folder:
PowerShell
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:Note the filenames of the
PowerShell
.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
<ServerHostname> and <CAName> with the actual values from your environment.3
Verify the files are present on the OCSP server:
Both the
.crl and .crt files should be listed.4
Import the CA certificate into the Trusted Root Certification Authorities store:Replace the filename with your actual CA certificate filename.
The output should confirm the certificate was added 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 Configure the CA server for
OCSP, “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 fails.
1
On the OCSP server, create a new file named RSA variant:ECC variant (ECDSA P-384):
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.Keep the
KeyUsageProperty = NCRYPT_ALLOW_SIGNING_FLAG line. Both INFs require it.
Without it, Futurex CNG creates a key that can encrypt and decrypt but can’t sign, so
certreq can’t sign the request and fails: it can stop responding without output, or show
an error. The failed attempt leaves the unused key on the HSM. In the
certutil -key -csp "Futurex CNG" output it’s the entry with no AT_SIGNATURE line; delete
it as shown in the next step before you retry.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.
HashAlgorithm in the INF only sets the request’s signature. The OCSP responses use the
revocation configuration’s hash algorithm, which you set in Step 7.Do not include
ProviderType in the INF. ProviderType is a legacy CryptoAPI field.
For CNG KSP requests it must be omitted, because its presence causes ERROR_INVALID_DATA for
ECDSA requests.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 5: Submit, Issue, and Install the
Signing Certificate.2
Generate the certificate request:
Verify the request file was created:The output should return Only the OCSP signing key should be listed. If keys from earlier failed attempts are
present, delete each one by the name
PowerShell
True, and the certreq output should end with
CertReq: Request Created, confirming the key was generated in the Excrypt HSM.For either variant, also check that no keys from earlier failed attempts were left behind:certutil lists: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 thedNSHostName 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: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.2
Run the scheduled task and wait for it to complete:
The output should contain:Note: the repeated word is expected: If a certreq process is present, it is hanging, most likely because the If
(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:-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.cer already exists from a previous run, delete it before retrying:3
Clean up the scheduled task:
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:
2
Find the serial number of the issued certificate:
3
Link the certificate to the HSM private key:Replace
<Serial_Number> with the value from the previous step.4
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 6: Configure the Revocation Configuration
1
Open the Online Responder Management console:
Command Prompt
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.
6
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 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. The signing certificate is assigned in Step 7: Assign the Signing
Certificate.
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>.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 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 ].
4
Right-click the Revocation Configuration, select Edit Properties, and on the Signing
tab set Hash algorithm to match the signing key: SHA256 for RSA and ECDSA P-256, SHA384
for ECDSA P-384, SHA512 for ECDSA P-521. Select [ OK ].
The Online Responder signs each response with this hash, not with the INF’s
HashAlgorithm. With the default (SHA256), a P-384 signing key still produces
ecdsa-with-SHA256 responses.5
Restart the Online Responder service so it loads the new signing key from the HSM:The service reads the HSM’s key list when it starts, so a key created after it started
isn’t found until the restart. Without it, the status in Step 8 shows a keyset error.
If you replace the signing certificate of an existing revocation configuration later (for
example, to renew it or to switch between RSA and ECDSA), also recycle the IIS application
pool. It caches responses, so clients keep receiving responses signed by the previous key
until it’s recycled:
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.
The Online Responder service loads the Futurex CNG provider when it starts and doesn’t
retry a signing key it can’t open. If the status shows an error (for example, a keyset
error), or if the HSM was unreachable when the service started, restart the service again
and refresh the status:
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: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: