FAQ — deploying certificates

Every deployment follows the same shape regardless of target:

1. Upload your leaf cert, its chain, and its private key to the Cert Vault. Put them in the same group.
2. Download the artifact the target platform expects (PEM bundle, individual files, or a password-protected PFX).
3. Import into the device. For servers that support automated reloads, use the Push to Devices feature so the box pulls new material over HTTPS instead of you copying files by hand.

Ignisfox encrypts every cert and private key at rest with a per-tenant data key. When you download or push, the material is decrypted in memory just long enough to serve the response.

IIS consumes PKCS#12 (.pfx) files. Build one that contains the leaf, chain, and private key together.

1. In the Cert Vault, open the leaf certificate’s row and click Build PFX. Set a password of at least 4 characters and (optionally) check Save to vault.
2. Download the resulting .pfx to the IIS host.
3. Open IIS Manager, select the server node, and double-click Server Certificates.
4. In the Actions pane, choose Import…, browse to the PFX, enter the password, and pick the certificate store (Web Hosting is the usual choice; use Personal if you need the private key exportable again).
5. Bind the imported cert: expand Sites, select your site, click Bindings…, then either edit the existing https binding or add a new one on port 443 with the imported certificate.
6. Recycle the application pool, or run iisreset if you need to be sure the new cert is loaded in-process.

Tip: for multi-SAN certs bound across many sites, use SNI bindings so a single IP can serve all of them.

nginx wants two PEM files: a fullchain (leaf + intermediates) and a private key. Both should be readable only by root.

1. From the Cert Vault, download the leaf + all chain certs and the matching private key.
2. Concatenate the leaf and chain into one file on the server. Leaf first, then intermediates, one BEGIN/END block after another.

sudo install -d -m 0755 -o root -g root /etc/ssl/ignisfox
sudo tee /etc/ssl/ignisfox/example.com.fullchain.pem > /dev/null <<'PEM'
-----BEGIN CERTIFICATE-----
... leaf ...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
... intermediate ...
-----END CERTIFICATE-----
PEM
sudo install -m 0600 -o root -g root example.com.key /etc/ssl/ignisfox/example.com.key

Then add the server block:

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/ssl/ignisfox/example.com.fullchain.pem;
    ssl_certificate_key /etc/ssl/ignisfox/example.com.key;
    ssl_protocols       TLSv1.2 TLSv1.3;

    # ... proxy_pass / root as usual ...
}

sudo nginx -t && sudo systemctl reload nginx

If you’re automating this, define a Push Target of type nginx and have a small shell script pull ?kind=fullchain and ?kind=key from the Ignisfox fetch endpoint into those two paths before the reload.

DSM replaces certificates through the Control Panel. Have three PEM files ready: leaf, intermediate(s), and private key.

1. In DSM, open Control Panel → Security → Certificate.
2. Click Add → Replace an existing certificate (or Add a new certificate if this is your first import), then Next.
3. Choose Import certificate and fill in three fields:
   • Private Key → the .key file.
   • Certificate → the leaf cert PEM.
   • Intermediate certificate → the chain PEM (concatenated intermediates if there’s more than one).
4. After import, click Configure in the certificate list to bind the cert to DSM, Web Station, VPN Server, etc.

In the Meraki dashboard, certificate upload lives under the product area that consumes it. Exact menu names move between releases — consult vendor documentation if the labels don’t match yours.

1. Sign in to the Meraki dashboard and select the network.
2. Navigate to Security & SD-WAN → Client VPN (or Secure Connect if that’s the product in use).
3. In the Authentication or Certificates section, upload:
   • the leaf certificate PEM, and
   • the private key PEM.
4. If the dashboard asks for a CA bundle separately, upload the intermediate chain PEM. Otherwise concatenate intermediates after the leaf in the certificate upload.
5. Save. Active VPN sessions will pick up the new cert on reconnect.

Meraki does not currently expose a pull-style API for certificate material; plan to refresh manually at renewal time, or consult vendor documentation for the current automation options.

Ribbon SBCs accept PKCS#12 bundles. Build one from the vault with a strong password — the SBC will prompt for it during import.

1. Build the PFX: Cert Vault → leaf cert → Build PFX, set a password.
2. In the SBC web UI, go to Settings → Security → SBC Certificates (path varies by firmware; on older SWe Lite it’s System → Certificate).
3. Click Import, choose PKCS#12, upload the .pfx, and enter the password you chose.
4. Assign the new certificate to the SIP TLS profile used by your signaling interfaces.
5. Reload or restart SIP services so new TLS handshakes present the replacement cert.

If the SBC refuses the PFX, regenerate it with 3DES encryption — some firmware versions don’t accept AES-256 encrypted PKCS#12. Ignisfox’s PFX builder already uses 3DES, which is the most compatible option.

