Azure Cloud HSM — ED25519 (NID_ED25519) token key generation fails cluster replication with 0x000000ac on 2/3 nodes

Question

Has anyone successfully created a persistent ED25519 key on Azure Cloud HSM across all 3 cluster nodes?

I've been trying to generate an ED25519 key pair for Solana transaction signing on Azure Cloud HSM and hit a wall with cluster replication. Sharing full details in case anyone has seen this or found a workaround.

Hardware: NITROX-III CNN35XX-NFBE

Firmware: CNN35XX-NFBE-FW-2.09-0702 (latest — confirmed per F5 K000149742)

SDK: 2.0.2.5 / Client 2.09.07.02

OS: Ubuntu 22.04

Cluster: 3-node Azure Cloud HSM

What I'm trying to do:

Generate a persistent ED25519 key pair in Azure Cloud HSM to sign Solana transactions via PKCS#11 (CKM_EDDSA / 0x1057).

---

What's happening:

Every attempt to create an ED25519 token key (genECCKeyPair -i 28) fails on 2 of 3 nodes with 0x000000ac: Invalid inputs passed:

Command:  genECCKeyPair -i 28 -l solana-key -nex

Cfm3GenerateKeyPair returned: 0x3000008a
  Node 1: 0x00000000 SUCCESS  ← always the primary/load-balanced node
  Node 2: 0x000000ac Operation Failed. Invalid inputs passed
  Node 3: 0x000000ac Operation Failed. Invalid inputs passed

---

What I've already ruled out:

✅ Hardware supports ED25519 — session key generation (-sess) succeeds perfectly:

genECCKeyPair -i 28 -l solana-key -sess
→ 0x00 SUCCESS — public/private handles returned

I've verified the full signing pipeline works with session keys — ED25519 key generation, public key extraction, CKM_EDDSA signing, and broadcasting a signed Solana transaction all work correctly.

✅ P-256 token keys work fine on all 3 nodes — ED25519 is specifically broken, not EC keys in general.

✅ -min_srv 1 -timeout 30 does not help — nodes are actively rejecting the operation, not just unreachable. The key gets rolled back entirely:

findKey -t 3 -l solana-key → Total number of keys present: 0

✅ Manual syncKey also fails — even after a partial creation on node 1, manually pushing the key handle to nodes 2 and 3 returns the same error:

syncKey <handle> 1
→ insertMaskedKeyObject failed: HSM Error: Operation Failed. Invalid inputs passed

✅ CKM_EDDSA (0x1057) is in the PKCS#11 mechanism list — this isn't a missing mechanism issue.

✅ getKeyDiffMap 0 0 0 reports 0 real keys — findAllKeys shows phantom handles left over from failed attempts, but getKeyInfo on those handles returns "Key not found". The replication failure leaves stale index entries.

---

My conclusion:

The CNN35XX-NFBE firmware's inter-node replication protocol doesn't support serializing ED25519 key material. The chip itself handles ED25519 fine — it's purely the cluster sync layer that rejects it.

Since CNN35XX-NFBE-FW-2.09-0702 appears to be the latest available firmware for this chip, I'm not sure if this is a known limitation, a bug pending a fix, or something that requires a config change I'm missing.

Answer 1

ED25519 keys must be generated inside Azure Cloud HSM using the supported tools so that they are created as true HSM keys and correctly handled by the service. The documented guidance is:

• Do not use openssl genpkey or openssl ecparam with -engine azcloudhsm_openssl for ED25519 or other EC key types, because this produces software keys rather than HSM-resident keys.
• For ED25519, use azcloudhsm_util (or the Azure Cloud HSM OpenSSL engine in the way documented for Cloud HSM) to create the key within the HSM.

The documentation does not describe any known limitation or error pattern for ED25519 token-key replication across nodes like the 0x000000ac failures described. It only states that ED25519 keys can be generated using azcloudhsm_util or the OpenSSL engine for Azure Cloud HSM, and that these are “typically used for self-signed certificates or in certificate signing processes that directly use the private key.”

Given the context, the supported path is:

1. Use azcloudhsm_util to generate the ED25519 key pair as an HSM key (not via openssl genpkey/ecparam).
2. After creation, wait up to 24 hours to allow service-side synchronization and backups to complete before relying on the key, and verify that the key is present on all nodes using the management utilities.
3. If a key is missing on any node, use the documented synchronization flow:
   • Start the management utility:

          ./azcloudhsm_mgmt_util ./azcloudhsm_resource.cfg
     

   • Log in as Cryptography Officer (CO) and verify login success on all nodes.
   • Use findAllKeys 0 0 to list key handles per node and identify any missing keys.
   • Use syncKey <KeyHandle> <ServerId> for each node where the key is missing, then re-run findAllKeys 0 0 to confirm consistency.

If ED25519 token-key creation or syncKey continues to fail with “Invalid inputs passed” on some nodes even when using azcloudhsm_util as recommended, this behavior is not covered in the available documentation and would require opening a support case for Azure Cloud HSM so that the service team can review firmware/HSM logs and confirm whether there is a product limitation or defect.

---

References:

• Troubleshoot Azure Cloud HSM
• PKCS#11 library for Azure Cloud HSM
• Key management in Azure Cloud HSM
• Synchronize users and keys across Azure Cloud HSM nodes