File locations
Where every binary, configuration file, log and script lives on a managed host, per platform, plus the service names.
Everything aethercert installs lives under one root per platform, with a subdirectory per component.
| Linux | Windows | |
|---|---|---|
| Install root | /opt/aethercert-agent | C:\Program Files\aethercert |
| Data root | /var/lib/aethercert-agent | C:\ProgramData\aethercert |
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.
Binaries
| Component | Linux | Windows |
|---|---|---|
| Fleet agent | /opt/aethercert-agent/aethercert-agent | C:\Program Files\aethercert\agent\aethercert-agent.exe |
| CA connector | not applicable | C:\Program Files\aethercert\ca-connector\aethercert-ca-connector.exe |
| Update Service | /opt/aethercert-agent/main/aethercert-update-service | C:\Program Files\aethercert\main\aethercert-update-service.exe |
| Tray | not applicable | C:\Program Files\aethercert\main\aethercert-tray.exe |
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 state
| Component | Linux | Windows |
|---|---|---|
| Agent config | /etc/aethercert-agent/agent/config.json | C:\ProgramData\aethercert\agent\config.json |
| Agent state | /etc/aethercert-agent/agent/ | C:\ProgramData\aethercert\agent\ |
| Agent scripts | /etc/aethercert-agent/agent/scripts/ | C:\ProgramData\aethercert\agent\scripts\ |
| CA connector config | not applicable | C:\ProgramData\aethercert\ca-connector\config.json |
| Update Service state | /var/lib/aethercert-agent/main/ | C:\ProgramData\aethercert\main\ |
| Tray state | not applicable | C:\ProgramData\aethercert\tray\ |
| Installer state | /var/lib/aethercert-agent/setup/ | C:\ProgramData\aethercert\setup\ |
State includes the ACME account key and the cached certificate material the agent keeps so
a redeployment does not have to reissue. config.json is written 0600 inside a 0700
directory; private keys are written the same way.
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.
Logs
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.gzRetention follows the plan - see Logs and diagnostics.
Services
| Component | Linux unit | Windows service |
|---|---|---|
| Fleet agent | aethercertagent.service | AetherCertAgent |
| CA connector | not applicable | AetherCertCAConnector |
| Update Service | aethercertupdateservice.service | AetherCertUpdateService |
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 - the last so a standalone HTTP-01 or
TLS-ALPN-01 challenge can bind a low port without the service running as root.
systemctl status aethercertagent
journalctl -u aethercertagent -fThe 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 paths
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 removes
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.