Ignisfox
📖 User Guide🚀 Deployment FAQ
Walkthrough

Dashboard user guide

A guided tour of the Ignisfox portal, section by section, in the order you'll find them in the left nav. Follow along with the app open at /dashboard in another tab — each stop ends with a link to the deep-dive doc when you want more detail.

On this page

Heads up. Anywhere in the app that you type a secret — CA API key, SSH password, DNS provider token, group PFX password, device PIN — the value is sealed with your tenant's DEK before it touches the database. Ignisfox can't read it back after you save; neither can support. See Security model for the full crypto picture.

Before you start

The dashboard has three persistent pieces you'll use throughout:

  • Left nav — the column on the left of every dashboard page. It lists every tool in roughly the order you'll use them. Contact Us is pinned at the bottom so support is always one click away.
  • Signed-in panel — just below the nav. Shows your name, email, and organization, plus the Clerk avatar menu for sign-out and account settings.
  • Tenant — your own isolated workspace. Every cert, key, group, push target, monitor, and setting described here belongs to your tenant and nobody else. Tenants share zero data; a new Ignisfox sign-up provisions one automatically on your first dashboard hit.

If the banner at the top of a page says Read-only access, a team owner invited you as a viewer. You can browse everything but any create / update / delete will be rejected — ask them to bump you to editor or owner under Settings → Members.

1. Overview — /dashboard

What it's for. The homepage. A single-glance summary of your tenant: how many certs you have, how many hosts you're watching, what's expiring soon, and a calendar view of the next 18 months of renewals.

How to read it:

  1. The top four stat tiles link to their deep pages. Click Certificates to jump to the vault; click Monitored hosts for the monitor list. Amber numbers mean something is expiring within 30 days.
  2. Below the tiles are three cards: Recently uploaded, Vault expiring (30d), and Monitors (soonest first). Each has a View all → link in the top-right corner.
  3. Scroll down for the Expiry calendar — every vault cert and monitored host plotted on the day it expires. Click a day to drill in.
  4. If your profile is incomplete you'll see an amber prompt near the top; click Open profile → to fill in your name and organization.

Tip. The calendar only lists items that have a parseable expiry date, so certs whose notAfter couldn't be decoded (rare — usually corrupt uploads) simply don't appear.

2. Cert Vault — /dashboard/vault

What it's for. The encrypted home for every certificate, key, bundle, and PFX you upload or issue. Everything is sealed with your tenant DEK before it's written.

How to use it:

  1. Scan the table. Every row has a coloured kind badge — cert, key, bundle, PFX, or unknown.
  2. Use the Search box (friendly name, CN, issuer, filename), the Kind filter, and the Group filter to narrow down. Sort by clicking any column header.
  3. Click a row's download link for the raw PEM / PFX. Certs accept .pem, .crt, or .cer as the extension — all return the same bytes.
  4. Click Build PFX on any group that has both a cert and a key to assemble a password-protected PKCS#12. The password you type is sealed the same way your keys are.
  5. Use Export CSV (top-right) for an audit-friendly dump of metadata only — no key material ever leaves the vault this way.
  6. Hit ⟳ Auto-sync to have the daily cron pull new cert generations from any configured CA providers straight into their existing groups.
Heads up. Group PFX passwords are sealed with your tenant DEK. If you lose the password, we can't recover it — just rebuild the PFX with a new one.

Full details: Cert vault and Cert groups.

3. Upload Cert — /dashboard/vault/upload

What it's for. The drag-and-drop door into the vault.

How to use it:

  1. Drag one or more files onto the drop zone, or click Choose files. Multi-select is supported.
  2. Accepted formats: .pem, .crt, .cer, .key, .pfx, .p12, and combined bundles. Max 256 KB per file.
  3. Optionally set a friendly name per file. Defaults to the filename without extension; you can rename later in the vault.
  4. Optionally pick a group to bind the uploaded artifacts to, or create a new group inline. Uploading a bundle with both cert and key will slot them into the same group automatically.
  5. For PFX uploads you'll be prompted for the source password so the file can be split into its PEM parts. That password is used once, not stored.
  6. Hit Upload. You'll land back in the vault with the new rows at the top.

Gotcha. PKCS#7 (.p7b) isn't parsed — if your CA handed you a .p7b, re-export the chain as PEM first. See Cert vault for the full format rundown.

