Installing the agent

The quickest way onto a server is one command - curl -fsSL https://get.aethercert.com | sudo bash on Linux, irm https://get.aethercert.com | iex in Windows PowerShell (see The one-command install).

It asks for an enrollment token, checks it, shows what it is about to do, and only then downloads, verifies and installs. Underneath, everything installs through one binary, aethercert-installer, built per operating system; the script fetches and verifies it for you. The dashboard's enrollment wizard picks the component, the OS and the token type, and hands back the same command with the token already filled in.

This page covers what that command does. For an unattended fleet rollout see Unattended rollout; for a container, see Containers.

Build the agent in the dashboardCopy Anchor Link

Start at Manage > Agents > New agent. The wizard has three sections:

1. Platform - the operating system, whether you want the graphical setup or the command line, a single- or multi-provision token, and optionally the agent group the host should join. Picking a group here means any certificate policy on it applies before the agent's first ordinary check-in.
2. Installation - the token is minted when you reach this section. The wizard shows the download and the command, with the token already in it.
3. Verify - the wizard polls for the agent's first check-in.

The same wizard mints a CA connector pairing token when you start from Manage > Certificate Authorities. The install command is identical either way: the token itself decides which component is installed, and the installer resolves that with the control plane before consuming it.

The one-command installCopy Anchor Link

Run one line on the server. It needs nothing but outbound HTTPS - no open port, no VPN - and the private keys the agent later generates never leave the host.

curl -fsSL https://get.aethercert.com | sudo bash

Run like this, in a terminal, the script is interactive:

1. It checks the host - platform, privileges, and that the control plane is reachable over outbound HTTPS.
2. It asks for the enrollment token and checks it with the control plane before anything is downloaded. A mistyped, expired or used-up token is caught here, and a token for a component that does not belong on this host (a CA connector token on Linux, say) is refused.
3. Once you typed the token in, it shows a review - what will be installed, the control plane, the installer version, the proxy - and waits. Choose Install, Change settings or Cancel with the arrow keys and Enter.
4. It downloads aethercert-installer, verifies it (see below), and only then runs it to enroll the host, install the service and start it.

If the host already runs an aethercert agent and you did not pass a token, the script asks first what you want: enroll again with a new token, repair the installation in place (keeping its enrollment), uninstall, or cancel. See Repair and uninstall.

Linux and Windows on amd64 only. On Linux the install has to run as root; the script refuses anything else rather than half-installing.

With the token in the commandCopy Anchor Link

This is the form the dashboard's enrollment wizard hands you, with your token already filled in, and the one to use from automation:

curl -fsSL https://get.aethercert.com | sudo bash -s -- --token <token>

With the token in the command the script does not stop for a review - you already decided when you copied it - and in a terminal it still checks the token first. Without a terminal - cloud-init, ssh without -t, a CI job, a remoting session, a scheduled task - there is nobody to ask, so nothing is asked and the token must come from --token / -Token or AETHERCERT_TOKEN. Without one, the script stops with an error before it downloads anything.

Which script get.aethercert.com servesCopy Anchor Link

get.aethercert.com picks the script by client: PowerShell gets install.ps1, curl, wget and other command-line clients get install.sh, and a web browser is sent to the install page on the website. To name the script explicitly - to read it before you run it, or from tooling whose client the dispatch might guess wrong - use its own address. Both answer the same to every client:

• https://get.aethercert.com/install.sh
• https://get.aethercert.com/install.ps1

The older commands keep workingCopy Anchor Link

Commands handed out before get.aethercert.com existed fetch the same scripts from the CDN, and are still supported - nothing in an existing image, playbook or runbook has to change:

curl -fsSL https://cdn.aethercert.com/install.sh | sudo sh -s -- --token <token>

