Root CA key ceremony on ADCS and a Luna HSM: an end-to-end walkthrough

This is the hands-on companion to our chapter on why the restore proof matters more than the ceremony: an end-to-end root CA key ceremony for Microsoft ADCS with the CA key generated and held in a Thales Luna HSM, ending with the partition backed up to a Luna Backup HSM and — the step most scripts omit — the backup restored to a second HSM and proven to sign. Commands are for Luna HSM Client 10.x with a Luna Network HSM 7 or a locally attached Luna PCIe/USB HSM, on Windows Server 2019 or later; where syntax depends on client or firmware version, we say so inline rather than guessing.

Before the ceremony: what must already be true

A ceremony is a scripted, witnessed execution of decisions already made. Walking into the room, you should have:

• Roles assigned — a ceremony administrator who runs the script, an operator at the keyboard, credential custodians (partition SO, Crypto Officer, domain holders), and at least two witnesses who are none of the above. Separation of duties per your ceremony framework — we cover the design in the key ceremony and separation of duties chapter.
• A written script — every command pre-agreed, numbered, with an expected result and a sign-off box. Deviations get recorded, not improvised.
• The HSM estate initialised — the root CA partition and the backup HSM initialised into the same cloning domain, deliberately and on the record. That procedure is its own walkthrough: initialising a Luna HSM and setting the cloning domain correctly.
• Media and materials — the Luna Backup HSM (B700-series, or legacy G5), a second Luna HSM or spare partition for the restore proof, tamper-evident envelopes, physical labels, safes booked, and the CAPolicy.inf and CA parameters (key size, validity, CRL periods) printed in the script.
• The offline CA server built — Windows Server installed, patched from offline media, never domain-joined, never networked. If the root partition lives on a Luna Network HSM, the ceremony network is an isolated switch connecting only the CA server and the appliance.

Step 1 — Install the Luna client and KSP on the CA server

Install the Luna HSM Client from Thales-supplied media, selecting the CSP (CAPI) / KSP (CNG) component during installation — ADCS on any modern Windows Server uses CNG, so the KSP is the piece that matters. The exact component naming in the installer varies across client releases; what you need on disk afterwards is the KSP directory under the client installation path (by default C:\Program Files\SafeNet\LunaClient\KSP\) containing KspConfig.exe.

Then connect the client to the partition. For a network HSM that means the one-time NTLS certificate exchange and client registration (covered in the initialisation walkthrough linked above); confirm the partition is visible before going further:

lunacm:> slot list
lunacm:> slot set -slot 0
lunacm:> partition showinfo

Record the slot number and partition label in the ceremony record — the KSP registration in the next step binds to this partition.

Step 2 — Register the KSP against the partition

Run KspConfig.exe from the KSP directory as an administrator. Two registrations, in order, per the Thales ADCS integration guide:

• Register the security library. Double-click Register Or View Security Library, browse to cryptoki.dll in the Luna client installation directory, and register it. You should see “Success registering the security library!”.
• Register the slot — twice. Under Register HSM Slots, select the partition and enter the Crypto Officer password, registering it for the logged-in Domain\User (on a workgroup root, MACHINE\Administrator) and again for NT AUTHORITY\SYSTEM. The wizard may only display one entry after both registrations; that is a known cosmetic quirk — both are required, because ADCS setup runs as you but the CA service (certsvc) runs as SYSTEM.

That SYSTEM registration is the single most commonly missed step in ADCS-on-Luna builds, and getting it wrong produces a CA that installs perfectly and fails later — a trap with enough depth that it gets its own chapter next in the series. There is also a command-line registration utility (kspcmd) in the same directory; its syntax varies by client version and we have not verified every variant, so for a witnessed ceremony the GUI wizard is the safer, more screenshot-able choice. Verify the provider is visible to Windows before proceeding:

C:\> certutil -csplist

Provider Name: SafeNet Key Storage Provider
...

Step 3 — Install the ADCS root CA with the Luna KSP

Place your CAPolicy.inf in C:\Windows\ (CRL periods, no default templates, any policy statements your framework requires), add the role, then configure the CA selecting the SafeNet provider for key generation. Via PowerShell:

PS C:\> Install-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools

PS C:\> Install-AdcsCertificationAuthority `
    -CAType StandaloneRootCA `
    -CryptoProviderName "RSA#SafeNet Key Storage Provider" `
    -KeyLength 4096 `
    -HashAlgorithmName SHA256 `
    -CACommonName "Example Root CA G1" `
    -ValidityPeriod Years -ValidityPeriodUnits 20

The provider string follows the CNG <algorithm>#<provider name> pattern; confirm the exact provider name from your own certutil -csplist output rather than trusting this page — Thales’ current integration guide drives the same choice through the Server Manager configuration wizard (Select a cryptographic provider → SafeNet Key Storage Provider), which is equally ceremony-appropriate and shows the provider list explicitly. Either way, the key pair is generated inside the Luna partition during this step: this is the moment the root key comes into existence, and the script should mark it as such.