4. Monitor SSL — /dashboard/monitor

What it's for. Watch public hostnames and get told when a cert is near expiry, already expired, serving the wrong SAN, or failing the handshake outright.

How to use it:

  1. Use the Add monitor form: hostname, optional non-443 port, optional cosmetic label. Example: mail.example.com:993.
  2. The scheduler probes each host on your tenant's cron (default 0 2 * * * — daily at 02:00). Change cadence in the Schedule panel.
  3. Click Probe now on any row for an on-demand check — useful right after a cert rotation.
  4. Expand a row for the full cert view: issuer, SANs, valid-from / valid-to, serving IP, last error if any.
  5. Configure where alerts go in Settings → Alerts. Email fires only on status transitions (ok → error, error → ok) — no spam if a host keeps failing.

Probe budget. Each probe has a 10-second ceiling (6s TCP + 4s TLS). The worker runs up to 8 hosts concurrently per tick.

Full details: SSL monitor and Cron schedules.

5. Push to Devices — /dashboard/push

What it's for. Get freshly-issued certs onto your actual servers and appliances. Ignisfox uses a pull-token model: your device fetches over HTTPS on a schedule you control. No inbound firewall holes.

How to use it:

  1. Pick a target type: generic HTTPS pull (curl / PowerShell one-liner), SSH auto-deploy (we push and reload your web server), or an appliance flavour (Cisco, F5, IIS).
  2. Point the target at a cert group. Only groups that already contain a cert + key are offered — a group without a key can't be deployed.
  3. For SSH targets: enter host, port, username, paths for cert / key / fullchain, and a reload command (e.g. systemctl reload nginx). Authenticate with a password or SSH key.
  4. Save the target. Ignisfox issues a unique opaque token. The pull command is shown once, ready to paste into cron, a systemd timer, or Windows Scheduled Tasks.
  5. Want the exact scheduling script for your OS? Click ✨ Get AI Recipe on any target row — the LLM writes you a deploy script.
Heads up — device-side secrets. SSH passwords, SSH keys, and appliance PINs are sealed with your tenant DEK before they're written. Ignisfox can't read them after save. The pull-token itself is hashed with SHA-256 and only shown once at creation — copy it immediately; we can't recover a lost token, only issue a new one.
Heads up — device side still needs care. Once the cert material lands on your server, protecting the files on disk (permissions, disk encryption, backup hygiene) is on you. Ignisfox seals data in flight and at rest on our side; we can't enforce anything after the pull.

Full details: Push-token API.

6. Free SSL Certs (ACME) — /dashboard/acme

What it's for. Issue Let's Encrypt certs through ACME with a DNS-01 challenge. Once issued, the cert lands in your vault and auto-deploys to any linked push targets.

How to use it:

  1. Click New order. Enter your primary domain and any additional SANs.
  2. Pick or create a cert group for the issued cert to land in. Existing groups linked to push targets will re-deploy on issuance.
  3. Ignisfox shows you a single _acme-challenge.<domain> TXT record. Publish it on your DNS provider. If you've configured Cloudflare credentials under Settings → DNS, Ignisfox publishes and cleans up the record for you.
  4. Click Verify & issue. Ignisfox polls DNS, finalises the order, and drops the fullchain + key into the chosen group.
  5. Toggle Auto-renew on the order. The daily cron re-runs the flow ~30 days before expiry.

Gotcha. DNS TTL still matters — if your TXT record is cached at 3600s, verification may take that long to see the new value. Use a shorter TTL during issuance if you can.

Full details: ACME setup.

7. CA Providers — /dashboard/ca-providers

What it's for. Pull already-issued certs from a paid CA into your vault. GoDaddy is live (beta); others are gated by user demand.

How to use it:

  1. Click Add provider. Pick GoDaddy, paste your API key, secret, and customer ID.
  2. Pick a default cert group for pulled certs to land in (one per provider — you can override per cert later).
  3. Save. Ignisfox does an initial pull and schedules the daily sync.
  4. Don't see your CA? Click Vote on the vendor tile. The most-requested vendors get built first.
Heads up. CA API keys, secrets, and customer IDs are sealed with your tenant DEK before insert. Rotate a key on the CA side any time — update the provider row and the new value supersedes the old one on next sync.

