OCSP Procedures

Install the OCSP Responder role

The Online Responder is a Microsoft Windows service that implements the OCSP services by decoding revocation status requests for specific certificates. This is an optional role you may install within AD CS. The service provides up-to-date validation of certificates based on the contents of the latest Certificate Revocation List (CRL) issued by the CA, and sends back a signed response containing the requested certificate status information. OCSP is used to provide real-time information about a certificate’s status. OCSP uses the Entrust nShield HSM to protect their private keys, and also uses the HSM for important operations such as key generation, certificate signing, and CRL signing.

These steps will configure the OCSP Responder to use an HSM for generation and storage of the private key for the OCSP Responder. The OCSP Responder will provide digitally signed responses to certificate status requests from Relying Parties. An OCSP Responder provides responses for the Issuing CA or CAs that it is configured to provide responses for.

The OCSP Responder is installed on top of Microsoft Internet Information Services (IIS). The OCSP service can be installed and configured on an existing IIS system that is providing other services. This includes IIS systems configured to be PKI Repositories or CRL Distribution Points.

Prerequisites

Install the Security World software both on the OCSP server and on the CA server.
Share the Security World by copying the %NFAST_KMDATA%\local directory from the CA server to the OCSP server.
Ensure that the HSM(s) has enough client licenses to support the OCSP Responder node.
Configure firewall rules appropriately so that the OCSP Responder can communicate both ways, with both the HSM and the RFS on TCP 9004.
Create a new OCSP Signing Template, based on the original version, that uses the nShield KSP for key pair generation.
Configure the OCSP Responder as a client of the HSM and the HSM as a client of the OCSP Responder.
Ensure that the machine where the CA is installed and which will be configured to issue the OCSP Response Signing certificate.
Ensure that the OCSP Responder that will need access to the OCSP Response Signing private key has been set up with the following:
- Security World software has been installed.
- The correct CSP/CNG/KSP configured.
- Access to the HSM or HSMs where the private key will be stored.

Configure the OCSP Response Signing Template for use with an HSM

The Online Responder must be set up as co-operating client/gang-client in relation to the RFS. This will ensure that it can both push and pull Security World data from the RFS.

It is recommended to use module key protection only when configuring the security for the OCSP Response signing private key(s). This will allow all generation and interaction with the private keys to be handled by the OCSP Responder without any need for administrator interaction.

Sign in to the machine where the CA is installed, with an account that has Domain Admin level privileges.
Run certtmpl.msc from a command prompt, or via the Run command.
Right-click the OCSP Response Signing Template and select Duplicate Template.

The new template opens, with the Compatibility tab open.
Change the Compatibility Settings to the following:
- Certification Authority: Windows Server 2016
- Certificate Recipient: Windows 10 / Windows Server 2016
Select OK.

Do not select Apply.
Select General > Template Display Name and enter a name for the new OCSP Response Signing template.
Select Request handling > Authorize additional service accounts to access the private key.
Select Key Permissions.
In the Permissions window, select Add, then select Object Types.
Select the Service Accounts option, then select OK.
In Enter the object names to select, enter Network Service, select Check Names, then select OK.

Ensure that Network Service has Read permissions.
The default validity period and renewal period for an OCSP Signing certificate are 2 weeks and 2 days respectively. If the private key(s) of the OCSP Signing key pair(s) are to be protected by an HSM, then the validity period of the certificate can be extended because of the improved security protection afforded by the private key(s).

If required, change the validity period or the renewal period.
Select Cryptography > Provider Category, then select the provider from the list.
Select a cryptographic algorithm name from the list, then specify the minimum key size.
Select Requests must use one of the following providers. This will enable the selection of the cryptographic providers populated in the list. Select the nShield CSP or KSP as available.
Modify the request hash to your required hash algorithm.
If the environment in which the certificate will be used contains either Windows XP or Windows Server 2003 machines, do not select Use alternate signature format.

