Designing an offline root CA for small operations

“Keep the root CA offline” is common PKI advice.

The phrase is simple. The operational design behind it is not.

Small teams rarely have dedicated HSMs, formal ceremony rooms, multiple security officers, or specialized PKI operators. They may have one engineer, a limited hardware budget, and a real requirement to issue certificates for VPN access or internal services.

The objective should not be to imitate a high-assurance enterprise ceremony badly.

It should be to identify the trust boundaries that matter, reduce routine exposure of the most consequential key, and create a procedure the team can actually operate and recover.

This article assumes a small private PKI used for a bounded purpose such as VPN client and server authentication. It does not claim to replace the requirements of a public trust service, regulated qualified-signature system, or high-assurance national PKI.

What the root CA is protecting

A compromised leaf certificate affects one identity or service.

A compromised intermediate CA may issue many trusted certificates within its permitted scope.

A compromised root CA can undermine the entire trust hierarchy.

The root key should therefore have one narrow operational purpose:

Establish and, when necessary, replace the intermediate trust layer.

It should not be used for routine client or service issuance.

Reducing the frequency with which the root is present reduces the number of systems, operators, and operational events that can expose it.

A practical hierarchy

For a small VPN certificate system, a defensible structure is:

Offline root CA
  └── signs constrained intermediate CA

Operational intermediate CA
  └── signs client and service certificates

The root remains outside the running platform.

The intermediate performs routine operations:

Certificate issuance
Policy enforcement
Revocation
CRL generation
Expiry management
Replacement workflows

This means the most powerful key is not required whenever a user needs a certificate.

The intermediate should be constrained according to the real use case. That may include:

A path-length constraint preventing further sub-CAs
Defined key usages
Defined extended-key usages
Controlled certificate lifetimes
Subject and SAN restrictions
Explicit client and server profiles

The goal is not simply to add another certificate to the chain. It is to reduce the authority and exposure of the operational signing key.

The root should not be part of the application

A web administration interface is useful, but it is also a large attack surface.

It processes:

HTTP requests
Sessions
User input
Templates
Database state
Browser interactions
Third-party dependencies

The root key should not be placed behind that interface.

In a separated design, the operator-facing service does not manipulate CA key material directly. It communicates with a dedicated certificate daemon through a narrow local interface.

The architecture may look like:

Browser
  ↓ HTTPS
Administrative control plane
  ↓ AF_UNIX socket
Certificate daemon
  ↓
Operational intermediate key and policy

Offline root CA
  ↓ used only for intermediate lifecycle
Intermediate CA certificate

This does not make a compromised web application harmless.

An attacker controlling the application may still attempt operations available through the daemon.

The important difference is that the application does not directly receive:

The intermediate private key
An unrestricted OpenSSL interface
Direct filesystem access to CA state
Authority to define arbitrary certificate policy

The daemon remains a separate enforcement boundary.

Why a Unix socket helps

A local Unix socket provides several useful properties:

No network listener
Filesystem-based access control
An explicit process boundary
A smaller protocol surface
Easier host-level restriction
Clear separation between UI logic and CA logic

The daemon can expose a constrained command model such as:

Generate a key and certificate
Sign a supplied CSR
Build a client bundle
Revoke a certificate
Regenerate or retrieve a CRL
Check service health

It should not expose a generic “execute an OpenSSL command” operation.

The socket boundary is only meaningful when the surrounding controls are correct.

A world-writable socket, shared service account, weak request validation, or unrestricted daemon protocol would remove much of the value.

The boundary should therefore include:

A dedicated daemon identity
Restricted socket ownership and mode
Strict request schemas
Defined operation types
Policy enforced inside the daemon
Structured audit records
Limited writable paths
No unnecessary network access

The root ceremony

A small operation still needs a repeatable root-key procedure.

The ceremony should document:

Who is present
Which machine is used
Which media is used
How software integrity is established
How entropy is obtained
How the key is encrypted
Where backup copies are stored
Which fingerprints are recorded
Which intermediate constraints are applied
How the result is verified
How temporary material is removed

The procedure should be written before generating the root.

The ceremony is not made secure by being dramatic.

Its value comes from repeatability, reviewability, and evidence.

A short procedure that can be followed correctly is more defensible than an elaborate ceremony that exists only as a document and has never been rehearsed.

Choosing the root environment

A practical root environment may be:

A dedicated offline laptop
A temporary live operating system
A machine with networking physically disabled
A clean, controlled virtual machine whose host boundary is understood

The best option depends on the threat model.

The important properties are:

It is not used for ordinary browsing or development
Network access is disabled during root operations
Required tools are obtained and verified in advance
Temporary files are identified and removed
The environment can be reproduced when the intermediate must be renewed
Operators understand what the environment does and does not protect against

“Offline” and “air-gapped” are not interchangeable terms.

A device may be offline during the ceremony while still having other exposure paths through removable media, compromised software, firmware, or the host on which a virtual machine runs.

A rarely used laptop that has not received updates for years is not automatically secure because it is disconnected from the network.

Software integrity remains part of the ceremony.

Root-key storage and recovery

One untested USB drive is not a recovery strategy.

A small operation should normally keep multiple encrypted copies on separate media and in separate physical locations.

