Microsoft AD CS
This document explains how to integrate Microsoft Active Directory Certificate Services (AD CS) with Luna HSM or Luna Cloud HSM. Microsoft AD CS provides customizable services for creating and managing public key certificates used in software security systems that employ public key infrastructure (PKI). Organizations use public key certificates to enhance digital security by binding the identity of a person, device, or service to a corresponding private key.
The root of trust in a public key infrastructure is the certificate authority (CA). Fundamental to this trust is the CA's private key, which is used to sign certificates issued to certificate holders and, in the case of a self-signed root CA certificate, to sign the CA's own certificate. Microsoft AD CS integrates with Luna HSM or Luna Cloud HSM to secure the CA private key.
Securing the Microsoft AD CS root encryption key with Luna HSMs delivers several key benefits:
-
Generates and stores CA signing private keys within FIPS 140-2 or FIPS 140-3 Level 3 validated cryptographic modules.
-
Manages the full key lifecycle to verify key integrity from generation to decommissioning.
-
Offloads cryptographic operations from application servers to dedicated hardware to reduce host CPU utilisation.
-
Logs key operations to an HSM audit trail for compliance tracking on-premises, though this specific audit log access is excluded from Luna Cloud HSM deployments.
Tested Platforms
This integration has been tested on the following platforms:
Tested platforms on Luna HSM
| HSM Type | Platforms Tested |
|---|---|
| Luna HSM | Windows Server 2025 Windows Server 2022 Windows Server 2019 Windows Server 2016 Windows Server 2012 R2 |
Tested platforms on Luna Cloud HSM
| HSM Type | Platforms Tested |
|---|---|
| Luna Cloud HSM | Windows Server 2022 Windows Server 2019 Windows Server 2016 Windows Server 2012 R2 |
Supported Key Types
Luna SafeNet Key Storage Provider (KSP) supports the following key types:
| Key Name | Key Type | Key Size/Curve | Origin of the Key | Description |
|---|---|---|---|---|
| CA Signing Keys | RSA | 2048 4096 |
Luna HSM | RSA keys used to sign certificates issued by the CA |
| CA Signing Keys | ECDSA | P-256 P-384 P-521 |
Luna HSM | ECDSA keys used to sign certificates issued by the CA |
| CA Signing Keys | ML-DSA-87 / ML-DSA-65 / ML-DSA-44 | 20736 15616 10496 |
Luna HSM | ML-DSA keys used to sign certificates issued by the CA |
| Entity Certificates issued by CA | RSA | 2048 4096 |
Luna HSM | PKI entity certificate keys used for various purposes |
| Entity Certificates issued by CA | ECDSA | P-256 P-384 P-521 |
Luna HSM | PKI entity certificate keys used for various purposes |
| Key Recovery Agent (KRA) Certificate issued by CA | RSA | 2048 4096 |
Luna HSM | KRA certificate keys used to perform key archival |
To generate ML-DSA signing keys on Luna HSM, the environment must meet the following criteria:
- Windows Server 2025 with Security Update (KB5120233) or later
- Luna HSM f/w 7.9.2 or later
- Luna Client s/w v10.9.4 or later
Prerequisites
Before you begin the integration process, ensure that you have completed the following tasks:
Configuring Luna HSM
To configure Luna HSM:
Ensure the HSM is setup, initialized, provisioned and ready for deployment.
Create a partition, establish a Network Trust Link (NTL) between HSM and client, and enable the client to access the partition. Refer to Luna Network HSM documentation for the detailed process.
Initialize Crypto Officer and Crypto User roles for the partition.
Use the following command to validate that the partition is successfully registered and configured:
C:\Program Files\SafeNet\LunaClient\lunacm
Upon successful execution, you should observe an output similar to the example provided below:
lunacm.exe (64-bit) v7.3.0-139. Copyright (c) 2018 SafeNet. All rights reserved. Available HSMs: Slot Id -> 0 Label -> ms-adcs Serial Number -> 1238696044953 Model -> LunaSA 7.3.0 Firmware Version -> 7.3.0 Configuration -> Luna User Partition With SO (PW) Key Export With Cloning Mode Slot Description -> Net Token Slot
For a detailed description of the steps involved in Luna HSM configuration, refer to Luna Network HSM documentation.
To configure Luna HSM HA
Please refer to the Luna Luna HSM documentation for HA steps and details regarding configuring and setting up two or more HSM appliances on Windows and UNIX systems. You must enable the HAOnly setting in HA for failover to work so that if primary stop functioning for some reason, all calls automatically route to secondary till primary starts functioning again.
This integration is tested in both HA and FIPS mode.
Configuring Luna Cloud HSM
Follow these steps to set up your Luna Cloud HSM:
Transfer the downloaded .zip file to your client workstation using pscp, scp, or other secure means.
Extract the .zip file into a directory on your client workstation.
Extract the appropriate client package for your operating system using the following command:
unzip cvclient-min.zip
Do not extract to a new subdirectory. Place the files in the client install directory.
Run the setenv script to create a new configuration file containing the information required by the Luna Cloud HSM service:
. setenv.bat
To add the configuration to an already installed UC client, use the -addcloudhsm option when running the setenv script.
Run the LunaCM utility and verify the Cloud HSM service is listed.
If your organization requires non-FIPS algorithms for your operations, ensure that the Allow non-FIPS approved algorithms checkbox is selected. For more information, refer to Supported Mechanisms.
Integrating Luna HSM with Microsoft AD CS on Windows Server
This section describes how to install Microsoft AD CS on Windows Server and integrate it with a Luna HSM or Luna Cloud HSM service. Microsoft AD CS uses the SafeNet Key Storage Provider (KSP) to integrate with the HSM.
We recommend that you familiarize yourself with Microsoft Active Directory Certificate Services. For more information, see the Microsoft AD CS documentation.
Configure SafeNet KSP
You must configure the SafeNet KSP so that the current user account and the local system account (NT AUTHORITY\SYSTEM) can access the Luna HSM or Luna Cloud HSM service.
- Luna HSM: The KSP package must be selected when you install the Luna Client software.
- Luna Cloud HSM: The KSP package is included in the
/KSPfolder of the service client package.
To configure the SafeNet KSP:
Go to the KSP folder of the Luna Client installation directory (by default, C:\Program Files\SafeNet\LunaClient\KSP). If you are using Luna Cloud HSM, go to the /KSP folder of the service client package.
Run KspConfig.exe, the KSP configuration wizard.
In the left pane, double-click Register Or View Security Library.
Click Browse, select cryptoki.dll from the Luna Client installation directory (or from the Luna Cloud HSM service client package), and then click Register.
Verify that the message Success registering the security library! appears.
In the left pane, double-click Register HSM Slots.
In the Register For User section, select the Domain and the user account that you are logged on with.
In the Slot Password box, type the Crypto Officer (CO) password for the slot.
Click Register Slot to register the slot for the selected user (Domain\User).
Verify that the message The slot was successfully and securely registered appears.
Register the same slot for the NT AUTHORITY\SYSTEM account. In the Register For User section, select NT AUTHORITY as the Domain and SYSTEM as the user, type the slot password again, and then click Register Slot.
Install Microsoft AD CS on Windows Server Using SafeNet KSP
You select the SafeNet KSP when you configure the Certification Authority role, so that the CA key is generated on the Luna HSM or Luna Cloud HSM service. To install Microsoft AD CS:
Log on as a user who is a member of the Enterprise Admins or Domain Admins group.
Verify that you configured the SafeNet KSP, as described in Configure SafeNet KSP.
In Server Manager, click Manage, and then click Add Roles and Features to open the Add Roles and Features Wizard.
On the Before you begin page, click Next.
On the Installation Type page, select Role-based or feature-based installation, and then click Next.
On the Server Selection page, select Select a server from the server pool, select your server in the Server Pool list, and then click Next.
On the Server Roles page, select Active Directory Certificate Services. When the Add features that are required for Active Directory Certificate Services? window appears, make sure that Include management tools (if applicable) is selected, and then click Add Features.
On the Server Roles page, click Next.
On the Features page, click Next. On the Active Directory Certificate Services page, click Next.
On the Role Services page, select Certification Authority, and then click Next.
On the Confirmation page, select Restart the destination server automatically if required. When the confirmation message appears, click Yes, and then click Install.
When the installation is complete, click Configure Active Directory Certificate Services on the destination server to open the AD CS Configuration wizard.
On the Credentials page of the AD CS Configuration wizard, click Next.
On the Role Services page, select Certification Authority, and then click Next.
On the Setup Type page, select Enterprise CA, and then click Next.
On the CA Type page, select Root CA, and then click Next.
On the Private Key page, choose how to provide the CA private key. To create a new private key, continue with the next step. If you already have a private key on the Luna HSM or Luna Cloud HSM service and want to use it, go to the step that starts with "To use an existing private key."
To create a new private key, select Create a new private key, and then click Next.
On the Cryptography for CA page, in the Select a cryptographic provider list, select the entry for the algorithm that you want to use with the SafeNet Key Storage Provider, for example, RSA#SafeNet Key Storage Provider.
Select the key length and the hash algorithm for signing the certificates that this CA issues.
Optionally, select the Allow administrator interaction when the private key is accessed by the CA check box. This option has no effect on keys that are generated on the Luna HSM.
Click Next. Skip the steps for using an existing private key, and continue with the step that follows them.
To use an existing private key, on the Private Key page, select Use existing private key, select Select an existing private key on this computer, and then click Next.
Click Change. In the dialog box, select the SafeNet Key Storage Provider entry that matches the algorithm of your existing key. Clear the CA common name box, and then click Search.
In the Search results list, select the existing key, and then click Next.
On the CA Name page, type a common name that identifies this CA, and then click Next.
On the Validity Period page, specify the validity period for the certificate that is issued to this CA, and then click Next.
On the CA Database page, specify the locations of the certificate database and the certificate database log, and then click Next. The certificate database records all certificate requests, issued certificates, and revoked or expired certificates.
On the Confirmation page, click Configure.
On the Results page, verify that the Configuration succeeded message appears, and then click Close to exit the wizard.
The CA private key is now stored on the Luna HSM or Luna Cloud HSM service.
Open a command prompt as an administrator. To verify that the AD CS service is running, run the following command, and then press Enter:
sc query certsvc
In the output, verify that STATE is RUNNING.
At the command prompt, run the following command to verify the CA key, and then press Enter:
certutil -verifykeys
If the verification succeeds, the output ends with a message that the command completed successfully.
Certificate Enrollment
Certificate enrollment is the process by which an entity requests and obtains a digital certificate from a CA. The entity generates a certificate signing request (CSR), the CA verifies the request, and the CA returns a signed certificate. This section describes how to obtain an entity certificate from a CA and generate the private key of the certificate on a Luna HSM by using the SafeNet KSP.
Enroll Certificates Using SafeNet KSP
To create a certificate template that uses the SafeNet KSP:
On the server where you configured the SafeNet KSP, open a command prompt and run certtmpl.msc to open the Certificate Templates Console.
In the details pane, right-click the Administrator template, and then click Duplicate Template.
On the Compatibility tab, select Windows Server 2016 in both the Certification Authority list and the Certificate recipient list.
In the Resulting changes dialog box, verify the changes, and then click OK.
On the General tab, type a name for the template in the Template display name box.
Click the Cryptography tab. In the Provider Category list, select Key Storage Provider.
In the Algorithm name list, select the algorithm, and then select the Minimum key size, if applicable.
Select Requests must use one of the following providers, and then select the SafeNet Key Storage Provider check box in the Providers list.
In the Request hash list, select a hash algorithm. If the Luna HSM is in FIPS mode, SHA-1 is not supported.
On the Subject Name tab, clear the Include e-mail name in subject name check box. In the Include this information in alternate subject name section, clear the E-mail name check box.
Click Apply, and then click OK to save the template.
Close the Certificate Templates Console.
Open a command prompt and run certsrv.msc to open the Certification Authority console.
In the console tree, expand the CA node, right-click Certificate Templates, point to New, and then click Certificate Template to Issue.
In the Enable Certificate Templates dialog box, select the template that you configured to use the SafeNet Key Storage Provider, and then click OK.
Click Certificate Templates, and verify that the template is listed in the details pane. Close the Certification Authority console.
Open a command prompt and run the certmgr.msc command to start requesting a certificate based on the template that you configured in the CA.
In the console tree, right-click Personal, point to All Tasks, and then click Request New Certificate.
On the Before You Begin page, click Next. On the Select Certificate Enrollment Policy page, select Active Directory Enrollment Policy, and then click Next.
On the Request Certificates page, select the template that you configured, and then click Enroll.
On the Certificate Installation Results page, verify that the status of the enrollment is Succeeded, and then click Finish.
In the certmgr window, expand Personal, click Certificates, and then verify that the issued certificate is listed.
The CA signs the certificate, and the private key of the certificate is generated on the Luna HSM.
Key Archival and Recovery
Key archival is the secure, centralized backup of private encryption keys by a CA, so that the keys can be recovered if the original keys are lost or damaged.
To protect the private key of the Key Recovery Agent on the Luna HSM, select the SafeNet Key Storage Provider when you generate the key for the Key Recovery Agent certificate.
If the Luna HSM is in FIPS mode and uses firmware 7.7.2 or later, FIPS restrictions prevent certificates whose keys you generate with the SafeNet Key Storage Provider from being used for encryption and decryption operations. In this case, use a non-FIPS Luna HSM partition or the Microsoft KSP for those certificates.
If you use the SafeNet Key Storage Provider for key archival, generate the Key Recovery Agent certificate on a separate system to isolate certificate generation from other operations. Register the SafeNet Key Storage Provider with a non-FIPS HSM partition so that the archived keys can be encrypted and decrypted.
To configure key archival, complete the following tasks:
Create a Key Recovery Agent (KRA)
Before you begin, ensure that:
- An Enterprise CA is installed on the CA server by using the SafeNet KSP, as described in Install Microsoft AD CS on Windows Server Using SafeNet KSP.
- The AD CS service is running on the CA server.
If you use the SafeNet Key Storage Provider for the KRA, generate the Key Recovery Agent certificate on a separate system that is configured with a non-FIPS Luna HSM partition.
To create a KRA:
Create a Key Recovery Agent certificate template that uses the SafeNet Key Storage Provider. Follow the steps in Enroll Certificates Using SafeNet KSP to create and save the template, but duplicate the Key Recovery Agent template instead of the Administrator template.
On the CA server, open a command prompt and run certsrv.msc to open the Certification Authority console.
In the console tree, expand the CA node, right-click Certificate Templates, point to New, and then click Certificate Template to Issue.
In the Enable Certificate Templates dialog box, select the Key Recovery Agent template, and then click OK.
Issue the KRA Certificate
To request the Key Recovery Agent (KRA) certificate:
Log on to the system on which the SafeNet KSP is registered with a non-FIPS partition, using the account that you registered for the slot.
Open a command prompt and run certmgr.msc.
In the console tree, right-click Personal, point to All Tasks, and then click Request New Certificate.
On the Before You Begin page, click Next. On the Select Certificate Enrollment Policy page, select Active Directory Enrollment Policy, and then click Next.
On the Request Certificates page, select the Key Recovery Agent template, and then click Enroll.
On the Certificate Installation Results page, verify that the status of the request is Pending, and then click Finish.
The CA administrator must approve the request before the certificate is issued.
Issue the KRA Certificate from the Certification Authority Console
To issue the KRA certificate:
Log on to the CA server with an account that has the Issue and Manage Certificates permission on the CA.
Open a command prompt and run certsrv.msc to open the Certification Authority console.
In the console tree, expand the CA node, and then click Pending Requests. In the details pane, right-click the request for the Key Recovery Agent template that you submitted, point to All Tasks, and then click Issue.
In the console tree, click Issued Certificates, and then verify that the KRA certificate is listed.
Retrieve the Issued Certificate from the CA
To retrieve and install the issued KRA certificate:
Log on to the system on which you requested the KRA certificate, using the same account that you used for the request.
Open a command prompt and run certmgr.msc.
In the console tree, right-click Certificates - Current User, point to All Tasks, and then click Automatically Enroll and Retrieve Certificates.
On the Before You Begin page, click Next.
On the Request Certificates page, select the issued Key Recovery Agent certificate, and then click Enroll. On the results page, click Finish.
In the console tree, expand Personal, click Certificates, and then verify that the Key Recovery Agent certificate is listed.
Configure the CA to Support Key Archival
To configure the CA to support key archival:
Log on to the CA server with an account that has the Manage CA permission on the CA.
Open a command prompt and run certsrv.msc to open the Certification Authority console.
In the console tree, right-click the CA node, and then click Properties.
Click the Recovery Agents tab, select Archive the key, and then click Add.
In the Key Recovery Agent Selection dialog box, select the KRA certificate that you issued, and then click OK.
In the CA Properties dialog box, click OK. When you are prompted to restart Active Directory Certificate Services, click Yes.
Create a Template with Key Archival Enabled
To create a certificate template that archives the private key of the certificate subject:
Log on to the CA server with an account that can create certificate templates in Active Directory.
Open a command prompt and run certtmpl.msc to open the Certificate Templates Console.
In the details pane, right-click the User template, and then click Duplicate Template.
On the Compatibility tab, select Windows Server 2016 in both the Certification Authority list and the Certificate recipient list.
In the Resulting changes dialog box, click OK.
On the General tab, in the Template display name box, type UserKeyArchival.
Click the Request Handling tab, and then select the Archive subject's encryption private key check box.
Click the Subject Name tab. Clear the Include e-mail name in subject name check box. In the Include this information in alternate subject name section, clear the E-mail name check box.
Click Apply, and then click OK to save the template.
Add a New Template to the CA for Issuing
To publish the key archival template on the CA:
On the CA server, open a command prompt and run certsrv.msc to open the Certification Authority console.
In the console tree, expand the CA node, right-click Certificate Templates, point to New, and then click Certificate Template to Issue.
In the Enable Certificate Templates dialog box, select the UserKeyArchival template, and then click OK.
In the console tree, click Certificate Templates, and then verify that UserKeyArchival is listed in the details pane.
Request a Certificate Using the Key Archival Template
To request a certificate whose private key the CA archives:
Log on to a client system as the user for whom you want to archive the key.
Open a command prompt and run certmgr.msc to open the Certificates console for the current user.
In the console tree, right-click Personal, point to All Tasks, and then click Request New Certificate.
On the Before You Begin page, click Next. On the Select Certificate Enrollment Policy page, select Active Directory Enrollment Policy, and then click Next.
On the Request Certificates page, select the UserKeyArchival check box, and then click Enroll.
On the Certificate Installation Results page, verify that the status is Succeeded, and then click Finish.
In the console tree, expand Personal, and then click Certificates. Double-click the new certificate, click the Details tab, click Serial Number, and write down the value. You need the serial number to recover the key.
On the CA server, open the Certification Authority console, and then click Issued Certificates. On the View menu, click Add/Remove Columns, and add the Archived Key column. Verify that the value is Yes for the certificate that you just requested.
Perform Key Recovery
If a user loses a private key that the CA archived, you can recover it. A certificate manager retrieves the encrypted key from the CA, and a Key Recovery Agent (KRA) decrypts it and saves it as a PFX file. You then import the PFX file for the user.
Before you begin, ensure that:
- The certificate was issued from the UserKeyArchival template, as described in Request a Certificate Using the Key Archival Template.
- The CA is configured to archive keys for the KRA certificate, as described in Configure the CA to Support Key Archival.
- The KRA certificate and its private key are available on the system on which you run the recovery commands. If the KRA key is on a Luna HSM, use the system that is registered with the non-FIPS partition.
To recover an archived key:
Log on to the client system as the user whose key was archived. Open a command prompt, and run certmgr.msc. In the console tree, expand Personal, and then click Certificates. Double-click the certificate that was issued from the UserKeyArchival template, and then click the Details tab.
Click Serial Number, and write down the value without spaces between the digit pairs. You need it to recover the key. Click OK to close the certificate.
The serial number is a hexadecimal string, for example, 2c00000010571aa3df40ba6396000000000010. In the following steps, <serial_number> stands for this value.
Log on to the CA server with an account that has permission to view issued certificates. Open the Certification Authority console, expand the CA node, and then click Issued Certificates.
On the View menu, click Add/Remove Columns. In the Available columns list, select Archived Key, click Add, and then click OK. In the details pane, scroll to the right, and verify that the Archived Key column shows Yes for the certificate whose serial number you wrote down.
The key is recoverable only if the Archived Key column shows Yes.
If you are testing key recovery, delete the user's certificate to simulate a lost key. On the client system, in certmgr, expand Personal, click Certificates, right-click the certificate that was issued from the UserKeyArchival template, and then click Delete. When the warning message appears, click Yes.
Log on to the system on which the KRA certificate is enrolled. Open a command prompt as an administrator, and go to the folder where you want to save the recovered files (this procedure uses C:\).
To retrieve the encrypted key from the CA, run the following command, and then press Enter. Replace <serial_number> with the serial number that you wrote down.
certutil -getkey <serial_number> outputblob
For example:
certutil -getkey 2c00000010571aa3df40ba6396000000000010 outputblob
The outputblob file is a PKCS#7 file that contains the KRA certificates, the user certificate, and the certificate chain. The inner content is an encrypted PKCS#7 file that contains the private key, which is encrypted with the KRA certificates.
To verify that the file was created, run the following command:
dir outputblob
If the file does not exist, check that you typed the serial number correctly and that your account has permission to retrieve archived keys from the CA.
To recover the original private and public key pair, run the following command, and then press Enter:
certutil -recoverkey outputblob user.pfx
When prompted, type a password to protect the PFX file in the Enter new password line, and then type it again in the Confirm new password line.
Log on to the client system as the user whose key was archived. In the certmgr console tree, right-click Personal, point to All Tasks, and then click Import.
In the Certificate Import Wizard, click Next. In the File name box, type the path of the PFX file (for example, C:\user.pfx), and then click Next.
In the Password box, type the password that protects the PFX file, select Mark this key as exportable, and then click Next.
Select Automatically select the certificate store based on the type of certificate, click Next, and then click Finish.
In the console tree, expand Personal, and then click Certificates. Double-click the imported certificate, click the Details tab, and then verify that the serial number matches the serial number that you wrote down.
Delete the outputblob and user.pfx files, because they contain the private key.
The private key is recovered. If the KRA key is stored on a Luna HSM, the recovery keys are protected by the HSM.
Migrate CA Keys from Microsoft Software KSP to SafeNet KSP
This section describes how to migrate a CA signing key from Microsoft software storage to a Luna HSM or Luna Cloud HSM service on Windows Server by using the ms2Luna utility.
Configure SafeNet KSP
You must configure the SafeNet Key Storage Provider (KSP) so that the current user account and the local system account (NT AUTHORITY\SYSTEM) can access the Luna HSM or Luna Cloud HSM service. If you are using a Luna HSM, the KSP package must be installed as part of the Luna Client software installation. If you are using the Luna Cloud HSM service, the KSP package is included in the service client package, in the /KSP folder.
Go to the KSP folder of the Luna Client installation directory (by default, C:\Program Files\SafeNet\LunaClient\KSP). If you are using the Luna Cloud HSM service, go to the /KSP folder of the service client package.
Run KspConfig.exe, the KSP configuration wizard.
In the left pane, double-click Register Or View Security Library.
Click Browse, select cryptoki.dll from the Luna Client installation directory (or from the service client package, if you are using the Luna Cloud HSM service), and then click Register.
Verify that the message Success registering the security library appears.
In the left pane, double-click Register HSM Slots.
In the Register For User section, select the Domain and the user account that you are logged on with.
In the Slot Password box, type the slot (partition) password.
Click Register Slot to register the slot for the selected user (Domain\User). Verify that the message The slot was successfully and securely registered appears.
Register the same slot for the NT AUTHORITY\SYSTEM account. In the Register For User section, select NT AUTHORITY as the Domain and SYSTEM as the user, type the slot password again, and then click Register Slot.
The Registered Slots section of the KSP interface might show only one entry. The slot is registered for both the user account and NT AUTHORITY\SYSTEM.
Back Up the CA
Before you migrate the CA key, back up the CA so that you can restore the CA database and keys if the migration fails. You also use this backup to restore the CA database after the migration. To back up the CA:
Log on to the CA server with an account that is a member of the local Administrators group and has the Manage CA permission on the CA.
Click Start, click Run, type certsrv.msc, and then click OK to open the Certification Authority console.
In the console tree, click the node that has the name of your CA. On the Action menu, click All Tasks, and then click Back up CA to open the Certification Authority Backup Wizard.
On the Welcome page, click Next.
On the Items to Back Up page, select the Private key and CA certificate check box and the Certificate database and certificate database log check box. In the Back up to this location box, type or browse to an empty directory in which to store the backup files, and then click Next.
On the Select a Password page, type a password in the Password and Confirm password boxes to protect the private key backup file, and then click Next.
On the completion page, click Finish.
Write down the password. You need it to restore the CA. The backup contains the CA private key, so store it in a secure location.
Migrate an MS CA to a Luna HSM or Luna Cloud HSM Service Using ms2Luna
A CA signing key that is stored in software is less secure and can be compromised. To protect the key, migrate it to the Luna HSM or Luna Cloud HSM service. The CA continues to use the same key after the migration.
Before you begin, ensure that:
- You registered a slot with the KSP, as described in Configure SafeNet KSP.
- You backed up the CA, as described in Back Up the CA.
To migrate the CA key by using ms2Luna:
In the Certification Authority console, right-click the CA node, and then click Properties. On the General tab, click View Certificate, click the Details tab, and then click Thumbprint in the Field column. Write down the thumbprint.
Open a command prompt as an administrator, and go to the KSP folder of the Luna Client installation directory (by default, C:\Program Files\SafeNet\LunaClient\KSP). If you are using Luna Cloud HSM, go to the /KSP folder of the service client package.
Run ms2Luna.exe. When prompted, type the thumbprint of the CA certificate, and then press Enter.
To verify the migration, run the following command, and then press Enter. Replace <CA_Certificate_Thumbprint> with the thumbprint that you wrote down.
certutil -verifystore My <CA_Certificate_Thumbprint>
In the output, verify that Provider is SafeNet Key Storage Provider.
In the Certification Authority console, right-click the CA node, point to All Tasks, and then click Stop Service. Right-click the CA node again, point to All Tasks, and then click Start Service. After the restart, the CA uses the key on the Luna HSM to sign new certificates.
Restore the CA database that you backed up before the migration. For instructions, see Restore MS CA.
If the CA service does not start after the migration, the CA configuration might still point to the Microsoft Software Key Storage Provider. For more information, contact Thales Customer Support. As a last resort, uninstall the AD CS role, and then follow the instructions in Install Microsoft Active Directory Certificate Services on Windows Server Using SafeNet KSP with Migrated Key.
Install Microsoft Active Directory Certificate Services on Windows Server Using SafeNet KSP with Migrated Key
Use this procedure to reinstall Microsoft Active Directory Certificate Services (AD CS) if the CA service does not start after you migrate the CA key to the Luna HSM. During the installation, you configure the CA to use the existing key on the Luna HSM.
Before you begin, ensure that:
- You removed the AD CS role from the server.
- You backed up the CA, as described in Back Up the CA.
- The SafeNet KSP is registered, as described in Configure SafeNet KSP.
To install AD CS:
Log on as a user who is a member of the Enterprise Admins or Domain Admins group.
In Server Manager, click Manage, and then click Add Roles and Features. The Add Roles and Features Wizard opens.
On the Before you begin page, click Next.
On the Installation Type page, select Role-based or feature-based installation, and then click Next.
On the Server Selection page, select Select a server from the server pool, select your server in the Server Pool list, and then click Next.
On the Server Roles page, select Active Directory Certificate Services.
When the Add features that are required for Active Directory Certificate Services? window appears, make sure that Include management tools (if applicable) is selected, and then click Add Features.
Click Next until the Role Services page appears.
On the Role Services page, select Certification Authority, and then click Next.
On the Confirmation page, verify that Active Directory Certificate Services is listed as the role to install, and then click Install.
When the installation is complete, click Configure Active Directory Certificate Services on the destination server. The AD CS Configuration wizard opens.
On the Credentials page of the AD CS Configuration wizard, click Next.
On the Role Services page, select Certification Authority, and then click Next.
The following steps assume that your original CA is an Enterprise root CA. If it is a different type, select the same setup type and CA type as your original CA.
On the Setup Type page, select Enterprise CA, and then click Next.
On the CA Type page, select Root CA, and then click Next.
On the Private Key page, select Use existing private key, select Select an existing private key on this computer, and then click Next.
Click Change. In the dialog box that opens, select the SafeNet Key Storage Provider entry that matches the algorithm of the key that you migrated. Clear the CA common name box, and then click Search.
In the Search results list, select the migrated key. Optionally, select the Allow administrator interaction when the private key is accessed by the CA check box. This option has no effect on keys that are stored on a Luna HSM. Click Next.
On the Cryptography for CA page, select the hash algorithm for signing the certificates that this CA issues, and then click Next.
On the CA Name page, type the common name of your original CA, and then click Next.
On the Validity Period page, specify the validity period for the certificate that is issued to this CA, and then click Next.
On the CA Database page, specify the locations of the certificate database and the certificate database log, and then click Next. The certificate database records all certificate requests, issued certificates, and revoked or expired certificates.
On the Confirmation page, click Configure.
When the configuration is complete, review the results, and then click Close to exit the AD CS Configuration wizard.
Open a command prompt as an administrator. To verify that the CA service is running, run the following command, and then press Enter:
sc query certsvc
In the output, verify that STATE is RUNNING.
After the installation, restore the CA database that you backed up before the key migration. For instructions, see Restore MS CA.
Restore the MS CA Database
After you migrate the CA key to the Luna HSM, restore the CA database from the backup that you made before the migration. For instructions on making the backup, see Back Up the CA.
Before you begin, log on to the CA server with an account that is a member of the local Administrators group and has the Manage CA permission on the CA. If the CA runs on a cluster, use the node that owns the AD CS cluster role.
To restore the CA database:
Click Start, click Run, type certsrv.msc, and then click OK. The Certification Authority console opens.
In the console tree, click the node that has the name of your CA. On the Action menu, click All Tasks, and then click Restore CA. If you are asked to stop Active Directory Certificate Services, click OK.
On the Welcome page of the Certification Authority Restore Wizard, click Next.
On the Items to Restore page, select the Certificate database and certificate database log check box. Do not select Private key and CA certificate, because the CA key is now on the Luna HSM. Click Browse, select the directory that contains the backup files, and then click Next.
If the wizard asks for a password, type the password that you set when you backed up the CA, and then click Next.
On the completion page, click Finish. When the Do you want to start Active Directory Certificate Services now? message appears, click Yes.
In the Certification Authority console, verify that Active Directory Certificate Services is running.
Click Issued Certificates, and verify that the certificates that the CA issued before the migration are listed.
Install and Configure the CA Cluster Using SafeNet KSP
The following sections describe how to install and configure a CA on a failover cluster that runs on Windows Server. The cluster nodes access the same CA key on the Luna HSM.
To set up the CA cluster, complete these procedures in order:
Set Up the CA Server Role on the First Cluster Node
Detach the Shared Storage from the First Cluster Node
Release the HSM from the First Cluster Node
Set Up the CA Server Role on the Second Cluster Node
Set Up the Failover Cluster Feature on the Cluster Nodes
Configure AD CS Failover Cluster
Create CRL Objects in Active Directory
Modify CA Configuration in Active Directory
Set Up the CA Server Role on the First Cluster Node
Before you begin, ensure that:
-
The Luna Client is installed on every cluster node, and the SafeNet KSP is registered on every node, as described in Configure SafeNet KSP.
-
The shared storage is attached and online on the first node.
-
You have the
ksputil.exeutility, which creates the cluster key for the other nodes. If you do not have it, contact Thales Customer Support.
To install Active Directory Certificate Services on the first cluster node and back up the CA:
Log on as a user who is a member of the Enterprise Admins or Domain Admins group.
Install Microsoft Active Directory Certificate Services on the first node by following the steps in Install Microsoft AD CS on Windows Server Using SafeNet KSP. After the installation is complete, continue with the next step.
Click Start, click Run, type certsrv.msc, and then click OK. The Certification Authority console opens.
In the console tree, click the node that has the name of your CA. On the Action menu, click All Tasks, and then click Back up CA.
On the Welcome page of the Certification Authority Backup Wizard, click Next.
On the Items to Back Up page, select the Private key and CA certificate check box. In the Back up to this location box, type or browse to the directory where you want to store the backup files, and then click Next.
On the Select a Password page, type a password in the Password and Confirm password boxes, and then click Next.
Click Finish. When a warning message states that the private key cannot be exported, click OK.
This warning is expected, because the private key is generated on the Luna HSM and cannot leave it. The backup contains the CA certificate. Keep the backup files and the password, because you need them when you set up the second node.
Open a command prompt as an administrator, and go to the KSP folder of the Luna Client installation directory (by default, C:\Program Files\SafeNet\LunaClient\KSP). Keys that the KSP generates are bound to the system on which they are generated. To let the second node use the CA key, run the following command to create a cluster key, which duplicates the CA key and binds it to the second node. When prompted, type the partition password.
ksputil clusterKey /s <SlotNum> /n <CA_Name> /t <TargetCluster_Host>
Where:
-
<SlotNum>is the slot ID of the Luna HSM partition. -
<CA_Name>is the name of the CA. -
<TargetCluster_Host>is the fully qualified domain name (FQDN) of the second node.
The output reports that the CA key was successfully migrated to the target host.
If your cluster has more than two nodes, run the command once for each additional node, and use the FQDN of that node as <TargetCluster_Host>. This binds all nodes to the same CA key, so that each node can access the key when it is part of the AD CS cluster.
In the Certification Authority console, click the CA node. On the Action menu, click All Tasks, and then click Stop Service. Stopping the service releases the shared disk so that the cluster can use it on the second node. Close the Certification Authority console.
Detach the Shared Storage from the First Cluster Node
Before you begin, make sure that the CA service on the first node is stopped, as described in the previous procedure.
Open Server Manager, and then click File and Storage Services. Click Disks, right-click the shared disk, and then click Take Offline. When the confirmation message appears, click Yes.
Release the HSM from the First Cluster Node
Disable the network connection between the first node and the Luna HSM. Because the Luna HSM is a network-attached HSM, this releases it from the first node.
Log off from the first node.
You have finished setting up the CA role on the first node.
Set Up the CA Server Role on the Second Cluster Node
This section explains how to set up the CA server role on the second cluster node. If your cluster has more than two nodes, repeat these steps on each additional node.
Before you begin, ensure that:
-
The Luna Client is installed on this node, and the SafeNet KSP is registered with the partition, as described in Configure SafeNet KSP.
-
This node can reach the Luna HSM over the network.
-
The shared disk is visible to this node.
-
You have the backup file (a
.p12file) and the password from the first node.
Configure the Second Cluster Node
Log on to the second cluster node as a user who has permission to install the CA. To install an Enterprise CA, log on with Enterprise Admin permissions in the Active Directory domain. To install a standalone CA, you can log on with local Administrator permissions if you do not want to register the CA in the Active Directory configuration container.
Open Server Manager, click File and Storage Services, and then click Disks. If the shared disk that is used for the CA is offline, right-click the disk, and then click Bring Online. Verify that the disk is online.
Copy the .p12 backup file that you created on the first node to the second cluster node.
Click Start, click Run, type mmc, and then click OK.
On the File menu, click Add/Remove Snap-in.
In the Add or Remove Snap-ins dialog box, select Certificates in the list of available snap-ins, and then click Add.
In the Certificates snap-in dialog box, select Computer account, and then click Next.
On the Select Computer page, select Local computer, and then click Finish.
In the Add or Remove Snap-ins dialog box, click OK.
Next, import the CA certificate, as described in Import an Existing CA Certificate.
Import an Existing CA Certificate
Before you begin, ensure that you created a cluster key for this node with ksputil, as described in Set Up the CA Server Role on the First Cluster Node, and that the slot is registered on this node for both your user account and NT AUTHORITY\SYSTEM.
In the Certificates snap-in that you added in the previous procedure, expand Certificates (Local Computer) in the console tree, and then click Personal.
On the Action menu, click All Tasks, and then click Import.
On the Welcome page of the Certificate Import Wizard, click Next.
In the File name box, type the name of the .p12 file that you created when you backed up the CA on the first node, and then click Next. If you click Browse to find the file, change the file type to Personal Information Exchange (*.pfx,*.p12).
In the Password box, type the password that you set when you backed up the CA on the first node, and then click Next.
Do not select the Mark this key as exportable check box. The private key is stored on the Luna HSM and must not be exported.
On the Certificate Store page, select Place all certificates in the following store, click Browse, select Personal, and then click OK. Click Next.
Click Finish. When the message that the import was successful appears, click OK.
In the Certificates snap-in, expand Personal, and then click the Certificates folder.
Double-click the imported CA certificate, and then click the Details tab.
Click Serial Number. In the box below the list, select the value, and then press Ctrl+C to copy it. Click OK to close the certificate.
Open a command prompt as an administrator. To repair the association between the certificate and the private key on the Luna HSM, run the following command, and then press Enter. Replace <serial_number> with the serial number that you copied.
certutil -repairstore My "<serial_number>"
When the command completes successfully, the output shows that Provider is SafeNet Key Storage Provider and that Encryption test passed.
Next, add the AD CS role, as described in Add the AD CS Role.
Add the AD CS Role
This procedure installs the AD CS role on the second cluster node. You configure the role in the next procedure.
On the second cluster node, in Server Manager, click Manage, and then click Add Roles and Features. The Add Roles and Features Wizard opens.
On the Before you begin page, click Next.
On the Installation Type page, select Role-based or feature-based installation, and then click Next.
On the Server Selection page, select Select a server from the server pool, select your server in the Server Pool list, and then click Next.
On the Server Roles page, select the Active Directory Certificate Services check box.
When the Add features that are required for Active Directory Certificate Services? window appears, make sure that Include management tools (if applicable) is selected, and then click Add Features.
On the Features page, click Next.
On the Active Directory Certificate Services page, click Next.
On the Role Services page, select the Certification Authority check box, and then click Next.
On the Confirmation page, click Install.
When the installation is complete, click Configure Active Directory Certificate Services on the destination server. The AD CS Configuration wizard opens.
Configure the AD CS Role
This procedure configures the AD CS role on the second cluster node so that it uses the CA certificate and the key on the Luna HSM.
On the Credentials page of the AD CS Configuration wizard, click Next.
On the Role Services page, select the Certification Authority check box, and then click Next.
On the Setup Type page, select Enterprise CA, and then click Next.
On the CA Type page, select Root CA, and then click Next.
On the Private Key page, select Use existing private key, select Select a certificate and use its associated private key, and then click Next.
On the Existing Certificate page, select the CA certificate that you imported (it has the name of your CA), and then click Next.
On the CA Database page, set the locations of the certificate database and the certificate database log to the same locations on the shared disk that you used on the first node, and then click Next. If a message states that an existing database was found, click Yes.
On the Confirmation page, click Configure.
On the Results page, verify that the Configuration succeeded message appears, and then click Close to exit the AD CS Configuration wizard.
Log off from the second cluster node.
Set Up the Failover Cluster Feature on the Cluster Nodes
Install the Failover Clustering feature on every cluster node before you create the failover cluster. Repeat the following steps on each node:
Log on to the cluster node with local administrator permissions.
In Server Manager, click Manage, and then click Add Roles and Features. The Add Roles and Features Wizard opens.
On the Before you begin page, click Next.
On the Installation Type page, select Role-based or feature-based installation, and then click Next.
On the Server Selection page, select Select a server from the server pool, select your server in the Server Pool list, and then click Next.
On the Server Roles page, click Next. On the Features page, select the Failover Clustering check box. When the Add features that are required for Failover Clustering window appears, click Add Features.
On the Features page, click Next.
On the Confirmation page, click Install.
When the installation is complete, click Close on the Results page.
In Server Manager, click Tools, and then verify that Failover Cluster Manager is listed.
Create a Failover Cluster
Before you begin, ensure that:
- The Failover Clustering feature is installed on both nodes, as described in Set Up the Failover Cluster Feature on the Cluster Nodes.
- Both nodes are members of the same Active Directory domain and can resolve each other's names.
- The shared disk is visible to both nodes.
- An IP address is available for the cluster, if your network does not use DHCP.
To create a failover cluster:
Log on to the cluster node that has the shared storage online, using an account that is a local administrator on both nodes and has permission to create computer objects in the domain.
In Server Manager, click Tools, and then click Failover Cluster Manager. On the Action menu, click Create Cluster.
On the Before You Begin page, click Next.
On the Select Servers page, in the Enter server name box, type the computer name of the first cluster node, and then click Add. Repeat this step for the second cluster node, and then click Next.
On the Validation Warning page, select Yes to run the configuration validation tests, and then click Next. Follow the prompts of the Validate a Configuration Wizard to run all tests. When the tests finish, review the report, and then click Finish.
On the Access Point for Administering the Cluster page, type a name for the cluster in the Cluster Name box. If your network does not use DHCP, type a static IP address for the cluster. Click Next.
On the Confirmation page, verify the cluster name, the nodes, and the IP address, and make sure that the Add all eligible storage to the cluster check box is selected. Click Next. When the cluster is created, click Finish on the Summary page.
In Failover Cluster Manager, expand the cluster name, and then click Nodes. Verify that both nodes have the status Up. Click Storage, then Disks, and verify that the shared disk is listed.
Configure the AD CS Failover Cluster
This procedure adds the CA as a clustered role, so that the cluster can run the CA on either node.
Before you begin, ensure that:
- You installed and configured the AD CS role on both nodes, and the CA service is stopped on both nodes.
- The cluster exists, and the shared disk is in the cluster, as described in Create a Failover Cluster.
- A name (and, if your network does not use DHCP, an IP address) is available for the CA role.
To configure certificate services for the AD CS failover cluster:
In Failover Cluster Manager, expand the cluster name, right-click Roles, and then click Configure Role.
On the Before You Begin page, click Next.
On the Select Role page, select Generic Service, and then click Next.
On the Select Service page, select Active Directory Certificate Services, and then click Next.
On the Client Access Point page, in the Name box, type the network name that clients use to reach the CA. If your network does not use DHCP, also type a static IP address. Click Next.
On the Select Storage page, select the shared disk that is used for the CA, and then click Next.
On the Replicate Registry Settings page, click Add. In the Registry Key dialog box, type SYSTEM\CurrentControlSet\Services\CertSvc (the dialog box adds the HKEY_LOCAL_MACHINE\ prefix), and then click OK. Click Next.
On the Confirmation page, click Next.
On the Summary page, click Finish.
In Failover Cluster Manager, click Roles, and then verify that the Status of the new certificate services role is Running.
To test failover, right-click the role, point to Move, and then click Best Possible Node. Verify that the role starts on the other node and that its Status is Running.
Next, create the CRL objects in Active Directory, as described in Create CRL Objects in Active Directory.
Create CRL Objects in Active Directory
By default, the CA cluster does not have permission to publish its certificate revocation list (CRL) to Active Directory. Until the CRL objects exist, clients that look for the CRL in Active Directory cannot check whether a certificate is revoked. To create the objects, publish the CRL manually by using the certutil command with the -f option, which forces the command to create the objects.
Before you begin, make sure that the AD CS role is running on the cluster node, as described in Configure the AD CS Failover Cluster, so that the CA has published a CRL file.
To create the CRL objects in Active Directory:
Log on to the cluster node that currently owns the CA role, with Enterprise Admin permissions.
Open a command prompt as an administrator.
At the command prompt, type cd %WINDIR%\System32\CertSrv\CertEnroll, and then press Enter. This folder contains the CRL files. The base CRL file is named after your CA and ends in .crl.
Run the following command to publish the CRL to Active Directory, and then press Enter:
certutil -f -dspublish <CRL_file>
Replace <CRL_file> with the name of the base CRL file.
Verify that the output ends with a message that the command completed successfully.
Next, modify the CA configuration in Active Directory, as described in Modify CA Configuration in Active Directory.
Modify CA Configuration in Active Directory
AD CS stores information about the CA in several containers in Active Directory. The AIA container stores the CA certificate, the Enrollment Services container stores the CA enrollment object, and the KRA container stores the key recovery agent information if you use key archival. To let all cluster nodes update these objects when required, add the computer account of each additional cluster node to the security settings of each object. The first node already has access because it created the objects.
You can perform these tasks from any computer in your Active Directory configuration on which the Active Directory Sites and Services snap-in is installed. To modify the CA configuration in Active Directory:
Log on to the computer with Enterprise Admin permissions.
Click Start, click Run, type dssite.msc, and then click OK to open Active Directory Sites and Services.
In the left pane, click the top node. On the View menu, click Show Services Node.
In the left pane, expand Services and Public Key Services, and then click AIA.
In the details pane, click the object that has the name of your CA, as it appears in the Certification Authority console.
On the Action menu, click Properties. Click the Security tab, and then click Add.
In the Select Users, Computers, Service Accounts, or Groups dialog box, click Object Types, select the Computers check box, and then click OK.
In the Enter the object names to select box, type the computer name of the second cluster node, and then click OK. If your cluster has more than two nodes, add each additional node in the same way.
On the Security tab, select each cluster node's computer account, and then select the Allow check box for Full Control. Verify that all cluster nodes have Full Control permission, and then click OK.
In the left pane, click Enrollment Services.
In the details pane, click the object that has the name of your CA.
On the Action menu, click Properties. Click the Security tab, and then click Add.
In the Select Users, Computers, Service Accounts, or Groups dialog box, click Object Types, select the Computers check box, and then click OK.
In the Enter the object names to select box, type the computer name of the second cluster node, and then click OK. Add any additional nodes in the same way.
On the Security tab, select each cluster node's computer account, and then select the Allow check box for Full Control. Verify that all cluster nodes have Full Control permission, and then click OK.
Complete the next steps for the KRA container only if you configured key archival, as described in Key Archival and Recovery. If you did not, skip to the step that starts with "Close Active Directory Sites and Services."
In the left pane, click KRA.
In the details pane, click the object that has the name of your CA.
On the Action menu, click Properties. Click the Security tab, and then click Add.
In the Select Users, Computers, Service Accounts, or Groups dialog box, click Object Types, select the Computers check box, and then click OK.
In the Enter the object names to select box, type the computer name of the second cluster node, and then click OK. Add any additional nodes in the same way.
On the Security tab, select each cluster node's computer account, and then select the Allow check box for Full Control. Verify that all cluster nodes have Full Control permission, and then click OK.
Close Active Directory Sites and Services.
Wait for Active Directory replication to complete before you test the cluster. In a multi-site domain, this can take several minutes.
To verify the cluster, open Failover Cluster Manager, click Roles, right-click the CA role, point to Move, and then click Best Possible Node. Verify that the role starts on the other node and that its Status is Running.
The AD CS cluster is now set up.
Migrate AD CS Cluster Keys from Microsoft Software KSP to SafeNet KSP
This section explains how to migrate the CA keys that AD CS uses from the Microsoft Software Key Storage Provider (KSP) to the SafeNet KSP. After the migration, the AD CS cluster uses CA signing keys that are stored on the Luna HSM.
Before you start the migration, ensure that:
-
The AD CS cluster is operational and uses the Microsoft Software KSP.
-
The Luna Client is installed, and a partition is registered on each cluster node.
-
The SafeNet KSP is registered and configured on every cluster node. For instructions, see Configure SafeNet KSP.
-
You have the ksputil.exe utility. If you do not have it, contact Thales Customer Support.
-
You can log on to each cluster node as a local administrator.
To migrate the AD CS cluster from the Microsoft Software KSP to the SafeNet KSP, you must associate the CA key with the SafeNet KSP on each cluster node. The procedure has these stages:
-
Prepare the first node: remove the AD CS service from the cluster, back up the CA, and record the CA name, the thumbprint, and the unique key container.
-
Migrate the CA key to the Luna HSM on the first node, and verify the migration.
-
Create a key for each of the other nodes.
-
Associate the CA certificate with the key on the Luna HSM on each of the other nodes.
-
Add the AD CS service back to the cluster, and test the cluster.
To migrate the keys:
Log on to the first cluster node, which is the node where the CA keys were generated. In Failover Cluster Manager, click Roles, and then verify that the AD CS cluster role is running and that this node is its owner.
In Failover Cluster Manager, click Roles, and then click the AD CS cluster role. On the Resources tab, click Active Directory Certificate Services. In the Actions pane, click Remove. In the Remove Generic Service dialog box, click Yes.
Open the Certification Authority console from the Administrative Tools menu. Before you back up the existing CA database and keys, verify that Active Directory Certificate Services is running. If the service is not running, start it.
In the console tree, click the CA node. On the Action menu, click All Tasks, and then click Back up CA.
Complete the Certification Authority Backup Wizard to back up the CA database and key. For the wizard options, see Back Up the CA. When you are prompted for the backup location, select an empty directory. When the wizard is complete, click Finish.
In the console tree, right-click the CA node, and then click Properties. On the General tab, note the CA name and the current provider. In the CA certificates list, select the current CA certificate, click View Certificate, click the Details tab, and then click Thumbprint in the Field column.
Write down the CA name and the certificate thumbprint. You need them later when you migrate the key. For example:
CA name: EYHSM-CA Thumbprint: da205e29cb1e1ebaebc50dbe4458e0443baa769a
Click OK in the Certificate dialog box, and then click OK in the CA Properties dialog box.
Open a command prompt as an administrator. To find the unique key container of the CA certificate, run the following command, and then press Enter. Replace <CA_Certificate_Thumbprint> with the thumbprint of the CA certificate.
certutil -verifystore My <CA_Certificate_Thumbprint>
In the output, note the value of Unique container name. You need it later when you migrate the keys to the Luna HSM.
At a command prompt, go to the KSP folder of the Luna Client installation directory (by default, C:\Program Files\SafeNet\LunaClient\KSP). Run ms2Luna.exe, and then type the thumbprint of the CA certificate when prompted to migrate the CA key. For more information, see Migrate an MS CA onto a Luna HSM or Luna Cloud HSM Service Using ms2Luna.
Verify that the CA provider is now SafeNet Key Storage Provider. You can use either of the following methods. In the Certification Authority console, open the CA Properties dialog box, and check the provider on the General tab. Alternatively, run the following command, and then press Enter. Replace <CA_Certificate_Thumbprint> with the thumbprint of the certificate whose key you migrated with ms2Luna.exe.
certutil -verifystore My <CA_Certificate_Thumbprint>
In the output, verify that the values of Unique container name and Provider have changed.
In the output, verify that Encryption test passed appears. If the CA certificate is not associated with the key that was migrated to the Luna HSM, run the following command to repair the store, and then press Enter. Replace <CA_Certificate_Thumbprint> with the thumbprint of the CA certificate.
certutil -repairstore -csp "SafeNet Key Storage Provider" My <CA_Certificate_Thumbprint>
In the Certification Authority console, right-click the CA node, point to All Tasks, and then click Stop Service. Right-click the CA node again, point to All Tasks, and then click Start Service. Verify that the CA node shows a green check mark, which indicates that AD CS runs correctly after the key migration.
On the first node, use the ksputil utility to create a key for each of the other nodes in the AD CS cluster. At a command prompt, go to the KSP folder of the Luna Client installation directory, run the following command, and then press Enter. When you are prompted for the challenge for the slot, type the partition password.
ksputil clusterKey /s <SlotNum> /n <CA_Name> /t <TargetCluster_Host>
Replace <SlotNum> with the slot ID of the Luna HSM partition, <CA_Name> with the name of the CA, and <TargetCluster_Host> with the fully qualified domain name of the cluster node. When the command succeeds, the output reports that the CA key was successfully migrated to the target host.
Run the command once for each of the other nodes in the cluster. The command duplicates the same key and associates it with the cluster node, so that each node has access to the same key.
Log on to one of the other cluster nodes. Make sure that you created a key for this node in the previous step. In the following steps, you associate the CA certificate with the key that was created in the HSM for this node.
Open a command prompt as an administrator. To verify that the CA certificate is still associated with the Microsoft Software Key Storage Provider, run the following command, and then press Enter:
certutil -verifystore My <CA_Certificate_Thumbprint>
The thumbprint is the same on all nodes of the cluster, because the cluster uses the same key and certificate on each node. In the output, note the value of Unique container name, which identifies the container that holds the key.
Go to the C:\ProgramData\Microsoft\Crypto\Keys folder, and find the key container that matches the unique container name from the previous step. Right-click the container, and then click Delete.
Make sure that you delete the container whose name matches the unique container name from the previous step.
To associate the CA certificate with the key that was migrated to the Luna HSM, run the following command at the command prompt, and then press Enter. Replace <CA_Certificate_Thumbprint> with the thumbprint of the CA certificate.
certutil -repairstore -csp "SafeNet Key Storage Provider" My <CA_Certificate_Thumbprint>
When the command completes successfully, the output shows that Provider is now SafeNet Key Storage Provider and that Unique container name has changed.
Open Registry Editor, and go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA_Name>\CSP. Replace <CA_Name> with the name of your CA. Double-click Provider, change the value from Microsoft Software Key Storage Provider to SafeNet Key Storage Provider, and then click OK.
In Failover Cluster Manager, click Roles, and then click the AD CS cluster role. In the Actions pane, click Move, and then click Best Possible Node to assign the shared disk to the node that you are working on.
Open the Certification Authority console, and then start the CA service. When the service starts, open the CA Properties dialog box, and verify on the General tab that the provider is SafeNet Key Storage Provider.
Repeat the steps from "Log on to one of the other cluster nodes" through "Open the Certification Authority console, and then start the CA service" on each of the other nodes of the cluster. Continue to the next step only after you have associated the CA certificate with the key on the Luna HSM through the SafeNet KSP on every node, and you have confirmed that the CA service is active on each node while the shared disk is connected to that node.
Log on to any node where the shared storage is available and the CA service is running.
In Failover Cluster Manager, click Roles, and then click the AD CS cluster role. Click the Resources tab. In the Actions pane, click Add Resource, and then click Generic Service.
In the New Resource Wizard, on the Select Service page, select Active Directory Certificate Services, and then click Next. On the Confirmation page, click Next. When the Summary page appears, click Finish.
On the Resources tab, click Active Directory Certificate Services, and then click Properties in the Actions pane. In the Properties dialog box, click the Registry Replication tab, and then click Add. In the Registry Key dialog box, type SYSTEM\CurrentControlSet\Services\CertSvc (the dialog box adds the HKEY_LOCAL_MACHINE\ prefix), and then click OK. In the Properties dialog box, click OK to save the settings.
In Failover Cluster Manager, click Roles, and then click the AD CS cluster role. In the Actions pane, click Stop Role to stop the role.
In the Actions pane, click Start Role to start the role again, so that the new service resource comes online. Verify that the status of the role is Running.
Log on to each node of the cluster in turn, and verify that the CA service is running on the node that owns the role.
In Failover Cluster Manager, click Roles, and then click the AD CS cluster role. In the Actions pane, click Move, and then click Best Possible Node. Verify that the role starts and runs on the node that you are logged on to.
If the role starts and runs on that node, you have successfully migrated the CA keys from the Microsoft Software KSP to the SafeNet KSP, and the migration of the failover cluster to the Luna HSM is complete.