Deltapath’s UC server imports PEM pairs through the admin portal.

1. Open System Administration in the Deltapath admin UI.
2. Navigate to Certificates (exact path may be Security → Certificates depending on your release).
3. Click Upload and provide:
   • the leaf certificate (PEM),
   • the private key (PEM, unencrypted), and
   • the intermediate chain (PEM).
4. Activate the new certificate for SIP TLS / HTTPS as appropriate, and restart the relevant services so endpoints renegotiate.

If your firmware refuses an encrypted private key, decrypt it first with openssl rsa -in key.pem -out key.plain.pem. Consult Deltapath documentation for the current supported formats.

Anything that can run curl can consume an Ignisfox Push Target. Create one, point it at a cert group, and install a tiny script on the device to pull material on a schedule (or on demand from your renewal pipeline).

Create a target in Push to Devices — the UI shows ready-to-paste commands with your token. A typical Linux cron looks like:

#!/usr/bin/env bash
set -euo pipefail
TOKEN=your-opaque-token
BASE=https://www.ignisfox.com/api/push/$TOKEN/fetch

curl -fsSL -o /etc/ssl/site/fullchain.pem "$BASE?kind=fullchain"
curl -fsSL -o /etc/ssl/site/privkey.pem  "$BASE?kind=key"
chmod 0600 /etc/ssl/site/privkey.pem
systemctl reload nginx

For Windows targets, use Invoke-WebRequest with -OutFile and schedule via Task Scheduler. For appliances that only accept PKCS#12, use ?kind=pfx&pw=... and hand the resulting .pfx to the device’s native import tool.

If you rotate the push token (recommended after staff changes), update the script’s TOKEN variable — the old value will stop working immediately.

Apache reads PEM files directly; a simple SSH push drops the files and triggers a reload.

1. In Ignisfox, add a push target with target type Apache httpd and push mode SSH. The default paths drop to /etc/ssl/ignisfox/ — adjust to wherever your SSLCertificateFile points.
2. Reload command (pre-populated): sudo systemctl reload apache2. On RHEL / CentOS use httpd instead of apache2.
3. Test → Deploy → schedule for recurring auto-rotation.

HAProxy wants the leaf + chain + private key concatenated in one file. Ignisfox exposes a kind=fullchain endpoint that returns leaf + chain; your deploy script concatenates the key on the server side.

#!/bin/bash
set -euo pipefail
TOKEN=your-opaque-token
BASE=https://www.ignisfox.com/api/push/$TOKEN/fetch
DEST=/etc/haproxy/certs/ignisfox.pem

# Fetch fullchain + key, concat in atomic order (HAProxy wants one file)
curl -fsSL "$BASE?kind=fullchain" > /tmp/ignisfox-chain.pem
curl -fsSL "$BASE?kind=key"       > /tmp/ignisfox-key.pem
cat /tmp/ignisfox-chain.pem /tmp/ignisfox-key.pem > "$DEST.new"
chmod 0600 "$DEST.new"
mv "$DEST.new" "$DEST"
rm -f /tmp/ignisfox-chain.pem /tmp/ignisfox-key.pem
systemctl reload haproxy

SSH push works too — select HAProxy in the target type dropdown and paths default to /etc/haproxy/certs/ignisfox.pem.

Caddy auto-rotates its own Let’s Encrypt certs when you let it, but if you prefer to bring your own cert, drop the PEM pair and reload.

1. Target type Caddy, mode SSH.
2. Paths default to /etc/caddy/ignisfox/{cert,privkey,fullchain}.pem.
3. In your Caddyfile, point to the Ignisfox-managed files:

example.com {
  tls /etc/caddy/ignisfox/fullchain.pem /etc/caddy/ignisfox/privkey.pem
  reverse_proxy localhost:8080
}

Reload command: sudo systemctl reload caddy.

Traefik’s file provider hot-reloads automatically when cert files on disk change — you don’t need a reload command at all.

1. Target type Traefik, mode SSH. Leave the reload command blank.
2. In your dynamic config, reference the Ignisfox paths:

# dynamic.yml
tls:
  certificates:
    - certFile: /etc/traefik/certs/fullchain.pem
      keyFile: /etc/traefik/certs/privkey.pem

Traefik notices the file change within a few seconds and re-serves with the new cert. No restart required.

For Windows hosts that aren’t IIS (services binding to a cert via thumbprint, scheduled tasks, custom apps), use the pull-token with a PowerShell scheduled task.

# C:\Scripts\ignisfox-pull.ps1
$Token = 'pt_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
$Base  = "https://www.ignisfox.com/api/push/$Token/fetch"
$Pass  = 'pfx-password'
$Dest  = 'C:\ssl\ignisfox.pfx'

