Ignisfox
Walkthrough

Cert vault

The vault is the encrypted home for every certificate, private key, bundle, and PFX you upload or issue through Ignisfox. It lives at /dashboard/vault. Every file is sealed with your tenant's DEK before it ever touches the database — see Security model for the crypto details.

What you can upload

  • PEM / CRT / CER — X.509 certificates (the public half). Base64-armoured with -----BEGIN CERTIFICATE----- headers, or raw DER binary (we detect and convert).
  • KEY / PEM — private keys. RSA, ECDSA, and PKCS#8 all work. We refuse to store a key without sealing it first.
  • Bundle — a single PEM file containing a cert, its intermediate chain, and optionally the private key. Common output of certbot and similar tools.
  • PFX / PKCS#12 — password-protected binary archives from IIS, F5, Cisco, and most appliances. We store them as-is and can also split them into their PEM parts.

How files are split on upload

If you drop a combined bundle or PFX, the uploader parses it and creates one vault row per logical artifact: the leaf cert as one row, the private key as another, each intermediate as its own row. This is what lets the rest of the app bind a cert to a key through a group, and what lets the PFX builder assemble the right three pieces later.

"Kind" detection

Every row in the vault has a payload_kind label — the coloured badge in the table:

  • Cert — a single X.509 leaf or intermediate. Safe to share; contains only a public key.
  • Key — a private key. Never leaves Ignisfox unencrypted; download returns PEM only on authenticated request.
  • Bundle — a PEM file containing more than one block (e.g. cert + key, or cert + chain). We still preserve the exact uploaded bytes for re-download.
  • PFX — a PKCS#12 binary. Marked with a purple badge; works as a Build PFX source once bound to a group.
  • Unknown — we couldn't parse it. Usually means PKCS#7 (.p7b) or a truncated file. Re-export from the source and try again.

Friendly names

Every row has a friendly name that defaults to the original filename (without extension). You can rename any row inline; the friendly name is what appears on push targets, group PFXs, and CSV exports. The Common Name column stays the authoritative X.509 subject — that one can't be edited since it's a cryptographic fact about the cert.

Downloading — .pem / .crt / .cer aliases

Every cert row has a download link: GET /api/vault/<id>. We accept any of .pem, .crt, or .cer as the extension — they all return the same bytes. The extension is purely cosmetic; most tools happily accept any of the three, but a Windows server might insist on .cer while an nginx config wants .pem. Pick the one that matches the config file you're dropping it into.

For PFX rows, the download is the raw PKCS#12 binary. For bundles, you get the exact uploaded PEM with every block preserved in order.

Search and filter

The vault table has three filters stacked together:

  • Search box — matches on friendly name, common name, issuer, and original filename. Substring match, case-insensitive.
  • Kind filter — quick toggle to only see Certs, Keys, Bundles, PFXs, or Unknowns.
  • Group filter — scope the view to a specific group or to (Ungrouped). When one group is selected you also get an inline Rename group button.

Combined with click-to-sort on every column, finding a cert even across a few hundred uploads should never take more than a couple of keystrokes.

CSV export

The Export CSV button at the top of the vault hits /api/vault/export and streams a CSV of metadata only — friendly name, common name, issuer, SANs, valid-from, valid-to, fingerprint, size, upload date. Never the key material. Handy for audit reports or ingesting into a spreadsheet for expiry tracking.

Re-uploading a renewed cert

When a cert gets renewed (whether via ACME, a CA provider sync, or you manually received a new PEM from the CA) you don't replace the existing row — you upload the new cert as a new row. The vault keeps the whole history so you can always diff against what was deployed before. Assign the new cert to the same group as the old one and any push targets pointed at that group will pick up the new material on their next pull.

If you don't want to manage this yourself, turn on /dashboard/vault/auto-sync — the daily ticker will pull new cert generations from your configured CA providers and slot them into their existing groups automatically.

Deleting certs

Deletes are hard — the row is removed, the ciphertext is dropped, and there's no undo. If the cert belonged to a group, the group itself stays behind (other certs may still reference it). Delete the group separately from the Groups panel if you also want to clean that up — see Cert groups.

Size and limits

  • Per-file — 256 KB. Enough for any real cert or bundle; much larger than that and it's almost certainly the wrong file.
  • Per-tenant — no hard cap on row count, but the UI is tuned for up to a few thousand. If you need more, get in touch.
  • Retention — rows stay until you delete them or you close the tenant (see Security model for the account-deletion flow).