Step 4 — Verify the key is in the HSM, and that the CA can sign

Do not take the installer’s word for it. Three checks, all recorded:

C:\> certutil -verifykeys
C:\> certutil -crl

C:\Program Files\SafeNet\LunaClient> cmu list
Please enter password for token in slot 0 : ********
handle=xx    label=<CA key label>

certutil -verifykeys confirms the CA certificate matches a reachable private key through the KSP; certutil -crl forces the CA to issue a CRL — a real signature with the root key, which is the operation this CA exists to perform; and cmu list (the Luna client’s certificate management utility) shows the key objects actually resident in the partition. If cmu list shows no new objects, your key landed in a software provider and the ceremony stops here for root-cause, not later.

Step 5 — Back up the partition to the Luna Backup HSM

Connect the Backup HSM to the client workstation (or use an appliance-connected or Remote Backup Service arrangement for network HSM estates — the client-connected path shown here is the common ceremony setup). From LunaCM, with the source partition selected and the Crypto Officer logged in:

lunacm:> slot list
lunacm:> role login -name co
lunacm:> partition archive backup -slot <backup_slot> -partition RootCA_Backup_01

You will be prompted for the backup device’s SO credentials, a password for the new backup partition, and its domain — the backup partition must be created in the same cloning domain as the source, because objects transfer encrypted under domain-derived secrets. A domain mismatch fails the clone (typically surfacing as CKR_CERTIFICATE_INVALID) and, unhelpfully, can leave an empty backup partition behind — which is exactly why “the command completed” is not the success criterion. Version notes: if -partition is omitted on a Backup HSM 7 the partition is auto-named <source>_<YYYYMMDD>; partitions on firmware 7.7+ (V0/V1) need correspondingly recent backup-device firmware; and the -replace option is deprecated from client 10.7. Then verify what was written:

lunacm:> partition archive list -slot <backup_slot>
lunacm:> partition archive contents -slot <backup_slot> -partition RootCA_Backup_01

Record the object count and labels against the source partition’s contents. Matching counts is necessary — and still not sufficient. One more step.

Step 6 — Prove the restore

This is the step that separates a backup from a hope. On a second HSM — a test appliance, a spare partition, anything that is not the source hardware — initialise a partition into the same cloning domain, register the ceremony workstation against it, and restore:

lunacm:> slot set -slot <test_partition_slot>
lunacm:> role login -name co
lunacm:> partition archive restore -slot <backup_slot> -partition RootCA_Backup_01
lunacm:> partition archive contents -slot <backup_slot> -partition RootCA_Backup_01

Then prove the restored key signs. The cleanest method mirrors real disaster recovery: re-register the KSP slot mappings to point at the test partition’s slot, restart the CA service, and run certutil -verifykeys and certutil -crl again so the CA issues a CRL using the restored copy of the key — then verify that CRL’s signature against the root certificate. If your ceremony constraints don’t allow repointing the CA, a signing operation driven directly against the restored key object through the Luna tools is an acceptable fallback — but the CA-level proof is stronger, because it exercises the KSP registration you would depend on in a genuine recovery. Afterwards, destroy the restored copy: zeroise or re-initialise the test partition, witnessed, and record the destruction. You created a second instance of your root key to prove the backup; the proof is incomplete until that instance is gone. Finally, restore the KSP registration to the production slot and confirm certutil -verifykeys passes once more.

Step 7 — The ceremony record

The record is the artefact your assessor, and your successors, will actually use. At minimum it captures:

• Date, location, attendees and roles; the script version executed, with per-step sign-offs and any deviations.
• Hardware identities: serial numbers of the CA HSM, Backup HSM and test HSM; firmware and client versions; partition labels and slot numbers.
• The CA parameters as configured (provider string, key algorithm and length, validity, CRL periods) and the root certificate’s thumbprint.
• Cloning domain artefacts: which envelope or PED key holds the domain, who has custody, which safe — without recording the secret itself in the ceremony record.
• The restore proof: backup partition name, object counts backed up and restored, the test signature performed (e.g. CRL number and verification result), and the witnessed destruction of the restored copy.
• End state: which devices went into which safes, sealed envelope IDs, and the schedule for the next restore re-proof.

For the wider estate design this ceremony slots into — partitions, policies, HA, client architecture — see the comprehensive Luna HSM design and operational guide.

Where this leaves you

Your root is built, backed up, and — unusually — proven restorable, with a record that says so. The next problem is the online tier: issuing CAs talking to the Luna through the same KSP, where the NT AUTHORITY\SYSTEM registration you did in step 2 becomes a genuine operational trap with service accounts and reboots — that is the next chapter. The full series lives at The Luna Field Guide.