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. It runs as three separate surfaces on three hostnames:

Two properties 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 every 3 hours by default on every plan. That interval is configurable down to 1 hour on Standard and MSP and 30 minutes on Pro; Free is fixed at 3 hours. Whenever a job or an update is queued, the control plane's heartbeat response shortens the next check-in to 10 seconds regardless of plan, so issuing a certificate does not mean waiting out the idle interval.

CA connectors

Some internal certificate authorities speak neither ACME nor a REST API. The common case is Active Directory Certificate Services, which is reached through Windows RPC. 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, the certificate templates it discovered and a health snapshot of the CA back to the control plane - never certificate material, never keys. See The CA connector.

Each sign or revoke request carries a short-lived, job-bound token the control plane minted at dispatch. The connector verifies its signature locally against the control plane's published JWKS, then calls back to confirm the job is still open and the token has not been used before. A signature alone proves only that the token was issued; the callback is what proves it is still valid.

The issuance flow

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 and holds a 20-minute lease on it. A claim whose lease expires without a result is requeued, so a host that dies mid-job does not strand the certificate.
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; HTTP-01, where it answers on port 80; or TLS-ALPN-01, where it answers the TLS handshake on port 443. 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 - 30 by default, anywhere from 1 to 90 - and the cycle repeats.

A job that fails is retried automatically, up to three attempts in total. A failure the agent classifies as permanent - bad credentials, an unknown template - stops immediately rather than burning the remaining attempts on an identical failure. See Jobs.

Scaling past one server

Everything above describes one certificate on one host. Three objects exist so 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

Exact hostnames, ports and directions are in Network requirements. What is stored and for how long is in Security and data handling.