Offline root CA and private PKI for air-gapped networks

An offline root CA keeps the most sensitive key off every network while online issuing CAs handle daily certificates. This page explains how to design, platform choices, and what to ask a partner.

On this page

Why an air-gapped PKI is designed differently: an offline root CA and private PKI for air-gapped networks

An enclave that cannot reach the internet still needs TLS, mutual TLS and device or user certificates, and it cannot rely on public OCSP responders or CA-hosted CRLs to check them. The design answer is that the root CA stays offline on a machine that never touches a network, and only issuing CAs run online inside the enclave. The root signs intermediate certificates during scheduled key ceremonies, then goes back into storage. Every day-to-day issuance, renewal and revocation happens on the online tier, so the root's key material is exposed only when someone deliberately performs a ceremony.

Three consequences shape the rest of the design. First, lifetimes must be planned around the ceremony calendar: the root and intermediates need validity periods long enough that a signing ceremony is rare, while leaf certificates stay short enough to be renewed inside the enclave without manual steps. Second, revocation cannot depend on external endpoints, so CRL distribution points and publication must be hosted inside the enclave, and you must confirm which component publishes CRLs and how often. Third, anything crossing the boundary, including software packages, container images and CRL files, needs an import process with integrity checks. Confirm how your platform's updates and rules reach the enclave, and record that path as a supply chain control.

On platforms, step-ca (Apache-2.0) is a strong fit for automated X.509 issuance with ACME and provisioners, with CA keys protected in an HSM, cloud KMS or YubiKey. OpenBao PKI (MPL-2.0) fits teams already standardizing on OpenBao for secrets and keys. FreeIPA, which bundles the Dogtag certificate system with its directory and Kerberos services under GPL-3.0-or-later, fits Linux-heavy estates. Test each option against your HSM, CRL hosting and offline update requirements before choosing.

Which requirements shape an air-gapped CA build

This table maps the regulatory requirements most likely to touch an offline PKI to the design decisions they influence. Read each row as a question to settle with your assessor or regulator before the key ceremony, because none of these rules prescribes a specific PKI design.

RequirementWhat it asks forWhat it means for the CA build
45 CFR 164.312 access control and unique identificationUnique user identification and access control for systems containing ePHIIssuing and administrative roles on the CA need named individuals, not shared operator accounts. Map each key ceremony role to a unique identity and record it.
45 CFR 164.312 audit controlsMechanisms that record and examine activity in systems containing ePHICeremony logs, issuance logs and CA configuration changes should be retained in the enclave. Confirm with your assessor which events they expect to see.
16 CFR 314.4 multi-factor authenticationMFA for any individual accessing any information system, per the FTC Safeguards RuleCA administration and HSM or smart card access need MFA, often through hardware tokens. Confirm whether the enclave's identity provider covers PKI admin consoles.
16 CFR 314.4 logging and monitoringMonitoring and logging of authorized user activityForward CA and OCSP or CRL publication logs to the enclave's log platform. Confirm retention periods with your regulator or counsel.
NERC CIP-013-2 supply chain integrityProcurement processes that verify software integrity and authenticity of vendor software and patchesEvery package, container image and CRL tool carried across the boundary needs a verified checksum or signature record. Keep a transfer log for each media import.
NERC CIP-005-7 remote accessInteractive Remote Access to high and medium impact BES Cyber Systems passes through an Intermediate System with encryption and MFA, with methods to detect and disable vendor sessionsIf the CA serves OT or BES Cyber Systems, admin access to the offline root and issuing CAs must not bypass the intermediate system. Confirm the impact rating of the systems in scope.
Regulations do not prescribe a PKI designOutcomes such as access control, logging and integrity, without naming a hierarchy, HSM or CRL methodHierarchy depth, key storage, lifetimes and CRL cadence are your design choices. Ask the assessor which evidence they accept for each one.
Assessor and regulator confirmationInterpretation of how each rule applies to your systems and dataConfirm scope, which systems hold ePHI or cardholder or customer data, and whether an external framework such as NIST SP 800-53 applies to your contracts.

How an offline root and online issuing CAs fit together

The offline root signs only intermediate CA certificates, and it does so during scheduled key ceremonies rather than as a running service. Below it sit one or more online issuing CAs inside the enclave, which hold their own keys, sign end-entity certificates for services and devices, and answer enrollment requests from ACME clients, step-ca provisioners or FreeIPA Dogtag. A two-tier design (root plus issuing CAs) suits most enclaves. A three-tier design adds a policy or intermediate layer when different business units or trust domains need separate issuers under one root. Either way, the root key never sees a network, and every issuer certificate it produces is a deliberate, recorded act.

