Private CA backup: encrypted archive vs HSM key backup

The question that decides most of this is not how you encrypt the archive. It is whether your CA private key can leave its container at all. If the key is a file, you can copy the whole CA directory into one encrypted blob and be finished in minutes. If it lives in an HSM or a token that marks the key non-extractable, that copy does not exist, and your plan turns into a plan about the vendor wrap-and-restore procedure. Both models work, they fail differently, and the failure you can survive is the one worth designing around.

Where the two backup models split

Model A is directory copy. An OpenSSL-style CA is a working directory, not a single certificate: ca.key or cakey.pem, ca.crt, the issuance database, the serial and crlnumber counters, and openssl.cnf. Seal that directory with a symmetric cipher, move the result to a second medium, and restore means unpack, verify, sign. Everything the issuer needs travels together, including weeks of revocation history that nobody remembers writing.

Model B is key containment. The key is generated inside a PKCS#11 module and marked non-extractable; the module can wrap it for backup, but no process ever reads the raw bytes. Your backup is then two artifacts that must be restored in the right order: a wrapped key blob that only that module family can unwrap, plus a plain copy of the database, configuration and certificates.

The comparison is never about which model is stronger in the abstract. It is about which one your team can restore at 2 a.m. with the people who are actually awake. An archive nobody can decrypt and an HSM blob nobody has tested are equally useless; the difference is that the archive failure shows up in a password manager, and the HSM failure hides in a support contract.

What every CA backup must contain

Both models need the same record set. In an OpenSSL CA those files are index.txt with one row per issued certificate covering status, expiry, serial and subject, then index.txt.attr, serial holding the next serial to issue, crlnumber holding the next CRL number, and openssl.cnf with the dir, policy and default_days your CA really runs with. The openssl-ca manual spells out what each of those counters controls. easy-rsa keeps the same data under pki/, with a vars file deciding the certificate fields.

The key and certificate are the parts you cannot rebuild. The database is the part you cannot reconstruct from memory. Skipping index.txt still leaves you able to sign new certificates, which is exactly the trap: you find out it is missing the first time a client asks whether a certificate was revoked. Record the CA fingerprint outside the backup, so a restore is compared against a value you trust rather than against the file you just restored.

openssl x509 -in ca.crt -noout -fingerprint -sha256
tar czf ca-state.tar.gz ca.crt ca.key index.txt* serial* crlnumber* openssl.cnf
openssl enc -aes-256-cbc -pbkdf2 -iter 200000 -salt -in ca-state.tar.gz -out ca-state.tar.gz.enc
openssl ca -config openssl.cnf -gencrl -out crl.pem

Restore tests that do not fork the issuer

Two live CAs with the same subject and the same key look identical to every client that trusts the original. Two CRLs carrying the same number but different contents is how clients quietly accept a certificate you revoked. Run the restore on a host with no route to your clients, or in a throwaway VM, and never publish the CRL the test produces.

A test that only proves the archive opens proves nothing about issuance. The sequence that counts: compare the restored ca.crt fingerprint with the value you recorded, confirm the serial matches what your last issued certificate implies, issue one certificate for a throwaway CN and watch index.txt gain a row, then revoke that certificate and regenerate the CRL.

openssl verify -CAfile ca.crt -CRLfile crl.pem -crl_check client.crt
openssl crl -in crl.pem -noout -lastupdate -nextupdate

With an HSM the same test runs through the module. Unwrap the blob into the replacement device, confirm the CA certificate the module reports matches your recorded fingerprint, and only then let it sign. If the module has its own object store, the wrap has to cover the key object and its label, because restoring the key under a different label breaks the configuration that points at it.

Failure modes that decide the choice

Five failures account for most real losses. A forgotten archive passphrase with no independent copy of the secret turns the archive into a brick. A single copy on one disk dies with that disk, and a checksum never tells you whether decryption still works. Certificates revoked after the backup date look valid again after a restore, so your backup interval is also your revocation blind spot. Restoring an older serial counter reuses serial numbers and confuses caches and CRL lookups keyed on serial. A replacement HSM that refuses the wrapped blob turns a hardware swap into full re-issuance.

Model A handles the first four badly but visibly. Model B handles them well right up until the module or the vendor process fails. If your keys are exportable and the team is small, the encrypted archive is the honest choice, backed by two media and a written passphrase procedure. If the key is non-extractable you have no choice at all, and the work shifts to proving the vendor restore path before the day you need it.

Choosing the model and scheduling it

Three conditions settle the decision. Can the key be exported without a vendor process? Must a restore land on hardware you do not already own? How long can issuance stop while you argue with support? Answer those three and the model is decided; everything after that is scheduling.

Take a backup after every signing ceremony and before any configuration change, because the config is part of the state. Keep two copies on different media in different places, one of them offline, and hold the decryption secret in a different trust domain from the copies. Write the last successful restore date on the backup record. A backup that has never been restored is a hypothesis, not a control.

Before you close the ticket, confirm these five points:

• The ca.crt fingerprint is recorded somewhere outside the backup.
• index.txt, serial, crlnumber and openssl.cnf are all inside the archive or blob set.
• The passphrase or wrapped-key custody is documented and held by someone other than the archive owner.
• A restore was tested on an isolated host with one issuance and one revocation.
• The revocation gap implied by your backup interval is accepted in writing or shortened.