Ignisfox
Walkthrough

Cert groups

A cert group is a logical bundle that ties a leaf certificate, its private key, and its intermediate chain together as one deployable unit. Every vault row can belong to at most one group. Manage groups from the Groups panel at the bottom of /dashboard/vault.

Why groups exist

The vault stores each PEM block as its own row (see Cert vault), which is great for auditing but inconvenient when you need to do something that requires the three parts together. Groups close that gap. Anywhere Ignisfox needs to assemble "the cert, its key, and its chain" it looks up the group rather than asking you to hand-pick three rows every time.

The two big consumers:

  • Build PFX — turns the group into a PKCS#12 archive you can drop onto IIS / F5 / Cisco. The builder needs the cert + key + chain; the group tells it which rows to grab.
  • Push targets — servers pull the latest cert via the push-token API. Push targets bind to a group, not to individual certs, so a rotation is transparent to the server: it pulls "fullchain for group X" and gets whatever the freshest material is.

How certs land in a group

Four ways:

  1. On upload — the uploader offers a group picker. Pick an existing group or type a new name to create one on the fly. If you upload a combined bundle, all three split rows are assigned to the same group together.
  2. Bulk from the vault table — select any number of rows with the checkbox column, then use the Move to group input in the bulk bar. The target group is created if it doesn't exist yet.
  3. ACME issuance — new ACME orders get a smart-default group named after the primary domain. Renewals inherit the group of the previous issuance, so your push targets see the rotation without any manual moves.
  4. CA provider sync — when a CA provider pulls a new generation of an existing cert, the renewal row inherits the old row's group. See CA providers.

Group passwords

Each group has an optional password used as the default PFX password when you Build PFX for anything in that group. Stored as encrypted_password — sealed with your tenant DEK exactly like a cert payload (same AES-256-GCM pipeline described in Security model). We never log it, never echo it back in the UI, and only unseal it at the moment of PFX generation.

If a group doesn't have a password set, the PFX builder prompts you for one at build time and offers to save it so later builds can skip the prompt. Clear the saved password from the group's settings row.

How push targets bind

When you create a push target at /dashboard/push you pick which group it reads from. From then on, every pull of ?kind=cert, ?kind=key, ?kind=chain, ?kind=fullchain, or ?kind=pfx resolves to the current freshest row of that type inside the group. "Freshest" means the most recent valid_from among certs whose valid_to is still in the future.

That indirection is the whole point: you rotate the cert by dropping a new row into the group, and every server pulling from that group's targets picks up the new material on its next fetch — no server-side config change, no Ignisfox dashboard clicks.

Auto-pull into groups

Enable auto-sync at /dashboard/vault/auto-sync and the hourly ticker will walk your CA provider integrations, pull any new cert generations it finds, and file them into the same group as the previous generation. Combined with push targets this gives you end-to-end auto-deploy: new cert issued by the CA → pulled by Ignisfox → placed in a group → your server fetches it next hour. Zero human touches.

Deleting a cert in a group

Deleting a single row removes that row's ciphertext from the vault. The group itself stays; other certs in the group are untouched. If you deleted the only member of a group, the group becomes empty and appears under empty groups at the bottom of the Groups panel, where you can prune it if you no longer need it.

Deleting an entire group

Two options from the Groups panel:

  • Delete the group shell (only offered when the group is empty) — removes the group record. Harmless; any push targets that were bound to it start returning 404 until you rebind them.
  • Delete all certs in the group — irreversibly removes every cert/key/chain row inside. The empty group shell stays behind so you can re-populate it or delete it separately. Push targets bound to the group will 404 until new material lands.

Both actions hit a confirmation dialog and are logged in the audit trail. There is no undo — if you're nervous, export the vault to CSV first.

Common patterns

  • One group per hostname / SAN set — the simplest model. Best when each cert covers a distinct service.
  • One group per appliance — useful when a single PFX is loaded onto an F5 or Cisco box that only wants one bundle. Keep the group's password aligned with whatever the appliance expects.
  • One group per environment — split prod / staging / dev even if they share SANs so a staging rotation can't accidentally push to prod targets.