How it works

aethercert has two moving parts: a hosted control plane (the dashboard and API you sign in to) and a small agent you install on each server. Everything else — domains, certificate authorities, deploy targets — is configuration that lives in the control plane and is handed to an agent only when it's time to do work.

The control plane

The control plane stores your organization's domains, certificate authorities, agents, and certificate definitions, and it schedules the work. It never holds a private key for an issued certificate and never connects into your network. It only ever responds to agents that poll it.

The agent

The agent is a single binary that runs as a service (systemd on Linux, the Service Control Manager on Windows). On a schedule it opens one outbound HTTPS connection to the control plane, asks "is there anything for me?", and if so, does it: generates a key and CSR, solves the ACME challenge, obtains the certificate, installs it into the deploy target, and reports the result back.

Outbound-only, keys stay put

Agents never accept an inbound connection — no firewall holes, no VPN. And the private key for a certificate is generated on the server that will use it and never leaves that host; only metadata (serial, fingerprint, validity) is reported back. See Agents.

CA connectors (optional)

For an internal CA that can't be reached over ACME — most commonly Active Directory Certificate Services — you install a CA connector on the CA host. Agents call the connector directly over your internal network to sign CSRs; the connector only reports liveness and its discovered certificate templates back to the control plane, never certificate material. See Certificate authorities.

The issuance flow, step by step

  1. Order. You define a certificate (common name, SANs, CA, deploy target, target agent or group) in the dashboard. The control plane queues an issue job for each target agent.
  2. Claim. On its next check-in the agent claims the job. Idle agents check in every 5 minutes; the control plane shortens that to 10 seconds whenever there's a queued job, so issuance feels immediate.
  3. Validate. The agent generates a fresh key + CSR and solves the challenge — DNS-01 (fetching short-lived DNS credentials from the control plane at that moment) or HTTP-01. Internal REST CAs skip the challenge and sign the CSR directly.
  4. Deploy. The issued certificate is written into the deploy target — a certificate store, a web-server file path with a reload, or a load balancer's management API.
  5. Report & renew. The agent reports serial, fingerprint, and validity back. The control plane tracks expiry and queues a renewal job the configured number of days before expiry — no human in the loop.

Where to go next