The contents of the tab may take a while to appear due to the number of cryptographic providers on the server.

If no nShield CSPs or KSPs are visible in the list of providers, ensure that both the Security World software has been installed and the relevant Configuration Wizard (CSP or CNG or both) has been run on the server.
Select Security > Add, then select Object Types.

Object Types appears.
Select Computers, then select OK.
In Select Users, enter the name of a server that will act as an OCSP Responder, then select Check Names. If the name of the server is found, it will appear underlined in the box. Then select OK.
Select the server name and in Permissions, ensure that Read & Enroll permissions are selected.
Configure permissions for all servers that will use this template.

If the Online Responder is installed on Windows Server Core, you also need to add the machine that is used to manage Windows Server Core remotely. Both the Windows Server Core machine and the remote machine have to be added and assigned Read & Enroll permissions in this step.
To add all servers at once, separate the names with a semi-colon (;), then select Check Names. If the entries are correct, all server names will be underlined. Then the permissions for each server can be set to have Read & Enroll.
Select OK. This will create the new OCSP Signing Template ready for use.
On the CA that will be making use of the OCSP Responder, enable the new template for issuance.
1. In the Certification Authority MMC, right-click Certificate Templates, select New > Certificate Template to Issue.
2. In Enable Certificate Templates, select the new OCSP Signing Template, then select OK.
If the CA is installed on Windows Server Core, you need to retarget the CA to the Windows Server Core machine:
1. Right-click Certification Authority (Local), then select Retarget Certification Authority.
2. Select Another computer > Browse, then select your CA.

Install Security World software on the OCSP Responder

Skip this section if the CA and OCSP Responder are on the same server because the Security World software should already be present on the server.

Ensure that the installer is 12.40.02 or later.
Do not permit the AutoRun to start the installation process. If it does, cancel or quit the installation immediately.
Open a File Explorer window and browse to the CD root directory.
Right-click Setup.exe and select Run as Administrator.
Depending on the configuration, your local administrator credentials may be requested to execute this step.
From the list of components to install, select:
- nShield Hardware Support
- nShield Core Tools
- nShield CSPs (CNG, CAPI)
Then select Next on each of the dialogs which appear. The software is installed, then confirmation dialogs appear. Accept all the default parameters for these. The installer will then quit.
Add the %nfast_home%\bin directory to the system PATH environment variable. This should be done via the Advanced System Settings and Environment Variables options from the System link on the Start menu.
This allows the Security World binaries to be accessible system wide without having to specify the %nfast_home%\bin directory every time.

Configure Windows Firewall

To allow the Connect HSM to communicate with the hardserver on the host with CA, the hardserver must be able to communicate through the Windows Firewall. If Windows Firewall is turned off, no further action is required.

Turning off Windows Firewall is not recommended but is dependent on local operating and security policies.

If Windows Firewall is turned on, follow these steps:

Determine which location the network connection has been configured with. Public is the default unless specified otherwise.
Right-click the Windows icon on the task bar and select Control Panel.
Select System and Security and then Allow an app through Windows Firewall.
Select Change Settings and then Allow another app.
Select Browse, navigate to hardserver.exe, select Open, then select Add. Location:
- Before 12.60: C:\Program Files (x86)\nCipher\nfast\bin\hardserver.exe
- From 12.60 onwards: C:\Program Files\nCipher\nfast\bin\hardserver.exe
- Ensure that nfserv (nShield hardserver in Security World versions 12.60 onwards) is set for the following properties:
  - Private
  - Public
  - Domain (if required)
Select OK.

Enroll the Online Responder as a client of the HSM

There is only one Remote File System (RFS) per Security World. One of the CAs can be used as the RFS or alternatively, a single system acts as the RFS but is not a client of the HSM.