Revocation and renewal depend on the root being offline, so plan both before the first ceremony. Issuing CAs publish their own certificate revocation lists (CRLs) or OCSP responses from inside the enclave, and relying systems must be able to reach those endpoints. The root only needs to publish its own CRL, and that happens rarely, so it can be scheduled around ceremonies. Revoking an issuing CA is the expensive case: it requires a ceremony and a new issuer certificate, and every certificate that issuer signed becomes untrusted at once. In FreeIPA, the first server handles certificate renewal and CRL publication by default, which is a design choice to confirm before any replica is retired.

Issuing CA lifetimes must be fixed before the root signs them, because an issuer cannot outlive its own certificate. A useful check is to list the longest end-entity lifetime you intend to issue, add the renewal window and the time needed to re-issue the issuer before its expiry, and confirm that the root's certificate covers all of it. Record each lifetime in the ceremony script so that the expiry date of every key is known to the operations team years in advance. Confirm with your PKI implementer how the chosen platform handles issuer rollover and whether it supports the key storage you require, since step-ca, OpenBao and Dogtag differ in how they store and renew issuer keys.

Which open source platforms fit an air-gapped PKI and why

The four options below differ in what they issue, how they automate renewal and how they integrate with identity. Each has a different fit for an offline root and online issuing CAs inside an enclave, so pick by estate and automation needs, then confirm offline support and HSM integration in the exact version you plan to deploy.

step-ca for automation-heavy stacks

step-ca is Smallstep's open-source online certificate authority, licensed under Apache-2.0. It issues X.509 certificates for TLS and mutual TLS and short-lived SSH certificates, supports ACME for automated renewal, and authorizes requests through ACME, OIDC, cloud instance identity and JWK provisioners. For an air-gapped design, it can run as an online issuing CA beneath an offline root, with CA keys protected in an HSM, cloud KMS or YubiKey. Confirm which of those key stores your chosen version supports inside your enclave.

OpenBao PKI for secrets-centric teams

OpenBao manages, stores and distributes secrets, certificates and keys. It is licensed under MPL-2.0 and hosted under the OpenSSF, and its PKI engine suits teams that already keep credentials there and want certificate issuance under the same policy and audit model. Its strength is the combined secrets and PKI surface, so review whether the PKI engine, its CRL handling and its HSM options meet your root ceremony requirements. Confirm each in the release you deploy, since the engine's offline behavior is not something to assume.

FreeIPA Dogtag for Linux estates

FreeIPA combines 389 Directory Server, MIT Kerberos, the Dogtag certificate authority, SSSD on clients and optional DNS and NTP in one integrated identity system. It is licensed under GPL-3.0-or-later and is a community project with no paid edition of its own, so support comes from your vendor or partner. Its appeal in an enclave is that certificates, users and host identity share one directory. Plan replica counts and backups carefully, and note that release 4.13.4 fixed two CVEs, including LDAP access control flaws, so patch cadence matters.

HashiCorp Vault licensing caveat

HashiCorp Vault version 1.15.0 and later is licensed under the Business Source License 1.1 with IBM named as licensor. That license is not OSI-approved open source, so it may fail a policy that requires open source components. Confirm your organization's license rules before shortlisting Vault, and if you need its PKI features, compare them against OpenBao, which is MPL-2.0 licensed. Read the license file for the exact terms that apply to the version you are considering.

How the air-gapped PKI is deployed across trust zones

In a fully disconnected enclave, the root CA, the issuing CAs, the revocation publication points and every client sit inside one closed network with no route to the internet or to other corporate networks. The trust boundary is the enclave perimeter itself. Nothing enters or leaves automatically, so the operating team must pre-stage everything the PKI needs: CA software packages, container images, OS updates and the trust anchors that relying systems will use. Kubernetes control plane images can be fetched in advance with kubeadm and pointed at a private registry, and GitLab documents offline self-managed deployment, which are useful examples of how software is carried into a closed network.

  • What crosses the boundary: Signed packages, container images, rule and policy updates, and any new trust material, all verified against published hashes or signatures before import.
  • Who transfers: A named custodian team outside the enclave prepares the media, and a second person verifies the import inside.
  • Key custody: Root and issuing CA keys never leave the enclave, and HSM or hardware token administration happens locally under dual control.
  • Revocation: CRLs are published from inside the enclave only to internal endpoints, so every relying system must reach those URLs.

Confirm with your assessor whether the enclave's transfer procedure satisfies your control framework before building it.