Full details: CA providers.

8. Ingest API — /dashboard/ingest

What it's for. A tenant-scoped bearer token your CI/CD pipeline, certbot deploy hook, or post-issuance script can use to POST a renewed cert straight into your vault.

How to use it:

  1. Click New token, name it (e.g. ci-prod), optionally pick a default cert group for the token to land certs in.
  2. Copy the token the instant it appears — it's the only time you'll see the plaintext value. The database stores a SHA-256 hash only.
  3. Set an Authorization: Bearer header in your pipeline and POST PEM bodies to the ingest endpoint shown on the page.
  4. Revoke any token at any time — old tokens stop working immediately; new requests must use a freshly-minted one.

Tip. Every ingest creates a normal vault row exactly as if you'd uploaded it by hand. Any push targets watching the group fire automatically.

9. Settings — /dashboard/settings

What it's for. Per-tenant configuration. The index redirects to Profile; the sidebar inside Settings lists the six sub-sections.

  • Profile — /dashboard/settings/profile. Your name, organization, timezone, and the danger-zone account-deletion button. Deletion is irreversible — see the Security model for what actually happens when you click it.
  • Members — /dashboard/settings/members. Invite teammates and pick a role. Owner is full access, editor can create/update/delete, viewer is read-only.
  • DNS — /dashboard/settings/dns. Connect DNS-01 providers (Cloudflare today) so ACME can auto-publish challenge records. DNS API tokens are sealed with your tenant DEK.
  • Alerts — /dashboard/settings/alerts. Where monitor and expiry alerts go. Pick the destination address and which status transitions should email.
  • Preferences — /dashboard/settings/preferences. Timezone, date format, AI TL;DR defaults, and the cron schedules for monitors and auto-sync.
  • Billing — /dashboard/settings/billing. Current plan, limits, upgrade path. Free / Starter / Team / Enterprise — see the pricing page for current numbers.
Heads up. Cloudflare API tokens, SMTP credentials, and anything else you paste into Settings is sealed with your tenant DEK. Support can see that a token exists; support cannot see the token's bytes.

10. Admin console — /dashboard/admin

What it's for. Ignisfox's own operator console. Visible only to the account whose email matches the internal admin-email configuration; regular tenants don't see the nav item at all. Listed here so admins know where to look — not for day-to-day tenant work.

Tiles on the landing page:

  • Tenants — browse every tenant: profile, sessions, activity timeline.
  • Certificates — cross-tenant vault browser for support incidents.
  • Audit log — every sensitive action across the platform, 180-day rolling window.
  • Archive — PFX archives the system has produced, for forensic/debug lookup.
  • AI provider — switch between OpenAI and Claude, update the model and API key for the AI features.
  • Usage stats — aggregate page views, tool runs, daily activity.
  • Public tools trail — logs from the free public tools (SSL checker etc.), with hashed IPs.
  • Retention — how long usage events and raw IPs are kept.
  • Rate limits — which IPs got throttled, on which buckets, when.
  • CA requests — ranked list of vendors users have voted for on the CA Providers page.
  • Feedback inbox — every message submitted via Contact Us, newest first.
Heads up. The admin console has access to certain decrypted values (e.g. group passwords surfaced for support incidents) that regular tenants never see. That access is scoped to the single admin email on the deployment and is not a general back-door into tenant key material — the master KEK is still runtime-only and cross-tenant decrypt is not possible. See the Security model for the full envelope.

11. Contact Us — /dashboard/feedback

What it's for. The in-app feedback form. Bug reports, feature requests, questions — everything lands in the admin inbox.

How to use it:

  1. Give it a subject and a body. Your email is attached automatically from your tenant profile.
  2. Attach a screenshot if it helps — the form accepts PNG / JPG up to a few MB. The image is stored alongside the message and shown inline in the admin inbox.
  3. Submit. You'll see a confirmation and we'll get back to you via email.
Heads up — do not paste real secrets. Do not put production private keys, CA API keys, SSH passwords, or PFX passwords into the feedback body or screenshot. Support will never ask for them — if we need to reproduce an issue, we'll guide you through the portal instead. Redact any sensitive values before submitting.

Can't find what you need in the docs? Email support@ignisfox.com. We read every message.