On the OCSP Server, enroll the client with the HSM:
```
> nethsmenroll --force --verify-nethsm-details <IP_address_of_HSM>
```
You can check that the client is correctly configured to make use of the HSM by running the enquiry command and checking the output shows that the HSM is available.
Manually copy the World file and the module file from C:\ProgramData\nCipher\Key Management Data\local on the RFS to the same location on the OCSP Responder node.

These files have to be copied so that the OCSP Responder node can make use the of the HSMs and Security World.

Install the Key Service Provider on the OCSP Responder

Sign in to the OCSP Responder as the local administrator or using a Domain account with local administrator privileges.
Security World software and wizards must be run using the true local administrator account in order for all file permissions to be written correctly.
Select the Windows icon on the taskbar, select the down arrow, then select nCipher > CNG Configuration Wizard.
If a User Account Control (UAC) dialog appears, select Yes.
In the wizard, select Next. Ensure Use the existing security world is selected, then select Next.
In Set Module States, ensure that Mode is set to operational and that State is usable. Select Next.
If the mode is not operational, that is, it states pre-initialization, ensure that the Security World is loaded into the module.
In Key Protection Setup, ensure that Operator Card Set protection is selected if you are using OCS protection. Do not select Always use the wizard when creating or importing keys. Do not create a new Operator Card Set. Select Next.
If you are not using an OCS, select Module Protection. Module protection should be used for the OCSP Responder to ensure that certificate auto-enrolment completes without needing administrator interaction.
To install the Key Service Provider (KSP), in Software Installation, select Next, then select Finish.
To check whether the nShield KSP is properly installed, run the following command at a command prompt:
```
> certutil -csplist
```
In the output, look for an entry which states:
```
Provider Name: nCipher Security World Key Storage Provider
```
If this entry is not available, investigate the KSP configuration before proceeding.

Install and configure the OCSP Responder service

On the OCSP Responder server, in Server Manager, select Add Roles and Features.
On the Before You Begin screen, select Next.
On the Select Installation Type screen, select Next.
On the Select Destination Server screen, select Next.
On the Select Server Roles screen, select Active Directory Certificate Services.
In the Add Roles and Features Wizard dialog that appears, select Add Features.
On the Server Roles screen, select Next.
On the Select Features page, select Next.
On the Active Directory Certificate Services screen, select Next.
Clear Certification Authority, select Online Responder instead, then select Next.

Only one option should be selected.

If the CA and OCSP responder are on the same server, you cannot clear the Certification Authority option.
If the Add Roles and Features wizard appears, select Add Features.
On the Role Services screen, select Next.
Confirm the chosen installation options by selecting Install.
On the Installation Results screen, select Close.
Ensure that all the chosen configuration options successfully installed. Investigate any errors before proceeding.
From the notifications section in Server Manager Dashboard, select Post-Deployment Configuration.
In the resulting window, select Next and then select Configure.

The account being used to do the configuration must be a member of the Local Administrators group on the server.
Check that the output shows that the Online Responder role has been successfully configured.
From the Administrative Tools folder, open Online Responder Management.
On the left hand side, select Revocation Configuration.
In the Actions pane, select Add Revocation Configuration.
On the Getting started screen, select Next.
On the Name the Revocation Configuration page, type a friendly name for the configuration and then select Next.
The selected name should represent the CA that the Responder configuration is being created for. This name is only used to identify the configuration to administrators.
Select Select CA Certificate Location > Select a certificate for an existing Enterprise CA, then select Next.
Select Choose CA Certificate screen > Browse CA certificates published in Active Directory, then select Browse.
In Select Certification Authority, select the CA that the Responder configuration is created for, select OK, then select Next.

In Select Signing Certificate, ensure that Automatically select a signing certificate and Auto-enrol for an OCSP Signing certificate are selected. Also ensure that the OCSPResponseSigning template is selected, then select Next.

If you want the OCSP Responder to protect its OCSP Signing certificate private key using an HSM, you should select the certificate template you created instead of the default template shown in these instructions.