How root key ceremonies are run and recorded

A root key ceremony turns the generation and signing of the root certificate authority into a scripted, witnessed and recorded event, so the organization can later prove who did what, on which hardware, and with which software. The sequence also fixes how issuing CA certificates are signed and how activation material is held. The record it leaves behind is the primary evidence an assessor will review.

  1. Prepare the ceremony room and hardware

    Before the ceremony, the team confirms the offline host or HSM, the operating system image and the ceremony tooling are the versions approved in the key management plan. Media is verified against published hashes, and the host is confirmed to have no network interfaces enabled or connected. The ceremony lead signs a pre-ceremony checklist that lists every device, serial number and media item in the room. The checklist is the first page of the ceremony record.

  2. Run the scripted root key generation

    The team runs a written script, reviewed in advance, that generates the root key pair on the offline host or inside the HSM. The key is generated under a defined algorithm and key size taken from the certificate policy, and the script logs each command and its output to a file on write-once media. Witnesses confirm the terminal session matches the script line by line. The ceremony is complete for this step when the public key and its fingerprint are written to the record.

  3. Issue the self-signed root certificate

    The root certificate is self-signed from the root key using the profile in the certificate policy, which sets the basic constraints, key usages, validity period and name constraints where the design uses them. The certificate's serial number, subject, validity dates and fingerprint are read back aloud and entered into the record. An independent witness compares the printed fields with the policy document. The step closes when the root certificate and its fingerprint are copied to media and recorded.

  4. Sign issuing CA certificates

    Each online issuing CA submits a certificate signing request, which is transferred to the offline host on approved media and checked against the issuing CA request register. The root signs only the requests that match an approved entry, with the path length and lifetime set in the policy. The signed issuing CA certificates are verified against the root public key before they leave the room. The output is a signed certificate per issuing CA and a matching entry in the signing log.

  5. Assign and record activation material custody

    Activation material, such as HSM operator cards, PINs, passphrase halves or smart cards, is split so that no single custodian can use the root alone. Each custodian receives a sealed item and signs a custody acknowledgment that names the item, its storage location and the conditions for access. The ceremony record lists which custodian holds which item. Custody is confirmed when the signed acknowledgments are filed with the record and the sealed items are placed in their assigned storage.

  6. Hash and seal the ceremony output

    The ceremony output, including the script, transcripts, certificates, CRL seed files and the checklist, is hashed with a published algorithm and the hash list is written into the record. Two copies of the output go to separate approved storage locations, and the hash list is signed by the witnesses. The team then verifies the copies against the hash list before sealing the media. Completion means every file in the output has a recorded hash and the witnesses have signed the hash list.

  7. Retain the record for assessor review

    The completed record is organized so that an auditor can trace each control: the approved key management plan, the root certificate policy, the pre-ceremony checklist, the transcripts, the custody acknowledgments and the hash list. Confirm with your assessor and your own retention policy how long the record and media must be kept, since those periods depend on your framework and sector. The record is reviewed by someone outside the ceremony team before it is filed. The step is complete when the index maps every control to its evidence.

What auditors and assessors ask for from an offline PKI

This table lists the evidence an assessor typically asks to see for an offline root and online issuing CA, and which component produces each item. Use it to plan logging and record keeping before the first key ceremony, not after. Confirm required formats and retention periods with your assessor, since they vary by framework and by the auditor's own methods.

Evidence itemWhat it showsProducing componentWhere it usually falls short
Root ceremony scripts and signed recordsSteps, roles and witnesses used to generate the offline root key and sign the issuing CA certificatesWritten ceremony script, witness signatures, HSM or hardware key initialization outputScripts written after the ceremony, or witness sign-off missing for one step
Certificate policy and hierarchy diagramsWhich CA signs what, certificate profiles, lifetimes and key usages for each tierCertificate policy document, hierarchy diagram kept under version controlDiagram no longer matches the live issuing CA profiles after a later change
Issuance logs from the online CAWho or what requested each certificate, through which provisioner or auth method, and whenstep-ca logs and provisioner configuration, Dogtag records in FreeIPA, OpenBao PKI audit devicesLogs rotated locally with no copy kept inside the enclave or in an approved archive
CRL publication recordsThat revocation data was generated on schedule and reachable by relying systems inside the enclaveFreeIPA publication records (first server handles CRL publication by default), step-ca and OpenBao CRL output and their distribution logsNo record of the publication point, or CRL update intervals not tied to the documented policy
Key custody logsWho accessed, moved or used the CA signing keys, and under which dual-control procedureHSM audit logs, hardware key custody register, OpenBao audit devices for keys held thereAccess granted to a shared administrator account, so individual actions cannot be traced
Backup and restore test resultsThat CA databases, keys and configuration can be recovered and that the restore was testedFreeIPA ipa-backup and ipa-restore output, step-ca and OpenBao backup records, HSM backup procedure resultsBackups taken but never restored in a test, or an outdated backup restored into a live replica topology
Software integrity checks for packages carried across the boundaryThat every package, image and rule set imported into the enclave was verified before useChecksum and signature verification records kept with each transfer, offline update media logs (for example, Security Onion soup from airgap media)Transfer media not logged, or verification done once and not recorded per import