Invoke-WebRequest "$Base?kind=pfx&pw=$Pass" -OutFile "$Dest.new"
Move-Item -Force "$Dest.new" $Dest

# Import into LocalMachine\My so services can bind by thumbprint
$Secure = ConvertTo-SecureString -String $Pass -AsPlainText -Force
Import-PfxCertificate -FilePath $Dest -CertStoreLocation Cert:\LocalMachine\My -Password $Secure

Register as a Scheduled Task so it runs daily / weekly:

schtasks /create /sc DAILY /st 03:00 /tn "Ignisfox Pull" ^
  /tr "powershell -NoProfile -ExecutionPolicy Bypass -File C:\Scripts\ignisfox-pull.ps1" ^
  /ru "SYSTEM"

Kubernetes ingress controllers read cert material from Secret objects of type kubernetes.io/tls. Use the pull-token from any host with kubectl access.

#!/bin/bash
set -euo pipefail
TOKEN=your-opaque-token
NS=default
NAME=ignisfox-tls

TMP=$(mktemp -d)
trap 'rm -rf "$TMP"' EXIT

curl -fsSL "https://www.ignisfox.com/api/push/$TOKEN/fetch?kind=fullchain" > "$TMP/tls.crt"
curl -fsSL "https://www.ignisfox.com/api/push/$TOKEN/fetch?kind=key"       > "$TMP/tls.key"

kubectl create secret tls "$NAME" \
  --cert="$TMP/tls.crt" \
  --key="$TMP/tls.key" \
  --namespace="$NS" \
  --dry-run=client -o yaml | kubectl apply -f -

Run as a CronJob inside the cluster if you prefer — same script, packaged in a small image. The Secret update triggers ingress-nginx / Traefik / cert consumers to pick up the new material within seconds.

For a containerised web server, mount a host directory and pull into it. The container re-reads certs on the next request or on SIGHUP depending on the image.

docker run -d --name web \
  -v /srv/certs:/etc/nginx/certs:ro \
  -p 443:443 \
  nginx:latest

# On the host, nightly cron:
curl -fsSL "https://www.ignisfox.com/api/push/$TOKEN/fetch?kind=fullchain" \
  > /srv/certs/fullchain.pem.new
mv /srv/certs/fullchain.pem.new /srv/certs/fullchain.pem
docker exec web nginx -s reload

Firewall appliances usually need a manual import step after the cert lands on disk — their web UIs bind certs to specific services (GUI, VPN, reverse proxy rules) and don’t hot-reload.

pfSense / OPNsense: target type pfSense or OPNsense, mode SSH. Files land in /tmp/. Then in the web UI, go to System → Cert Manager, import the PEM pair, and re-bind services (HTTPS UI, OpenVPN, HAProxy package) to the new cert. We don’t automate the re-bind step because those references change per firewall.

F5 BIG-IP: target type F5 BIG-IP. The pre-filled reload command runs tmsh install sys crypto cert/key against the dropped files. Re-binding to your client SSL profile still happens manually via the GUI the first time; after that, replacing the cert and key of the same names keeps the binding intact.

If Cloudflare proxies your traffic and you use an origin certificate on your web server, treat it the same as any other Linux web server — Cloudflare doesn’t care which cert is on your origin as long as it’s valid.

For Cloudflare’s own origin-CA certs (issued via their dashboard, only valid for Cloudflare-proxied traffic), you still import them into your origin web server. Ignisfox stores them like any other PEM bundle once you upload them to the vault.

Fully automated cert provisioning via the Cloudflare API (origin CA or custom uploaded certs) is on the roadmap. Until then the pull-token + curl pattern covers any server behind Cloudflare.

AWS load balancers (ALB / NLB) bind to certs stored in ACM (AWS Certificate Manager) or IAM. Use the pull-token + AWS CLI to upload a new cert and update the listener.

#!/bin/bash
set -euo pipefail
TOKEN=your-opaque-token
BASE=https://www.ignisfox.com/api/push/$TOKEN/fetch
LISTENER_ARN=arn:aws:elasticloadbalancing:...:listener/app/...

CERT=$(curl -fsSL "$BASE?kind=cert")
CHAIN=$(curl -fsSL "$BASE?kind=chain")
KEY=$(curl -fsSL "$BASE?kind=key")

IMPORTED=$(aws acm import-certificate \
  --certificate "$CERT" \
  --certificate-chain "$CHAIN" \
  --private-key "$KEY" \
  --query CertificateArn --output text)

aws elbv2 modify-listener \
  --listener-arn "$LISTENER_ARN" \
  --certificates CertificateArn="$IMPORTED"

Run from a Lambda or EC2 instance with IAM permissions for acm:ImportCertificate and elasticloadbalancing:ModifyListener. Useful when you want Ignisfox to be the source-of-truth for cert issuance but still use ACM-backed ELBs.