Offline Certificate Authority (CA)

The defining characteristic of an offline CA is that its private key is generated and stored on a device that is never connected to a network. This is typically a dedicated Hardware Security Module (HSM) or a purpose-built, hardened laptop kept in a Faraday cage enclosure or a dual-control safe. The key material never touches system memory accessible by a network stack, making remote exfiltration mathematically impossible. The only way to compromise the key is through physical theft of the secured hardware, which is mitigated by tamper-evident seals, biometric access controls, and strict break-glass procedures.

Since the root CA is offline, it cannot issue certificates on demand. Instead, it signs a limited number of intermediate (subordinate) CAs during controlled ceremonies. These subordinate CAs are deployed online within the air-gapped environment to issue leaf certificates for services like mutual TLS (mTLS) between microservices. If a subordinate CA is compromised, the offline root can revoke it via a manually transported Certificate Revocation List (CRL) without exposing the root key. This creates a defense-in-depth hierarchy where the most critical asset is physically air-gapped.

Bringing the offline CA online is a strictly audited ceremonial event requiring multiple trusted administrators. The process follows a policy-as-code (PaC) script and often requires quorum-based authentication (e.g., M-of-N smart cards) to unlock the HSM. Every command typed and every output displayed is recorded by a witness and logged to an immutable snapshot for compliance. This ensures that no single rogue administrator can abuse the root key, and the supply chain integrity of the signing operation is verifiable.

Certificate revocation in an air-gapped network relies on the sneakernet protocol. The offline CA generates a new Certificate Revocation List (CRL) during its brief operational window. This CRL is signed by the root and written to removable media that has undergone strict removable media validation. The media is physically transported to the online subordinate CAs and imported. This manual process guarantees that even if an attacker compromises an online service, they cannot suppress the revocation of their stolen certificate, preserving the integrity of the zero trust architecture (ZTA).

The offline root CA's private key must be generated inside a FIPS 140-2 Level 3 (or higher) validated HSM. The key is marked as non-exportable, meaning it can never leave the hardware boundary in plaintext. All cryptographic operations occur within the HSM's secure cryptoprocessor. The HSM itself is stored in a tamper-evident bag within a safe. This hardware-backed keystore ensures that even if the host operating system is compromised during a ceremony, the key material remains protected by the HSM's physical security mechanisms.

For sovereign identity management, the offline CA can pre-generate batches of signed authentication tokens or client certificates during a ceremony. These tokens are written to a secure, tamper-proof model registry equivalent for identity artifacts. When a new device or service is deployed in the air-gapped enclave, it uses a pre-generated identity rather than requesting one dynamically. This offline token generation pattern eliminates the need for an online CA for routine provisioning, allowing the root to remain offline for months or years at a time.

A dedicated, tamper-resistant physical computing device that safeguards the offline CA's private root key. The HSM performs all cryptographic operations internally, ensuring the key material never leaves the hardware boundary in plaintext. In an air-gapped deployment, the HSM is often kept in a safe and only connected during a controlled key signing ceremony.

• Generates and stores the root key pair
• Requires multi-party authentication (M-of-N quorum) to activate
• FIPS 140-2 Level 3 validation is the minimum standard

An intermediate certificate authority that operates online and issues end-entity certificates. Its own certificate is signed by the offline root CA, creating a chain of trust. If the issuing CA is compromised, the offline root can revoke the intermediate certificate without needing to rebuild the entire PKI hierarchy.

• Handles day-to-day certificate issuance
• Operates in a network-connected environment
• Enforces the validity period and policies set by the root

A digitally signed list published by the CA that enumerates certificates that have been revoked before their scheduled expiration. For an offline root, the CRL is generated during the periodic signing ceremony, transferred to the online network via sneakernet, and published by an online distribution point.

• Contains serial numbers of revoked certificates
• Signed by the issuing CA or root CA
• Must be manually transported across the air gap

A rigorously scripted, audited procedure where the offline root CA is temporarily activated to perform cryptographic operations. Multiple trusted administrators assemble in a physically secured room, authenticate to the HSM, and execute the exact steps required to sign a subordinate CA certificate or generate a new CRL.

• Requires dual control and video recording
• Follows a pre-defined, immutable script
• Produces a tamper-evident audit log

A dedicated microcontroller on a device's motherboard that performs measured boot and stores platform integrity measurements. In an air-gapped PKI, TPMs on the machines that host the offline CA software ensure the operating system and application stack have not been tampered with between signing ceremonies.

• Stores cryptographic hashes in Platform Configuration Registers (PCRs)
• Enables remote attestation of the CA host
• Binds disk encryption keys to specific hardware state

A service that provides real-time certificate revocation status, offering a more granular alternative to CRLs. The OCSP responder's signing certificate is issued by the offline root, and its responses are pre-signed during the ceremony to allow it to operate autonomously in the online environment without direct root CA connectivity.

• Returns 'good', 'revoked', or 'unknown' status
• Uses pre-computed responses for air-gapped operation
• Reduces reliance on large, periodically downloaded CRLs