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 is configuration that lives in the control plane and is handed to an agent only when there is work to do.

The control plane

The control plane stores your organization's domains, certificate authorities, agents and certificate definitions, and it schedules the work.

Two properties are worth stating plainly, because they determine what a compromise of the control plane would and would not get an attacker:

• It never holds the private key of an issued certificate. Keys are generated on the server that will use them and stay there. What comes back is metadata - serial number, fingerprint, validity window.
• It never connects into your network. There is no inbound port, no callback, no agent that listens. It only ever answers agents that have called 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 whether there is anything for it, and if so does it: generates a key and a certificate signing request, solves the validation challenge, obtains the certificate, installs it into the deploy target, and reports the result.

An idle agent checks in on a cadence tied to your plan and the agent's own settings - 3 hours by default on every plan, as often as every 30 minutes on Pro/MSP. Whenever a job is queued the control plane shortens that to roughly ten seconds, so issuing a certificate does not mean waiting out the idle interval.

CA connectors

Some internal certificate authorities cannot be reached over ACME or a REST endpoint - most commonly Active Directory Certificate Services, which speaks its own Windows RPC protocols. For those you install a CA connector on the CA host itself.

Agents call the connector directly over your internal network to have CSRs signed. The connector reports only its liveness and the certificate templates it discovered back to the control plane - never certificate material, never keys. See The CA connector.

The issuance flow, step by step

1. Order. You define a certificate - common name, subject alternative names, authority, deploy target, target agent or group. The control plane queues an issue job for each target agent.
2. Claim. The agent claims the job on its next check-in.
3. Validate. The agent generates a fresh key and CSR, then proves control of the hostname: DNS-01, where it fetches short-lived DNS credentials from the control plane at that moment and publishes the challenge record; or HTTP-01, where it answers on port 80. Internal REST authorities skip validation and sign the CSR directly.
4. Deploy. The issued certificate goes into the deploy target - a certificate store, a file path plus a service reload, a load balancer's management API.
5. Report. The agent sends back serial, fingerprint and validity. Not the key.
6. Renew. The control plane queues the renewal job the configured number of days before expiry, and the cycle repeats without anyone being involved.

Scaling past one server

Everything above describes one certificate on one host. Three objects exist so that the same work does not have to be repeated per server:

• An agent group is a named set of agents. A certificate job can target the group instead of one host.
• A certificate policy is a standing rule attached to a group. Every member gets the certificate the policy describes - now, and as the group grows. A server provisioned six months from now arrives with its certificate already being issued.
• A deploy target can be saved once, under Manage > Deploy Targets, and reused by any number of certificates - instead of repeating the same load balancer or cluster credentials on every certificate that deploys to it.

The practical consequence is that the policy can be written before any of the servers exist, and that rotating a shared credential means updating it in one place.

Where things run

Details, including what is stored and for how long, are in Security and data handling.

Where to go next