On the Revocation Provider screen, select Provider.
In the Base CRLs section of the resulting dialog box, select the URL, then select OK.
The OCSP Responder uses the CRL generated by the selected CA it is being configured for to obtain its information about the status of certificates issued by the CA.

If you are using Delta CRLs, select Delta CRLs > Add in the dialog box. In the window that appears, paste the URL to the Delta CRL issued by the Issuing CA whose configuration is being created on the OCSP Responder. Select OK.
Ensure the URL includes the correct encoding, with %20 for space characters.
Clear Refresh CRLs based on their validity periods box. Enter the required value for Update CRLs at this refresh interval (min).

CRLs are issued from the Issuing CA every 12 hours. Unless this setting is configured, the OCSP Responder will not retrieve manually issued CRLs that were issued between the automated issuance periods because of CRL caching and because the OCSP Responder uses CRLs to determine a certificate’s status. This forces the OCSP Responder to check for a new CRL every 5 minutes. In turn, this setting also invalidates the IIS and OCSP Responder caches meaning new responses will be sent to queries based on the 5-minute setting as opposed to the validity period specified in the CRL, for example 24 hours.
Back on the Revocation Provider screen, select Finish.
Ensure that the configuration of the OCSP Responder completes successfully. Investigate any issues before proceeding.
Right click the newly created Revocation Configuration and select Edit Properties.
Select the Signing tab.
Change the Hash algorithm to at least SHA256. This is mandatory if using FIPS 140-2 Level 3 because the default SHA1 option is not supported.
Select OK.
Right-click the server FQDN under the Array Configuration option, then select Set as Array Controller.

This server will act as the Array Controller for the OCSP Responder Service.
After the OCSP Responder has been configured and the key pair generated successfully on the HSM, the following command should be run to commit local Security World data, such as application key tokens, to the RFS:
```
> rfs-sync --commit
```
This is important because the RFS holds copies of all key tokens and the World file. Assuming that all key tokens used by clients are synchronized, a backup of the RFS Security World files.
In the Certification Authority MMC, right-click the CA and select Properties.
Select Extensions > Select Extension > Authority Information Access (AIA), then select Add, and enter the name of the OCSP URL:
```
http://<FQDN-of-OCSP-server>/ocsp.
```
Select OK.
Select Include in the online certificate status protocol (OCSP) extension, then select OK.
A window prompts you to restart the CA. Select Yes and wait for the CA to restart.

Verify that OCSP works correctly

If OCSP is on Windows Server Core, execute these steps on the Windows Server Core machine.

Generate a certificate request

The WebServer certificate template must be available. If required, install the WebServer certificate template in certsrv.msc. Right-click Certificate Templates, select New > Certificate Templates to issue, then select the WebServer template.

Open Notepad and create a file called rsa.inf with contents similar to the following on your local C drive:

[Version]
Signature = "$Windows NT$"
[NewRequest]
Subject = "C=GB,CN=rsa.inf"
KeyAlgorithm = RSA
KeyLength = 2048
ProviderName = "nCipher Security World Key Storage Provider"
KeyUsage = 0xf0
MachineKeySet = True
RequestType = PKCS10
[EnhancedKeyUsageExtension]
OID = 1.3.6.1.5.5.7.3.1
[Extensions]
1.3.6.1.5.5.7.48.1.5 = Empty

In the rsa.inf file, replace the subject with your CA common name.

From the command prompt navigate to your local C drive and run the following command:
```
> certreq -new rsa.inf rsa.req
```
Select the CA certificate from the window that appears and save it as rsa.cer in your local directory.
Check that rsa.req is listed in the directory.

In the command line run the command:

> certreq -submit -attrib -CertificateTemplate:WebServer rsa.req

Select the CA certificate from the Certification Authority list window that appears and save it as rsa.cer in your local directory.
Navigate to the directory where you saved the certificate and look for rsa.cer.

Run the following command:

> certutil -verify -urlfetch rsa.cer

Make sure the command completes successfully and the output contains the following lines:

