Agents & automation

Agents run on the machines that hold certificates and pull work from the server over mTLS — no inbound connections to your hosts, ever.

1. Enable agent registration

Registration is gated by a shared bootstrap token. Set it on the server (the appliance wizard can also do this for you):

# in the server's .env
ENS0KEY_AGENT_BOOTSTRAP_TOKEN=$(openssl rand -hex 24)

Without the token, registration is disabled.

2. Install the agent

The agent is a single static binary — no runtime dependencies. The fastest path: on the Agents tab in the UI, open "How do I connect an agent?" and download the ready-made archive for Linux (.tar.gz) or Windows (.zip).

Linux (systemd)

tar xzf ens0key-agent-linux-amd64.tar.gz && cd ens0key-agent-linux-amd64
sudo ./install.sh                    # binaries -> /usr/local/bin, unit, user 'ens0key'
sudo nano /etc/ens0key/agent.env     # server URL + bootstrap token
sudo systemctl enable --now ens0key-agent
journalctl -u ens0key-agent -f       # logs

Windows (service)

# put both .exe (agent + worker) into a permanent folder
$dir = "C:\Program Files\ens0key"
Expand-Archive ens0key-agent-windows-amd64.zip .; Copy-Item .\ens0key-agent-windows-amd64\* $dir

# configuration
@"
ENS0KEY_SERVER_URL=https://pki.example.com
ENS0KEY_AGENT_BOOTSTRAP_TOKEN=<token>
ENS0KEY_AGENT_NAME=win-01
"@ | Set-Content C:\ProgramData\ens0key\agent.conf

cd $dir; .\ens0key-agent.exe install   # registers + starts the service
Keep ens0key-agent.exe and ens0key-agent-worker.exe together in the same permanent folder — UI-driven upgrades swap the worker in place. For ADCS enrollment, set ENS0KEY_AGENT_SERVICE_ACCOUNT to a domain account (or gMSA) the CA template grants Enrollto — the default LocalSystem usually isn't one.

Trusting the server

In production, give the agent the CA that signed the server's certificate via ENS0KEY_AGENT_SERVER_CA (a PEM bundle) — or use a publicly trusted server certificate. ENS0KEY_AGENT_INSECURE exists for labs only: it skips server authentication entirely.

3. Approve the agent

A newly registered agent lands in pending and cannot claim jobs until an admin approves it on the Agents tab. Once approved it gets its mTLS identity and starts polling. Online/offline status comes from a 60-second heartbeat; recent logs can be pulled straight into the UI.

4. Put certificates on auto-renewal

  • Certificate stores — a location the agent manages: a PEM directory, a PKCS#12 or JKS keystore, or a Windows IIS binding. Add service checks to confirm the endpoint actually serves the deployed certificate.
  • Auto-renewals — bind a CA + Common Name + store: ens0key issues, the agent deploys, and it renews before expiry — optionally running a reload command (e.g. nginx -s reload) after each push. If post-deploy verification fails, the agent restores the previous certificate automatically.
  • Blueprints — a reusable template (stores + renewals + checks) you apply to each new agent for fleet rollout.
  • Jobs — the audit trail of everything agents have done.

5. Upgrade agents from the UI

An agent older than the server shows an outdated badge with an Upgrade button. One click downloads the new worker over mTLS, verifies its checksum, self-tests it, and swaps it in place — no restart, no SSH, and the previous binary is kept for rollback.

6. Appliances without an agent

Some devices can't run an agent. Orchestration → Appliances pushes an issued certificate over the device's own management interface:

  • F5 BIG-IP (iControl REST) and Cisco ISE (OpenAPI) — REST upload, serial-matched to the inventory.
  • Cisco ESA — over SSH (certconfig); the issuing chain is resolved automatically and bindings (listeners, GUI, LDAPS) are re-applied on every renewal.
  • Cisco WLC — Catalyst 9800 (PKCS#12 import over HTTP) and AireOS (TFTP); the server hosts the bundle just for the duration of the deploy.
  • Cisco IOS / generic SSH — agentless SSH inventory of host keys and configured keys.

Every agentless deploy streams its steps live and keeps the last CLI transcript behind a Log button on the target.