& ([scriptblock]::Create((irm https://cdn.aethercert.com/install.ps1))) -Token '<token>' -Yes

What the script checks before it runs anythingCopy Anchor Link

It downloads aethercert-installer, fetches the SHA-256 published beside it, compares them, and only then executes. There is no flag to skip that: a script piped into a root shell that runs whatever it just downloaded is exactly the shape of install the checksum exists to rule out. On a mismatch it exits non-zero having executed nothing.

When the build was published with a signing key configured, the download is additionally checked against a detached Ed25519 signature published beside it. That is a stronger guarantee than the checksum alone, because a compromised CDN cannot forge it. The signature check needs openssl on the host; its absence, or the absence of a signature to check, is tolerated - the checksum already ran. A signature that is found and does not verify is always fatal.

A download cut off half-way cannot run part of the script: the Linux script is all functions with the one call on its last line, and PowerShell parses the whole Windows script before running any of it.

Step by step, without the bootstrap scriptCopy Anchor Link

If you would rather see each step, your environment does not allow piping a script into a shell, or the host cannot reach get.aethercert.com, download the installer yourself. On an air-gapped host, fetch the two files on a machine that can reach the CDN, carry them over, and run the same checksum comparison there before installing. This is also the form the wizard shows when there is no CDN to serve install.sh from.

curl -fsSL -o aethercert-installer-linux-amd64 \
    "https://cdn.aethercert.com/installer/latest/aethercert-installer-linux-amd64" \
  && curl -fsSL -o aethercert-installer-linux-amd64.sha256 \
    "https://cdn.aethercert.com/installer/latest/aethercert-installer-linux-amd64.sha256" \
  && sha256sum -c aethercert-installer-linux-amd64.sha256 \
  && chmod +x aethercert-installer-linux-amd64 \
  && sudo ./aethercert-installer-linux-amd64 install \
       --api https://api.aethercert.com --token <token>

latest moves with each release. A versioned path - .../installer/2026.8.3.0.0/... - is immutable, so pin one in a golden image or a configuration-management manifest.

The graphical setup, on WindowsCopy Anchor Link

Double-click the installer, or start it with no arguments, and a setup window opens: choose install, repair or uninstall, choose the fleet agent or the CA connector, paste the control plane URL and the token, adjust the options, and watch the install log. It follows the Windows display language, in German or English. aethercert-installer gui opens it explicitly from a shell.

That is the path for a server somebody is sitting in front of. Everything it does is also a command-line flag - see the CLI reference.

What the install does to the hostCopy Anchor Link

1. Resolves which product the token belongs to, without consuming the token.
2. Enrolls with it, obtaining this host's own credentials.
3. Downloads that product's current build using those credentials.
4. Places the binary at the standard location and writes config.json beside it.
5. Registers and starts an operating-system service.
6. Best-effort, installs the shared tray icon (Windows) and the aethercert Update Service alongside it.

The last step is best-effort by design: the component you asked for is already installed and running by the time it is reached, and neither companion being absent stops it doing its job today. A host without the Update Service simply never updates itself.

Both the config path and the binary path are printed on stdout when the install finishes, and the whole run is written to an install log - see File locations.

Service accounts on WindowsCopy Anchor Link

By default the service runs as LocalSystem. Pass --service-account (and --service-password, unless it is a group managed service account whose name ends in $) to run it as a named account instead.

When you do, the installer grants that account the Log on as a service right, verifies the credentials actually work as a service logon before creating the service, and waits for the service to report running afterwards. A wrong password, a disabled account or a Deny log on as a service policy is reported as exactly that rather than as a generic start failure. The password never reaches a log line or an error message.

A dedicated service account is strongly recommended for the CA connector, because it is what the CA rights get granted to. The certificate connector needs no rights on the machine at all, which makes an account of its own a cheap way to keep a network-facing service off LocalSystem. Either way, the installer grants the account access to the component's own directory - and nothing else - and the Update Service keeps that grant in place.

Confirming it workedCopy Anchor Link

Click Verify connection in the wizard. The agent polls outbound, so this works from behind NAT and a closed inbound firewall.

On the host, aethercert-installer status prints what is installed - component, version, service state, binary and config paths, and the control plane it points at - and exits 0 either way, which makes it safe to run from a configuration-management dry run.

RequirementsCopy Anchor Link

Exact hostnames and ports are in Network requirements.