When a FreeIPA CA on an HSM is worth designing for
A FreeIPA CA on a hardware security module is worth designing for when your policy requires that the private keys of the certificate authority never exist in software on a server. This is typical for teams running a PKI that issues certificates trusted across many systems, where a compromised CA signing key would affect every certificate chain beneath it. The FreeIPA HSM design lets the Dogtag CA and its Key Recovery Authority (KRA) generate and store their private keys on a device reached through a PKCS#11 shared library. It covers a self-signed CA, a CA signed by an external root or intermediate, replica CAs, and KRA clones that use the same HSM-held keys. If your requirement is only that keys be protected at rest or that the CA be backed up, a software-held CA with tight host controls may be the proportionate choice, and you should be able to state which requirement you are meeting before choosing hardware.
Before committing, confirm three constraints from the FreeIPA HSM design. Installation is all or nothing, so the KRA cannot sit on an HSM while the CA stays in software. Only RSA keys are supported, which rules out designs that depend on elliptic curve keys for the CA. Finally, the HSM vendor's client libraries and SELinux policy must match your platform, since FreeIPA 4.12.0 shipped SELinux subpackages for Thales Luna and nCipher nfast support. Ask your HSM vendor and your operating system distribution whether the PKCS#11 library and the matching SELinux packages are available for your exact versions before you size the project.
Treat the HSM as a dependency of every CA server, not only the first one. Replicas that share HSM keys inherit the same operational exposure: a partition, failed device or expired HSM credential can stop certificate issuance on more than one host. Write down who owns HSM partitions, how key material is backed up and recovered under your HSM vendor's model, and how a failed device is replaced without rekeying the CA. These decisions shape the design more than the install command does, and they are the questions to put to any implementation partner or internal team before work begins.
Which HSM install case fits your CA design
This table compares the four HSM install cases FreeIPA's HSM design covers: a self-signed CA, an externally signed intermediate CA, replica CAs and KRA clones. Read each row for when the case fits, what your team must prepare and what to confirm with the HSM vendor or the design document before you commit.
| Install case | When it fits | What to prepare | What to confirm |
|---|---|---|---|
| Self-signed CA on an HSM | A new, private FreeIPA CA where IPA creates the root and you want its signing key generated and stored in the HSM | An HSM with a PKCS#11 shared library, a partition or slot for IPA, and a plan for PIN and credential custody | Your HSM's PKCS#11 library path and version, and that it supports RSA key generation as IPA requires |
| Externally signed CA on an HSM | An intermediate CA under an existing enterprise root, where the root key stays offline or in another system | A signing request for the intermediate CA, a root process that signs it, and HSM storage for the intermediate key | How your root signing process returns the issued certificate and chain, and that the HSM key can be used for the CA role |
| Replica CA sharing HSM keys | A multi-server FreeIPA topology with CA replicas that must sign with the same key material as the first CA | Replica servers with access to the same HSM partition, plus a tested replica install order and backup plan | Whether your HSM can present the same key objects to every replica, and how key access is audited and revoked per server |
| KRA clone using the same HSM keys | Deployments that need key archival and recovery, with the KRA holding its keys in the same HSM as the CA | The KRA on HSM installed only after the CA is on HSM, and a documented recovery procedure | That the KRA key objects are created and stored in the HSM in your design, and how recovery is tested in your environment |
| Mixed installation (CA on HSM, KRA on software) | Not supported under the all-or-nothing rule, so this is a design to avoid, not an option | Nothing to build for this case. Plan both CA and KRA on the HSM or both in software | Confirm the current rule in the design document before any change to the plan |
| Any case using non-RSA keys | Not supported, since only RSA keys are covered by the design | RSA key size and algorithm choices written into the CA profile before install | Confirm the CA signing algorithm and key type with your security team and the design document |
| Vendor SELinux packages (Thales Luna, nCipher nfast) | Environments using these HSM families on RHEL-based hosts with SELinux enforcing | Installing the matching vendor subpackage that FreeIPA 4.12.0 lists for HSM support | The package name and version for your HSM firmware, and that your OS release has a matching build |
Constraints that decide whether an HSM install is possible
Four constraints determine whether a FreeIPA CA can move its private keys onto an HSM and how the deployment must be built around that choice. Each one changes a decision made before installation starts, so they should be checked against the target design first, not after servers are already enrolled.
All or nothing installation
Either the CA and KRA both keep their keys on the HSM, or the design has no HSM for this deployment. A KRA cannot sit on an HSM without the CA doing the same, so a team that wants key archival protected in hardware must also accept hardware-backed CA keys. Decide early whether the KRA is needed at all, because adding it later changes the HSM layout. Confirm the plan with the HSM vendor and the FreeIPA design before ordering hardware.
RSA keys only
The FreeIPA HSM design supports only RSA keys for CA and KRA material. Teams that plan elliptic-curve certificates for internal services, or that want to match a corporate key standard, must reconcile that with the CA key type before install. The restriction also affects the capacity planning of the HSM, since RSA key generation and signing load differ from EC workloads. Ask the vendor which RSA sizes the module handles at the expected issuance rate.
Shared keys across replicas
Replica CAs and KRA clones can use the same HSM keys, which is what allows a multi-server CA to keep one signing identity. The design consequence is that every replica must reach an HSM partition holding those keys, so network paths, partition credentials and failover of the HSM itself become part of the replication plan. Restoring an outdated backup into an active topology can also break replication, so backups must be taken and restored with the HSM state in mind.
Vendor fixed PKCS#11 library
FreeIPA reaches the HSM through a PKCS#11 shared library, and that library comes from the HSM vendor. The choice of hardware therefore fixes the library path, its version and its SELinux support. The FreeIPA 4.12.0 release notes list SELinux subpackages for Thales Luna and nCipher nfast, so teams using other modules must confirm the packaging and policy story themselves. Ask the vendor for the library version tested with the target FreeIPA release and for the SELinux policy it ships.
Thales Luna and nCipher nfast support in FreeIPA 4.12
The FreeIPA 4.12.0 release notes list an SELinux subpackage for Thales Luna HSM support. The subpackage matters because the Dogtag CA and KRA reach the HSM through a PKCS#11 shared library, and SELinux policy must allow that access from the server processes. Treat the subpackage as a starting point. It does not certify that your Luna appliance, firmware and client combination is a tested configuration, so the checks below belong in your pre-install plan.
- Install the matching package: Confirm the Luna SELinux subpackage is available for your FreeIPA 4.12 build and your operating system release before you schedule the install.
- Library path: Record the exact PKCS#11 library path the Luna client installs, and confirm it is the path you will pass to the installer.
- Firmware and client versions: Ask the vendor which Luna firmware and client versions it supports with your FreeIPA release and operating system.
- Vendor PKCS#11 statement: Get the vendor's written statement on PKCS#11 support for the Dogtag key operations you need, including RSA key generation and storage.
- Replica hardware: Check that every replica that will hold CA or KRA keys has an equivalent Luna client and partition configuration.
Confirm each item in a lab that mirrors production before you touch the CA on a live deployment.
The FreeIPA 4.12.0 release notes also list an SELinux subpackage for nCipher nfast HSM support. The same PKCS#11 model applies: the Dogtag processes load a vendor library, so the library location, its permissions and the SELinux labels around it all have to line up. The subpackage is a packaging fact from the release notes, not proof that your nfast hardware and software level has been validated end to end with the CA and KRA.
- Install the matching package: Confirm the nfast SELinux subpackage matches your FreeIPA 4.12 build and your operating system version.
- Library path: Identify the PKCS#11 library installed by the nfast client and confirm the path and file permissions the CA service account can read.
- Firmware and client versions: Ask the vendor which Security World, firmware and client versions it supports with FreeIPA 4.12.
- Vendor PKCS#11 statement: Obtain the vendor's support statement covering PKCS#11 operations used for CA and KRA keys, and whether it covers replica CAs.
- Key type limits: Confirm the key type you plan to use is RSA, because FreeIPA's HSM design supports only RSA keys.
Record the answers next to the library path in your install runbook so the platform and security teams sign off on the same versions.
Whichever HSM family you use, the release notes give you the package signal and the design page gives you the operating rules. Neither source replaces a test install with your own hardware. The tab on each vendor lists what to confirm, and the steps below apply to both families and should be completed before anyone starts the CA installation.
- Version matrix: Write one table that lists FreeIPA version, operating system, SELinux policy, HSM firmware, client version and PKCS#11 library path.
- Lab proof: Install a test CA on the matrix, create a replica and confirm the KRA behaves as expected before production work.
- Vendor support in writing: Ask the vendor to confirm in writing that its PKCS#11 library and firmware are supported for this FreeIPA release.
- Recovery plan: Document how you restore keys and the HSM partition if the appliance fails, since the all-or-nothing rule applies.
- Ownership: Name who owns the HSM client upgrades, because a vendor client change can break the CA service.
Do not schedule production installation until every version in the matrix has a documented, tested path.
How to plan and sequence an HSM-backed CA install
This sequence moves FreeIPA's CA and, if chosen, KRA private keys into an HSM in an order that keeps the design decisions, vendor components and replicas consistent. Each step ends with a check so the team knows it can move on.
Confirm the CA design and key type
The architect decides whether the CA will be self-signed or externally signed, since the FreeIPA HSM design covers both cases. The team confirms that CA keys will be RSA, because only RSA keys are supported, and decides whether KRA is included, because HSM installation is all or nothing and the KRA cannot sit on an HSM without the CA. Read the FreeIPA HSM design before signing off. Done when a written design note records the signing model, key type and KRA decision, and the security owner has approved it.
Install the vendor PKCS#11 library and SELinux package
The platform team installs the vendor PKCS#11 shared library on every server that will hold HSM keys, including future replicas. Where a supported vendor SELinux subpackage exists, it is installed too. The FreeIPA 4.12.0 release notes list SELinux subpackages for Thales Luna and nCipher nfast, so confirm that your vendor and FreeIPA release match before you install anything. Done when the vendor client tools on each server list the expected HSM slot without FreeIPA involved, and the SELinux package is present on each host.
Prepare the HSM partition and service credentials
The HSM administrator creates a partition for the CA, along with the credentials the installer will use to log in to it. The team decides how the PIN or password will be supplied to the installer and keeps it out of shell history, configuration files and ticket comments. The administrator confirms that the account can log in and create and remove keys in that partition. Done when the team can authenticate to the partition from each server that will host the CA, and the token label and slot are written into the install runbook.
Run the first server install with HSM options
The installer runs on the first server only, with the HSM options described in the FreeIPA HSM design pointing at the vendor library, token and credential source. Replicas are added later, after the first CA is verified. Keep the install output and the exact options used in change records, because replicas must match them. Done when the installer completes without errors and the CA responds to a basic status query from the server itself.
Verify key location and certificate chain
The team checks that the CA signing key is an object in the HSM and not a file in the Dogtag database on disk. The vendor tool lists the key objects on the partition, and the operator confirms that the CA certificate chains to the root expected in the design. For an externally signed CA, the chain must reach the external root that was agreed in step one. Done when the signing key appears on the HSM, the chain validates, and the results are saved to the change record. A typical check is
openssl verify -CAfile root.pem ca.pem, with the file names adjusted to your environment.Plan replica CAs and KRA clones on shared keys
Replica CAs and KRA clones can use the same HSM keys, so each new replica needs the same library, SELinux package and partition access as the first server. The team applies the replica count and placement guidance from the FreeIPA deployment recommendations, including at least one replica per datacenter running PKI. Before a replica is treated as ready, its operator confirms that it sees the same key objects and can complete a test certificate request. Ask the HSM vendor to confirm how partition access and client licensing apply to each additional server. Done when every planned replica passes the same key and certificate checks as the first server.
Security and operations for HSM-held CA keys
Moving the FreeIPA CA and KRA keys into an HSM changes who can sign certificates, how keys are recovered and which server does the routine CA work. The cards below cover the operational decisions that follow from that change, and what to confirm with your HSM vendor and your own team before the install starts.
Key custody and HSM credentials
Decide who holds the HSM partition password, the PIN or the client credentials that let the Dogtag process reach the keys through the PKCS#11 library. Those credentials are as sensitive as the CA key itself, because anyone holding them can use the key without touching FreeIPA. Record which administrators can log in to the HSM, how credentials are rotated, and how access is logged and reviewed on the HSM side.
HSM backup versus ipa-backup
An ipa-backup run captures the FreeIPA directory, configuration and CA database, but the private keys live in the HSM and are not part of that archive. Recovery therefore needs the HSM vendor's own backup or key-replication mechanism for the partition, tested separately. Confirm with your HSM vendor how partitions are backed up, where those backups are stored, and how a restored partition is matched to the FreeIPA server it serves.
Losing the HSM or its credentials
If the HSM fails, is decommissioned or its credentials are lost, the CA may be unable to sign new certificates or renew existing ones, and CRL publication can stop. The all-or-nothing install rule means the KRA is also affected if it depends on the same HSM. Ask your vendor how a lost partition is recovered, how long that takes in your environment, and whether a documented exit path exists before you commit to an HSM-backed CA.
SELinux policy and library trust
Vendor HSM support depends on SELinux subpackages that the FreeIPA 4.12.0 release notes list for Thales Luna and nCipher nfast. Install the package that matches your HSM, keep the PKCS#11 shared library under the path your vendor documents, and avoid loosening SELinux to get past denials. Verify the library file's ownership and permissions, and confirm that updates to the HSM client software are tested on a replica before production.
First server role in renewal and CRL
By default, the first server in a FreeIPA topology handles certificate renewal and CRL publication. With HSM-held keys, that server also depends on the HSM being reachable at the moments those jobs run. Plan which server holds that role, confirm how it fails over, and check that the HSM connection works from every CA-capable replica you intend to promote, not only from the first server.
Restoring into a replica topology
The backup documentation warns that restoring an outdated backup into an active replica topology can break replication. Combined with HSM-held keys, a restore must also match the key material the HSM still holds for each CA and KRA instance. Write a restore runbook that covers the directory, the CA database and the HSM partition, and rehearse it on a non-production copy before you need it.
Questions teams ask before an HSM-backed FreeIPA CA
What drives the cost and effort of an HSM install for FreeIPA?
The main drivers are the number of CA and KRA servers that will share HSM-held keys, whether the CA is self-signed or signed by an external authority, and how many HSM partitions, clients and network paths must be configured. Costs split into HSM vendor licensing and hardware you may already own, the internal time of your HSM, PKI and Linux teams, and any partner work for design, install and testing. One-time work covers design, installation and validation. Recurring work covers HSM firmware and client updates, certificate renewal checks and backup testing. Ask any partner for a written scope that lists each server, each HSM interface, the cases covered and the test evidence delivered.
Can our team install an HSM-backed FreeIPA CA without outside help?
A capable team can, provided it has people who know FreeIPA installation, Dogtag, PKCS#11 and the HSM vendor's client tooling, and it reads the HSM design before starting. The hard parts are the all-or-nothing rule, which means the KRA cannot sit on an HSM without the CA, the RSA-only key limit, and getting the vendor's PKCS#11 library and SELinux packages matched to your release. Mistakes in these areas are costly to unwind, so many teams test the full sequence in a non-production environment first. Outside help is most useful for design review and a rehearsal of the install and restore procedures.
What does the work need from our HSM admins, PKI owners and Linux admins?
Each group owns a different part of the work:
- HSM admins create partitions or slots, manage client credentials, and confirm the PKCS#11 library version is supported on the target platform.
- PKI owners decide the CA chain, signing model for external CAs, certificate profiles, and key retention and backup rules.
- Linux admins prepare the FreeIPA servers, install the vendor SELinux packages, configure the HSM client on each replica, and run backup and restore tests.
Agree these responsibilities and a single change window before any server is touched, because replicas sharing HSM keys depend on each other.
How long does an HSM-backed FreeIPA CA take to deploy?
Duration depends on the design and your environment, and no fixed figure applies to every deployment. Key variables include whether the CA is self-signed or externally signed, how many replica CAs and KRA clones will share keys, how quickly HSM partitions and access can be approved, and how much testing your change process requires. Procurement lead times for HSM hardware or licenses often take longer than the FreeIPA work itself. Ask for a timeline in the written scope that shows design, lab validation, production change, and restore testing as separate phases with named owners.
Can we move an existing software-based FreeIPA CA onto an HSM?
The FreeIPA HSM design describes installation with keys generated and stored on an HSM, covering self-signed and externally signed CAs, replica CAs and KRA clones. Moving keys from an existing software CA is a different task and needs careful review before anyone attempts it, because the keys, certificate chain, renewal behavior and backups all change. Confirm with the FreeIPA project and your own PKI owners whether an in-place conversion is supported for your version and CA type. If it is not, plan a new CA hierarchy and a controlled cutover instead.
What should we ask for in a written quote for this work?
Ask the provider to state the exact scope in writing: the number of FreeIPA servers and whether each runs the CA or KRA, the CA type (self-signed or externally signed), the HSM model and PKCS#11 library, and the RSA key requirement. Request a list of deliverables, such as a design document, install runbook, SELinux configuration record, backup and restore test evidence, and a handover session. Also ask which items are fixed, which depend on your HSM vendor, what you must provide before work starts, what is excluded, and what ongoing support, if any, is priced separately.
What are the main security risks of putting FreeIPA CA keys in an HSM?
The main risks are losing access to HSM-held keys, misconfigured HSM access that weakens key protection, and restoring an outdated backup into an active replica topology. Because the HSM is all or nothing and supports only RSA keys, design choices made early are hard to change later. Confirm your HSM backup and recovery method, record who holds HSM credentials, and test restoration into a lab before production use. Review the FreeIPA backup documentation with your team so that replica and certificate renewal behavior is understood before any change.
How DeployOpen scopes an HSM-backed FreeIPA CA
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including FreeIPA. For an HSM-backed FreeIPA CA, the work starts with a written scope that settles the install case, the HSM model and the replica plan before any server is touched.
How we scope
- Confirm whether the CA is self-signed or externally signed, since the two install paths differ.
- Record the HSM model, PKCS#11 library version and vendor SELinux package for each server.
- Decide early whether the KRA is in scope, because it cannot sit on an HSM without the CA.
How we build
- Verify RSA key generation and signing on the HSM in a non-production FreeIPA install first.
- Plan replica CA and KRA clones so they share the HSM keys as the design requires.
- Test certificate issuance, renewal and CRL publication against the HSM before go-live.
How we hand over
- Deliver a runbook covering HSM partitions, library paths, SELinux settings and key ownership.
- Document the backup and restore procedure, including how HSM-held keys are handled during recovery.
- Walk your team through renewal, failover and the steps to take when the HSM is unavailable.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer.
- Ask your HSM vendor and your FreeIPA release to confirm compatibility before any upgrade is scheduled.