Leaf certificate revocation check passed
CertUtil: -verify command completed successfully.

Remove information about the certificate’s CRL

Select Start > Run, enter certsrv.msc, then select OK.
Windows Server Enterprise:

Select Certificate Authority.

A list of folders appears below the CA.
Windows Server Core:

If CA is on Server Core, on the machine used to manage the CA remotely, right-click Certification Authority (Local), then select Retarget Certification Authority. Select Another computer, select Browse, and select your CA.
Right-click the Revoked Certificates folder, then select All Tasks, Publish.

A Publish CRL dialog appears.
Select OK to select a New CRL.
Right-click the CA, then select Properties.
Select the Extensions tab.
Check that the Select extension drop-down list box shows CRL Distribution Point (CDP).
Select any of the listed CRL distribution points, then select Remove, then Yes.
Select Apply.

A dialog appears saying you need to restart the service.
Select Yes to restart the service, then select OK to close the dialog.

Retrieve information about the certificate’s AIA, CRLs, and OCSP

To check that clients can still obtain revocation data in the command prompt, navigate to the folder where the certificate is stored, then type:
```
> certutil -url rsa.cer
```
The URL Retrieval Tool appears.
Select Certs (from AIA), then select Retrieve.

The list contains the verified Certificate and its URL.
Select CRLs (from CDP), then select Retrieve.
Compare the results to what you had earlier when you removed a CRL distributed point. CRLs show they have been verified.
Select OCSP (from AIA), then select Retrieve.

The list contains the Verified OCSP URL.
Select Exit.

Verify the OCSP Server is active

To check details about the certificate and its CA configuration in the command prompt, navigate to the folder where the certificate is stored, then type:
```
> certutil -verify rsa.cer > rsa.txt
```

Open the text file rsa.txt. The last few lines should be as follows:

Verified Issuance Policies: None
Verified Application Policies:
1.3.6.1.5.5.7.3.1 Server Authentication
Leaf certificate revocation check passed
CertUtil: -verify command completed successfully

This shows that the OCSP Server is working correctly and there were no errors.

Back up, migrate, and restore CA

The most common procedure related to backup, migrate and restore for the CA and HSM is to use the options:

Select a certificate and use its associated private key.
Select an existing private key.

This procedure describes backing up the CA / HSM data on an existing server, then restoring the CA / HSM data onto a new server. Entrust has successfully tested this procedure in the following configurations:

Windows Server 2012 (CNG) to Windows Server 2012 R2 (CNG)
Windows Server 2016 (CNG) to Windows Server 2019 (CNG)
Windows Server 2019 (CNG) to Windows Server 2022 (CNG)

If your existing CA is using a custom CAPolicy.inf file, you should copy the file to the new planned CA server. The CAPolicy.inf file is located in the %SystemRoot% directory, which is usually C:\Windows.

Migrate the CA using an existing certificate and associated private key using Module Protection

For this procedure your CA must be protected with module-only protection or 1/N OCS without passphrase as key protection method.

