13.1 Reference Architecture
Common deployment patterns for CertKit Agents.
CertKit Agents are flexible enough to run next to the workload they manage, act as a trusted push host for appliances, or retrieve certificate material from an on-premise Keystore. The right architecture depends on where the private key should live and what system must be updated after renewal.
On-host workloads
We recommend using on-host workloads whenever possible. Each of your Windows and Linux servers should run the agent.
For servers and applications you control directly, install one agent on each host that needs certificate material. The agent registers the host with CertKit, polls for assigned deployment configurations, writes the renewed certificate to the local destination, and runs the post-deploy command needed by that workload.
Use this pattern when the agent can run on the same machine as the software using the certificate. Examples include Nginx, Apache, HAProxy, IIS, Remote Desktop, RRAS, DirectAccess, Exchange, SQL Server, WinRM, FileZilla Server, Postfix, Dovecot, Docker, and Java applications that need JKS output.
┌──────────────────────────┐
│ CertKit App │
│ issue + renew certs │
│ deployment configs │
└─────────────┬────────────┘
│ HTTPS API: poll config + fetch cert
┌────────────────────┴──────────────────────┐
v v
┌────────────────────────────────┐ ┌────────────────────────────────┐
│ Linux host: web-01 │ │ Windows host: app-01 │
│ ┌────────────────────────────┐ │ │ ┌────────────────────────────┐ │
│ │ CertKit Agent │ │ │ │ CertKit Agent │ │
│ │ polls + deploys │ │ │ │ polls + deploys │ │
│ └──────────────┬─────────────┘ │ │ └──────────────┬─────────────┘ │
│ v │ │ v │
│ Nginx / Apache / HAProxy │ │ IIS / RDP / RRAS / WinRM │
│ Docker / Postfix / Java │ │ Exchange / SQL Server │
└────────────────────────────────┘ └────────────────────────────────┘In this model, the host is the management boundary. If three web servers all terminate TLS, install three agents and assign each host the deployment configurations it needs. You can still link or copy deployment configurations between agents when the hosts are intentionally identical.
Appliance and device push
We recommend nominating a single host to act as your deployment agent for appliance and device certificate distribution.
For appliances, firewalls, load balancers, and managed devices, you usually cannot install an agent directly on the target system. Instead, create a small host or VM that runs one CertKit Agent and can reach the devices’ management interfaces. That single agent can own multiple deployment configurations, with one configuration per appliance, VIP, profile, listener, or remote device.
This pattern works well for API-driven pushes and command-line integrations. Built-in templates include examples such as F5 BIG-IP over iControl REST, Palo Alto firewalls over the PAN-OS API, AWS ACM imports, Azure Key Vault uploads, and Kubernetes TLS secrets. Custom templates can cover the same pattern for device APIs, SSH commands, vendor CLIs, or internal deployment scripts.
┌──────────────────────────┐ ┌────────────────────────────────┐
│ CertKit App │ HTTPS API │ Host: cert-push-01 │
│ issue + renew certs │--------------->│ ┌────────────────────────────┐ │
│ deployment configs │ config + cert │ │ CertKit Agent │ │
└──────────────────────────┘<---------------│ │ appliance push host │ │
status │ └────────────────────────────┘ │
└────────────────┬───────────────┘
│ push certs (one config per target)
┌────────────────┬────────────────┬────────────────┬──┴─────────────┐
v v v v v
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ F5 BIG-IP │ │ Palo Alto │ │ Kubernetes │ │ AWS ACM │ │ Azure KV │
│ iControl │ │ PAN-OS │ │ TLS secret │ │ import │ │ upload │
└─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘Keep the deployment configs separate even when they use the same certificate. That gives each appliance its own status, retry history, variables, maintenance window, and error reporting. For example, a single wildcard certificate could have one F5 BIG-IP deployment for clientssl_public, another F5 deployment for clientssl_admin, and a Palo Alto deployment for a VPN portal certificate.
Keystore-backed deployments
Use the CertKit Keystore when private keys must remain on your own infrastructure. The keystore service runs on one host, generates private keys locally, sends CSRs to CertKit, stores issued certificates next to those keys, and serves certificate material to authorized CertKit Agents over HTTPS. CertKit’s cloud services handle public material and orchestration, but private keys are generated and stored on the keystore host.
Agents still run near the workloads or push hosts that need to deploy certificates. The difference is that those agents fetch PEM or PFX material from the keystore instead of directly from CertKit. The keystore validates each agent request with CertKit before releasing key material.
┌──────────────────────────┐ ┌────────────────────────────────┐
│ CertKit App │ CSR + status │ Host: keystore-01 │
│ request CSR │--------------->│ ┌────────────────────────────┐ │
│ issue + renew certs │ agent auth │ │ CertKit Keystore │ │
│ validate agent fetch │<-------------->│ │ keys / CSRs / PEM+PFX │ │
└──────────────────────────┘ │ └────────────────────────────┘ │
└────────────────┬───────────────┘
│ cert fetch (PEM/PFX, validated)
┌─────────────────────────────────────┴─┐
v v
┌────────────────────────────┐ ┌────────────────────────────┐
│ Host: web-01 (Linux) │ │ Host: app-02 (Windows) │
│ ┌────────────────────────┐ │ │ ┌────────────────────────┐ │
│ │ CertKit Agent │ │ │ │ CertKit Agent │ │
│ │ Nginx / Java / Docker │ │ │ │ IIS / RDP / WinRM │ │
│ └────────────────────────┘ │ │ └────────────────────────┘ │
└────────────────────────────┘ └────────────────────────────┘This architecture is useful when security or compliance requirements prohibit private key storage in a cloud service. It does add an infrastructure dependency: the keystore host needs durable backups, restricted administrative access, and network reachability from every agent that must retrieve certificate material.