File locations

Everything aethercert installs lives under one root per platform, with a subdirectory per component.

The Linux agent is the one exception to the data root: its configuration and state sit under /etc/aethercert-agent/agent/, where a system configuration file belongs.

BinariesCopy Anchor Link

The tray and the Update Service share a main directory because neither is scoped to one product: the tray covers both backends, and the Update Service updates both.

Configuration and stateCopy Anchor Link

State includes the ACME account key and the cached certificate material the agent keeps so a redeployment does not have to reissue. On Linux, config.json is written 0600 inside a 0700 directory; private keys are written the same way. On Windows, where file modes do not apply, every component restricts its state directory every time it starts (from 2026.10.7.0.0): SYSTEM, Administrators and - if the service runs under its own account - that account; only logs\ stays readable for other local users. The data root C:\ProgramData\aethercert itself belongs to Administrators, and other users may read it but not create anything in it. A link that a non-administrator put into one of these directories is deleted; if a component's whole directory is such a link, the service refuses to start, and aethercert-installer repair names the link. To add a deploy script to scripts\, use an elevated prompt or accept Explorer's administrator prompt.

The Update Service has no config.json of its own - it reads whichever backend's config is already on the host.

The installer's state directory sits outside the others on purpose: an uninstall that deletes the agent's directory must not also delete the log explaining what it just removed.

LogsCopy Anchor Link

One file per UTC day in logs/ inside each component's state directory, with the previous day compressed into logs/archive/:

<state directory>/logs/2026-09-06.log
<state directory>/logs/archive/2026-09-05.tar.gz

Retention follows the plan - see Logs and diagnostics.

ServicesCopy Anchor Link

The Linux unit names are the Windows service names lowercased, because systemd unit names are conventionally lowercase while services.msc shows mixed case. The units live in /etc/systemd/system/ and carry Restart=on-failure, RestartSec=5 and AmbientCapabilities=CAP_NET_BIND_SERVICE, and from 2026.10.7.0.0 a sandbox per component - see systemd sandbox below.

systemd sandboxCopy Anchor Link

Each Linux unit restricts its service as far as that service's job allows:

The Update Service brings the units of an existing installation up to date on its next check; each service runs under its new unit from its next restart, which the next update does. A unit you edited by hand is left alone - put your own settings in a drop-in instead, which nothing of aethercert ever touches:

sudo systemctl edit aethercertagent        # opens a drop-in for your settings
sudo systemctl restart aethercertagent

A drop-in can switch a setting off (ProtectKernelModules=no), or tighten the agent on a host whose deploy targets you know - for example ProtectSystem=strict with a ReadWritePaths= line for /etc/aethercert-agent/agent and every directory your certificates, webroots and scripts write to. Run a deployment after any change.

systemctl status aethercertagent
journalctl -u aethercertagent -f

The Windows tray is launched for the logged-in user from an HKLM Run key rather than as a service, because it needs an interactive session.

Legacy pathsCopy Anchor Link

A host installed before the unified layout has its components under their own top-level folders - AetherCertAgent, AetherCertCAConnector, AetherCertUpdateService under Program Files and ProgramData, and /usr/local/bin plus /etc/aethercert-agent/config.json on Linux. The Update Service migrates such an installation onto the layout above on its own; nothing has to be re-enrolled.

What an uninstall removesCopy Anchor Link

uninstall without --purge stops and removes the services and leaves everything above in place, so a later install reuses the host's existing enrollment. --purge deletes the binaries, configuration and logs as well, and cleans up the now-empty roots.

Certificates already deployed - files at the paths a deploy target wrote to, entries in the Windows certificate store - are never touched by either.