To back up the CA and HSM data on the existing server (machine #1), then migrate the CA and HSM onto a new server (machine #2):

On machine #1:

Using PowerShell, back up the CA database by running the command:
```
> Backup-CARoleService - Path <path_to_backup_file> - DatabaseOnly
```
Alternatively, if you are using CMD (where CA_config_string = Computername\CA-Name), run:
```
> certutil - config WINserver1\CA-example -backupdb C:\Users\Administrator\Documents\dbexample backup
```
Default location of the CA .edb file: C:\Windows\System32\CertLog.
Export the certificate on machine #1:

For Windows Server Core, execute the following steps from the remote machine that is managing the Windows Server Core.
1. Run mmc.
2. In the console, select File > Add/Remove Snap-in.
3. Select the Certificates tab, then select Add.
4. The certificate snap-in window opens. Select Computer Account. Select Next.
5. Keep the default selection, select Finish, then select OK.
6. Select Trusted Root Certification Authorities > Certificates.
7. Right-click the CA certificate, then select All Tasks > Export. Select Next.
8. Select Base-64 encoded X.509 (.CER). Select Next.
9. Specify the path and file name to save the certificate. Select Next.
10. Select Finish.
11. Select OK to close the export success message.
Back up the contents of the Security World data from the following location: C:\ProgramData\nCipher\KeyManagement Data\local.
Uninstall the CA from machine #1.

On machine #2:

Copy the backup of the Security World data to the following folder on machine #2: C:\ProgramData\nCipher\KeyManagement Data\local.
Load the Security World onto the HSM on machine #2 by running the command:
```
> new-world -l
```
For more information about loading a Security World, refer to the User Guide for the HSM.
Run the CNG Configuration Wizard.

Windows Server Core:
```
> capingwizard
```
If you are selecting Operator Card Set protection, clear Always use the wizard when creating or importing keys.
Copy and install the X.509 certificate into the local user Trusted Root CA Store on machine #2:
1. Right-click the certificate, then select Install. Select Next.
2. Select Local Machine.
3. Select Place all certificates in the following store, then select Browse.
4. Select Trusted Root Certification Authorities, then select OK. Select Next, then select Finish.
5. Select OK to close the import success message.
Install the certificate to the Cert:\LocalMachine\My\ store. Using PowerShell, navigate to the LocalMachine:
```
> Set-Location -Path Cert:\LocalMachine\My\
```
Run the following command:
```
> Import-Certificate -FilePath <path to certificate>\Certificate_Name.cer
```

Repair the certificate store by running the following command from the console:

> certutil -f -repairstore -csp "nCipher Security World Key Storage Provider" my "<cert serial number>"

You should receive confirmation similar to:

my "Personal"
================ Certificate 0 ================
Serial Number: 13fa1422bfba4f9a4303e2aa162c25b2
Issuer: CN=ADCS-IO-CA, DC=ADCSDC, DC=internal
NotBefore: 11/10/2019 09:44
NotAfter: 11/10/2024 09:51
Subject: CN=ADCS-IO-CA, DC=ADCSDC, DC=internal
Certificate Template Name (Certificate Type):CA
CA Version: V0.0
Signature matches Public Key
Root Certificate: Subject matches Issuer
Template: CA, Root Certification Authority
Cert Hash(sha1): 486232dc0583012d47c75c74eb0d1b65da9f9484
Key Container = ADCS-IO-CA
Provider = nCipher Security World Key Storage Provider
Private key is NOT exportable
Signature test passed
CertUtil: -repairstore command completed successfully.

Select Start > Server Manager to open Server Manager.
Install and configure the CA as described in Install AD CS with Enterprise.
Install and configure AD CS with the following settings:
1. In the Set Up Private Key window, select Use existing certificate and private key.
2. In the existing Certificate window, the imported certificate is shown. Select the certificate, then select Allow administrator interaction when the private key is accessed by the CA. Select Next.
3. In the Certificate Database window, select Next.
4. In the Confirmation window, select Configure.
When the CA installation is complete, select Close in the Results window.
Stop the CA service.
Copy the backup of the CA database data to machine #2.
Run the command:
```
> certutil -shutdown
```
On machine #2, restore the CA database by running the command:
```
> certutil.exe -f -restoredb <BackupDirectory>
```
Restart the CA by running the command:
```
> net start certsvc
```
Verify that the CA service has started successfully by running the command:
```
> sc query certsvc
```

Migrate the CA using an existing certificate and associated private key using OCS and Softcard protection

For this procedure your CA is assumed to be protected with OCS or Softcards as a key protection method.

On machine #1:

Using PowerShell, back up the CA database by running the command:
```
> Backup-CARoleService - Path <path_to_backup_file> - DatabaseOnly
```
Alternatively, if you are using CMD (where CA_config_string = Computername\CA-Name), run:
```
> certutil - config WINserver1\CA-example -backupdb C:\Users\Administrator\Documents\dbexample backup
```
Default location of the CA .edb file: C:\Windows\System32\CertLog.
Export the certificate on machine #1:

For Windows Server Core, execute the following steps from the remote machine that is managing the Windows Server Core.
1. Run mmc.
2. In the console, select File > Add/Remove Snap-in.
3. Select the Certificates tab, then select Add.
4. The certificate snap-in window opens. Select Computer Account. Select Next.
5. Keep the default selection, select Finish, then select OK.
6. Select Trusted Root Certification Authorities > Certificates.
7. Right-click the CA certificate, then select All Tasks > Export. Select Next.
8. Select Base-64 encoded X.509 (.CER). Select Next.
9. Specify the path and file name to save the certificate. Select Next.
10. Select Finish.
11. Select OK to close the export success message.
Back up the contents of the Security World data from the following location: C:\ProgramData\nCipher\KeyManagement Data\local.
Uninstall the CA from machine #1.

On machine #2:

Copy the backed-up Security World data on the following path on machine #2: C:\ProgramData\nCipher\KeyManagement Data\local.
Load the Security World onto the HSM on machine #2, by running the command:
```
> new-world -l
```
For more information about loading a Security World, refer to the User Guide for the HSM.
Run the CNG Configuration Wizard.

Windows Server Core:
```
> capingwizard
```
If you are selecting operator card set protection, do not select Always use the wizard when creating or importing keys.
Create the temporary folder C:\temp.
Add the system environment variable NFAST_NFKM_TOKENSFILE:
1. Go to Control Panel > System and Security > System > Advanced System Settings.
2. Select Environment Variables.
3. Select New at the bottom under System Variables.
4. Add NFAST_NFKM_TOKENSFILE=c:\temp\nfast_nfkm_tokensfile.
Copy and install the X.509 certificate into the local user Trusted Root CA Store on machine #2:
1. Right-click the certificate, then select Install. Select Next.
2. Select Local Machine.
3. Select Place all certificates in the following store, then select Browse.
4. Select Trusted Root Certification Authorities, then select OK. Select Next, then select Finish.
5. Select OK to close the import success message.
Install the certificate into Cert:\LocalMachine\My\ store. Using PowerShell, navigate to the LocalMachine:
```
> Set-Location -Path Cert:\LocalMachine\My\
```
Run the following command:
```
> Import-Certificate -FilePath <path to certificate>\Certificate_Name.cer
```

At an elevated command prompt, use preload to relink the CA certificate and private key.

For OCS protection:

> preload --module=1 -f c:\temp\nfast_nfkm_tokensfile --cardset-name="<CARDSET_NAME>" certutil -repairstore -csp "ncipher security world key storage provider" my "<SHA-1_THUMBPRINT_OF_CA_CERT>"

For Softcard protection:

> preload --module=1 -f c:\temp\nfast_nfkm_tokensfile --softcard-name="<CARDSET_NAME>" certutil -repairstore -csp "ncipher security world key storage provider" my "<SHA-1_THUMBPRINT_OF_CA_CERT>"

You should receive confirmation similar to:

my "Personal"
================ Certificate 0 ================
Serial Number: 13fa1422bfba4f9a4303e2aa162c25b2
Issuer: CN=ADCS-IO-CA, DC=ADCSDC, DC=internal
NotBefore: 11/10/2019 09:44
NotAfter: 11/10/2024 09:51
Subject: CN=ADCS-IO-CA, DC=ADCSDC, DC=internal
Certificate Template Name (Certificate Type):CA
CA Version: V0.0
Signature matches Public Key
Root Certificate: Subject matches Issuer
Template: CA, Root Certification Authority
Cert Hash(sha1): 486232dc0583012d47c75c74eb0d1b65da9f9484
Key Container = ADCS-IO-CA
Provider = nCipher Security World Key Storage Provider
Private key is NOT exportable
Signature test passed
CertUtil: -repairstore command completed successfully.

Ensure that the nShield Service Agent is running. This can be viewed in the task tray.

At an elevated command prompt, use preload before you install the CA.

For OCS protection:

> preload --module=1 -f c:\temp\nfast_nfkm_tokensfile --cardset-name="<CARDSET_NAME>" pause

For Softcard protection:

> preload --module=1 -f c:\temp\nfast_nfkm_tokensfile --softcard-name="<CARDSET_NAME>" pause

Select Start > Server Manager to open Server Manager.
Install and configure the CA as described in Install AD CS with Enterprise.
Install and configure AD CS with the following settings:
1. In the Set Up Private Key window, select Use existing certificate and private key.
2. In the existing Certificate window, the imported certificate is shown. Select the certificate, then select Allow administrator interaction when the private key is accessed by the CA. Select Next.
3. In the Certificate Database window, select Next.
4. In the Confirmation window, select Configure.
When the CA installation is complete, select Close in the Results window.
Remove the previously added system environment variable NFAST_NFKM_TOKENSFILE.
Stop the CA service, then copy the backed-up CA database data onto machine #2.
Run the command:
```
>certutil -shutdown
```
On machine #2, restore the CA database by running the command:
```
>certutil.exe -f -restoredb <BackupDirectory>
```
Restart the CA by running the command:
```
>net start certsvc
```
Verify that the CA service has started successfully by running the command:
```
>sc query certsvc
```

Migrate the CA using an existing private key

To back up the CA and HSM data on the original server (machine #1), then to migrate the CA/HSM on a new server (machine #2):

On machine #1:

Back up the CA database by running the command:

> certutil -config <CA_config_string> -backupdb <BackupDirectory>

Back up the Security World data and the private key, which are found in C:\ProgramData\nCipher\Key Management Data\local. For more information about backing up a Security World, refer to the User Guide for the HSM.
Uninstall the CA from machine #1.

On machine #2:

Copy the backed-up Security World data and the private key to C:\ProgramData\nCipher\Key Management Data\local on machine #2.
Load the Security World onto the HSM on machine #2, by running the command:
```
> new-world -l
```
For more information about loading a Security World, refer to the User Guide for the HSM.
Run the CNG Configuration Wizard, then select Use existing Security World.
Install Microsoft Active Directory Certificate Services with the following settings:
1. In the Private Key window, select Use existing private key and use existing private key on this computer. Select Next.
2. In the Select Existing Key window, select Change. The Change Cryptographic Provider window opens.
3. Select the CSP that contains the created key. Delete the contents of the CA common name field, then select Search. The search results should find the existing private key.
4. Select the key that you generated on machine #1.
  
  If the private key is protected by Softcard or OCS, select Allow administrator interaction when the private key is accessed by the CA. Select Next.
5. In the Cryptography for CA window, select Next.
6. In the CA name window, select Next.
7. In the Validity Period window, specify the validity period. Select Next.
8. In the Certificate Database window, specify the certificate database location. Select Next.
9. In the Confirmation window, select Configure.
10. In the Installation Results window, select Close.
Copy the backed-up CA database data onto machine #2.
Run the command:
```
> certutil -shutdown
```
On machine #2, restore the CA database by running the command:
```
> certutil.exe -f -restoredb <BackupDirectory>
```
Restart the CA by running the command:
```
> net start certsvc
```
Verify that the CA service has started successfully by running the command:
```
> sc query certsvc
```

Uninstall AD CS and OCSP

To uninstall AD CS and OCSP:

Open Server Manager, then select Start > Server Manager.
Select Manage, then select Remove Roles & Features.

The Before you begin window opens. Select Next.
On Server selection, select a server from the server pool. Select Next.
Clear Active Directory Certificate Services and Online Responder. Select Next.
When the removal process is complete, select Close and restart the machine.