What teams ask before building an air-gapped private CA

What drives the cost of an offline root CA and HSM setup?

Cost is driven by the number of people and locations involved, the hardware you buy or rent, and the design work that comes before any key is generated. The main line items are the HSM or hardware key storage for the root and issuing keys, secure enclosures or safes for offline media, the build of one or more online issuing CAs, and the key ceremony itself, including the time of custodians and witnesses. Some costs are one-time, such as the ceremony and initial hierarchy design. Others recur, such as HSM support contracts, CRL and issuing CA operations, and periodic renewal of intermediates. Ask any partner for a quote that separates hardware, licenses, implementation labor, ceremony support and ongoing operations. Ask which parts are fixed scope and which depend on your number of CAs, locations and integrations.

How long does it take to build an air-gapped PKI?

Duration depends on how much of the environment already exists and how many approvals the design needs. A greenfield enclave with its own hardware, a documented hierarchy and an agreed ceremony plan takes far less time than a build that must wait for a new HSM shipment, a security review of the air gap, or a migration from an existing CA. The schedule usually depends on change control windows, the availability of key custodians and witnesses, and how long your organization needs to approve the certificate policy and profiles. No timeline should be accepted until the written scope lists the environments, the number of issuing CAs, the integrations and the ceremony dates. Ask the implementation partner to show which milestones depend on your staff and which depend on hardware delivery.

What does the client need to provide for an offline root project?

The client supplies the people, space and approvals that the design cannot supply itself. That includes network owners who document the enclave boundary and transfer paths, key custodians who hold the activation material, independent witnesses who observe and sign the ceremony records, and a change control board that approves each ceremony step. You also need a certificate policy, naming and lifetime rules, a secure room or cabinet for offline media, and a decision on who may request, approve and revoke certificates. Ask the partner to produce a responsibilities matrix before work starts, and confirm that your custodians and witnesses are named, trained and available on the planned dates.

Can our internal team run an offline root CA without a partner?

Internal teams can run an offline PKI if they already operate a PKI, have staff trained on HSM administration and key ceremonies, and can keep procedures, logs and evidence consistent over time. The harder part is ongoing discipline rather than the first build: the offline root must be powered up rarely and under controlled conditions, and issuing CA renewals, CRL publication and software updates must follow written runbooks. Many teams split the work, keeping day-to-day issuance in house while using a partner for design, the first ceremony, documentation and periodic reviews. Ask any partner which tasks they would hand over to your team, and whether they offer retainer support for upgrades and testing after the build.

How do renewal and CRL distribution work when the root is offline?

The offline root signs only the intermediate CA certificates, so it is brought online rarely, and the online issuing CAs handle end-entity issuance, renewal and revocation publication. Each issuing CA publishes its own CRL inside the enclave, and clients must be able to reach those distribution points. Renewal of an issuing CA certificate requires a planned ceremony before its expiry, so the calendar for that event should be set long before it is due. In FreeIPA, the first server handles certificate renewal and CRL publication by default, so replicas and backup plans need to account for that role. Ask how the partner tracks intermediate expiry, how CRLs are reachable from every trust zone, and what happens if a CRL is stale.

How do we update software across the air gap?

Updates must be built or downloaded outside the enclave, checked for integrity and authenticity, and then carried across the boundary on approved media. Security Onion supports updates from newer ISO media in airgap mode through its soup tool, and Wazuh publishes an offline installation guide and can use an offline vulnerability repository. For PKI components, check the vendor's offline upgrade path for step-ca, OpenBao or Dogtag before scheduling changes. The NERC CIP-013-2 supply chain control is a useful reference for the verification step, even outside the power sector. Ask the partner for a transfer procedure that covers hash and signature checks, a test environment, rollback steps and the record kept for each package.

Does air-gapped support come with paid editions?