The storage design should answer:

What happens if one device fails?
What happens if one location is lost?
Who possesses the decryption material?
Can one person access every component?
How is media integrity checked?
Has restoration been tested?
How is old or failed media retired?
How is unauthorized duplication detected or discouraged?

Availability and confidentiality must be considered together.

An exposed root compromises the trust hierarchy.

An inaccessible root can also create a serious operational failure when the intermediate expires or must be replaced after compromise.

The objective is not to maximize secrecy at the cost of recoverability. It is to create controlled, tested access.

Constraining the intermediate

The intermediate should be narrower than the root.

Its certificate should reflect:

Intended certificate types
Naming rules
Validity limits
Subject and SAN policy
Key-usage requirements
Extended-key-usage requirements
Whether further subordinate CAs are prohibited
Revocation behaviour
Renewal procedure

The root should not sign a broadly capable intermediate merely because that is the easiest command to run.

The intermediate’s lifetime should be shorter than the root’s, but long enough that renewal can be planned rather than performed during an emergency.

The appropriate values depend on:

Number of issued certificates
Ability to redistribute trust material
Frequency of administrative access
Recovery capability
Consequences of intermediate replacement

These are design decisions, not universal constants.

Protecting the online intermediate

The intermediate is online because it must perform routine operations.

It therefore requires stronger runtime boundaries.

Useful controls include:

A dedicated service account
No network-exposed CA API
Unix-socket access only
A strict request schema
Policy enforced inside the daemon
No arbitrary subjects or lifetimes
Restrictive private-key permissions
Structured audit records
Rate and concurrency limits
Revocation support
CRL generation
Backups separated from the web application

The administration layer should request an operation.

It should not decide the final certificate policy by itself.

For example, the control plane may request a client certificate for a supplied identity. The daemon should independently determine whether:

The subject is valid
The requested profile exists
The lifetime is allowed
The key type is permitted
Duplicate subjects are accepted
The resulting extensions match policy

This gives the policy boundary meaning even when the caller is compromised.

Revocation is part of issuance

A certificate-management system is incomplete when it can issue certificates but cannot reliably revoke them.

For VPN access, the design must answer:

How is a certificate selected for revocation?
How quickly is the CRL regenerated?
How does the VPN service receive the updated CRL?
What happens when CRL publication fails?
Is CRL expiry monitored?
Can an operator identify the correct certificate serial?
Are replacement and revocation linked operationally?
What evidence is retained?

A carefully protected root does not compensate for a revocation process that operators cannot execute under pressure.

Issuance, revocation, replacement, and distribution are one lifecycle.

Intermediate compromise and root compromise are different events

If the intermediate is compromised, the response may include:

Stop trusting new certificates from the affected intermediate.
Isolate the signing service.
Preserve relevant logs and CA state.
Generate a replacement intermediate.
Sign it using the offline root.
Reissue affected certificates.
Update CRLs and relying-system configuration.
Investigate the path of compromise.

The exact procedure depends on how relying systems process intermediate revocation and trust anchors.

If the root is compromised, recovery is more disruptive.

Every relying system may need a new trust anchor. Existing intermediate and leaf certificates may need to be replaced. The organization may no longer be able to distinguish legitimate certificates from attacker-issued ones under the compromised hierarchy.

This difference is the primary reason to keep the root outside routine systems.

Avoiding cargo-cult controls

Some PKI practices are copied from high-assurance environments without considering whether they improve a small operation.

Elaborate ceremonies without recovery testing

Documentation and witnesses do not help if no one can restore the key when required.

Excessive manual steps

A procedure performed once every several years is likely to be forgotten or executed incorrectly unless it is simple, documented, and rehearsed.

Offline systems without software integrity

A disconnected machine running compromised or outdated tooling can still produce an untrustworthy result.

Encryption with one unavailable password

A perfectly encrypted root that no authorized operator can recover is an availability failure.

Storing every component together

Root media, passwords, documentation, and backup copies should not all be lost or compromised by one physical event.

Treating the HSM as the architecture

An HSM can improve key protection, but it does not define:

Certificate policy
Operator authorization
Revocation
Auditability
Recovery
Trust-anchor distribution

Hardware is one control inside a broader operating model.

The right controls are those that address the actual threat model and can be operated consistently.

What a defensible small-scale design achieves

A practical offline-root architecture should ensure:

The root key is absent from routine systems
Normal certificate issuance does not require the root
A web compromise does not directly expose CA key material
The intermediate independently enforces certificate policy
Revocation and CRL handling are operational
Root and intermediate recovery procedures exist
Loss of one storage medium does not destroy the PKI
One compromised runtime credential does not automatically compromise every trust layer
Operators can explain and reproduce the procedure
Intermediate replacement can occur without inventing a process during an incident

These properties can be evaluated.

They are more useful than simply stating that the root is “offline” without explaining what that means operationally.

Closing thought

An offline root CA is not a product feature.

It is an operational boundary.

Its value comes from reducing how often the most powerful key is present, reducing which systems can reach it, and preserving a trustworthy recovery path when the online intermediate fails.

For small operations, the best design is not the most ceremonial one.

It is the smallest design that creates real separation, can be tested, and will still be understood when it is needed years later.