Security & data handling

aethercert runs an agent as root or LocalSystem on your servers and handles the material that identifies them. This page states plainly what that means: what is stored, where, what an attacker would get from each component, and what they would not.

Private keys#

A certificate's private key is generated on the host that will serve it, by the agent, at the moment of issuance - including at every renewal. It is written to the deploy target on that host and nowhere else.

It is not transmitted to the control plane, not escrowed, and not backed up by aethercert. What the agent reports back is metadata: serial number, fingerprint, validity window, and success or the error text.

The practical consequence is worth being explicit about, in both directions:

• A compromise of the control plane does not yield your private keys. They are not there to take.
• aethercert cannot recover a lost key for you. If a host is destroyed, its certificate is reissued rather than restored. For a renewing certificate that is a non-event; it is the correct trade.

The network boundary#

Agents make outbound HTTPS connections and accept none. There is no inbound port, no callback, no listener - so aethercert needs no firewall hole, no VPN and no public address on your side.

The one exception is the CA connector, which does listen - on your internal network only, for your agents, on a port you choose. It is not reachable from the internet, and every request to it is authenticated with a shared API key regardless of the transport certificate in use.

What the control plane stores#

Secrets at rest#

Every secret you paste into the dashboard goes into Supabase Vault, encrypted, rather than into a plain column.

They are write-only from the browser's point of view. Once saved, a credential is never returned to a client again - editing shows an empty field, and leaving it empty keeps the stored value. Replacing a secret deletes the one it replaced, so a rotated credential is genuinely gone rather than merely superseded.

DNS credentials are handed to agents as short-lived values fetched at the moment a challenge is being solved, not stored on the agent host.

The dashboard is not a code-delivery channel#

This is the most important boundary in the product, and it is worth understanding before you evaluate the rest.

A deploy target can run a reload command or a script as root or LocalSystem on every host it applies to. That is the product working as intended - installing a certificate means telling a service to pick it up.

What is deliberately not possible is introducing new code through the dashboard:

• Custom scripts are never uploaded. The script must already exist in the agent's scripts directory on the host. The dashboard only selects it by filename.
• Script variables are passed as environment variables (AC_VAR_<NAME>), never interpolated into a shell command, so no variable value can inject a command.

A compromised dashboard account can therefore at most change which already-approved script runs, and with what variables. Placing new script content on a host requires access to the host.

Configuring a deploy target is separated from ordinary certificate work for the same reason: it requires the admin role, while issuing and renewing certificates with existing targets requires only member. See Users, roles and access.

Access control#

The four roles - viewer, member, admin, owner - are enforced in the database through row-level security and a trigger on the certificates table, not only in route handlers. A request that the interface would not offer is refused server-side too.

The organization is the isolation boundary. Under an MSP plan, each customer is a separate organization rather than a filtered view of a shared tenant, so there is no cross-customer query to get wrong. MSP members inherit their role on the customer workspaces they manage.

Authentication#

Multi-factor authentication is mandatory and cannot be switched off. Password plus an authenticator code, a passkey, or Microsoft Entra SSO in an organization that relies on its own Conditional Access policies. A password and an authenticator app stay enrolled regardless, so no single method is ever the only way in.

Irreversible actions re-check the requirement server-side rather than trusting the browser.

Data residency#

Storage and processing stay in Germany.

Your rights over your data#

The privacy policy is the authoritative document.

Transport and browser hardening#

HSTS with a two-year max-age and includeSubDomains, X-Frame-Options: DENY and a frame-ancestors 'none' content security policy so the dashboard can never be framed, X-Content-Type-Options: nosniff, and strict-origin-when-cross-origin referrer policy.

Agent supply chain#

Agents update through the aethercert Update Service, which verifies a checksum before replacing a binary. Auto-update can be turned off per agent to pin a version, in which case the dashboard shows the exact manual command instead.

The agent and connector never update themselves, and neither accepts code from the control plane other than a signed-off release binary through that path.

Reporting a vulnerability#

Do not open a public issue. Use GitHub private vulnerability reporting on the repository, or email [email protected].

Include the affected component and version, what an attacker gains, and enough detail to reproduce. If a certificate or private key is involved, send the fingerprint and serial - never the key material.

Researchers are credited in the release notes unless they ask not to be. There is no paid bounty. Please allow 90 days before public disclosure, or less if a fix ships sooner.