It often does. Several open-source and commercial products restrict air-gapped deployment to paid tiers, so the license you choose can decide whether the design works at all. Mattermost lists air-gapped deployment in Enterprise Advanced, Rocket.Chat excludes it from the free Starter plan, and Metabase offers it on its Enterprise plan. For PKI, step-ca is licensed under Apache-2.0, and FreeIPA under GPL-3.0-or-later with no paid edition of its own. Confirm each component's license and offline capability in writing before you commit, because the answer can differ by version and edition.

What evidence should an air-gapped PKI produce for an assessor?

A well-run ceremony produces records that an assessor can inspect: the certificate policy, the hierarchy diagram, signed ceremony scripts and logs, witness attestations, HSM configuration records, issuance and revocation logs, and CRL publication history. The HIPAA Security Rule at 45 CFR 164.312 and the FTC Safeguards Rule at 16 CFR 314.4 both expect audit controls and access control evidence where sensitive data is involved. DeployOpen prepares these controls and evidence for assessments but does not issue audit reports or certifications; independent auditors do. Ask the partner which artifacts they deliver, and confirm with your assessor which ones they will request.

What to ask an implementation partner for an air-gapped PKI

Start with the key ceremony, because every later control depends on it. Ask who writes the ceremony script, who holds each role (custodian, witness, operator, auditor), and whether the partner will witness the root generation and record it on video and in a signed log. Ask how the root's private key is generated and stored: on an HSM or on hardware tokens such as YubiKeys, and whether the platform version you plan to run supports that storage. step-ca can protect CA keys in HSMs, cloud KMS or YubiKeys, and FreeIPA's Dogtag runs its own key storage model, so get the partner to confirm in writing which model applies to each CA in your hierarchy and which firmware or library versions were tested with your HSM. Next, pin down how software and revocation data move across the boundary. Ask for the offline update procedure in writing: how packages, container images and rule sets are verified for integrity and authenticity before they enter the enclave, who signs off on each transfer, and how the partner handles a platform upgrade that arrives on new media. For revocation, ask how the CRL is published inside the enclave, where it is hosted, how often it is re-issued, and whether OCSP responders are deployed or clients rely on CRLs alone. Confirm that every relying system can reach those endpoints without internet access, and test an expired CRL on purpose before go-live. For FreeIPA deployments, ask for the replica topology and the backup test results, not just the design. The FreeIPA deployment recommendations call for two to three replicas per datacenter and at least one replica running PKI in each datacenter, and the backup documentation warns that the first server handles certificate renewal and CRL publication by default. Ask how that role is moved or documented, and how a restore into a live topology is rehearsed. Finally, ask what evidence package you will receive for assessors, what post-handover support covers and at what cost, and what the partner will not do. DeployOpen prepares controls, configurations and evidence for your assessment, but independent auditors and certification bodies issue the audit reports and certifications.

How DeployOpen scopes and builds an air-gapped PKI

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For a private PKI, that means agreeing the hierarchy, key ceremony and renewal plan in writing before any key is generated, then building the offline root and online issuing CAs inside the enclave. Compliance assessments are supported with evidence, but audit reports and certifications come from independent auditors.

How we scope

  • Written scope covers the CA hierarchy, offline root placement, issuing CA count and the chosen issuer such as step-ca, OpenBao PKI or FreeIPA Dogtag.
  • Scope records which key storage is used, whether an HSM, cloud KMS or hardware key, and who holds each key custodian role.
  • Scope lists the certificate profiles, lifetimes, CRL distribution points and the systems that must trust the root inside the enclave.

How we build

  • Key ceremonies are planned as scripted, witnessed steps with written logs, with the root generated offline and never connected to a network.
  • Issuing CAs are built and tested for automated issuance and renewal, with CRL publication reachable from every enclave segment that needs it.
  • Offline package and image transfer is designed so that every artifact carried across the isolated boundary is checked for integrity before installation.

How we hand over

  • Deliverables include the CA architecture document, key ceremony records, runbooks for issuance, revocation and root renewal, and backup procedures.
  • Handover covers an inventory of issued certificates, expiry monitoring setup and the evidence set that supports an assessor's review.
  • Operators are walked through renewal planning, offline update procedures and recovery steps, with the outstanding gaps listed in writing.

How we support

  • Ongoing support, upgrades and continuous testing are available as retainers, so the offline root and issuing CAs keep receiving maintenance.
  • Retainers can cover scheduled review of certificate lifetimes, CRL health checks and planned root or issuing CA renewals before they expire.
  • Confirm with DeployOpen the response expectations, upgrade cadence and testing frequency in the written agreement before work starts.

Sources and further reading

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.