aethercert
Documentation

Agent known issues

Current limitations of the aethercert agent, CA connector, Update Service and tray, with the workaround for each.

Limitations that are real and current. Each one says what the workaround is.

Only linux/amd64 and windows/amd64 are published

There is no arm64 build today. The bootstrap installer refuses any other architecture rather than half-installing.

The CA connector is Windows-only

Active Directory Certificate Services, certreq.exe and certutil.exe exist only on Windows Server, so there is no Linux connector build. An internal CA that speaks ACME or exposes an HTTP signing endpoint needs no connector at all.

Enrollment tokens expire after an hour

Every token is valid for one hour from creation, and a multi-provision token is capped at 500 redemptions.

Workaround. Mint the token as part of a provisioning run rather than baking one into an image. See Unattended rollout.

An agent's credential cannot be rotated in place

There is no rotate operation. Re-register in the dashboard mints a token scoped to that one agent and updates it in place, which covers a lost or rejected credential; the only other route is revoking the agent and enrolling a new one.

check_in_interval_seconds in config.json is not the real cadence

It is the value --check-in-interval wrote at install time and a pre-enrollment fallback only. The cadence the agent uses is whatever the control plane returns on every heartbeat.

Workaround. Change the cadence under Manage > Agents.

A custom-script deploy target receives no certificate material

It runs your hook with your variables in its environment. It does not write the certificate, chain or key anywhere and passes no paths to the script.

Workaround. Give the certificate a second deploy target that writes the files, or have the script fetch the material from wherever your environment keeps it.

A custom script is capped at 60 seconds

Execution is bounded, and a script that overruns is reported as a temporary failure and retried.

Workaround. Have the hook hand off to something asynchronous rather than doing the slow work inline.

Most third-party deploy targets have not been exercised against real hardware

Every deploy target is implemented against its vendor's own documented API, but only a handful have been run against the real product. Sophos Firewall and WatchGuard Firebox go further: the vendors publish no example success or error response for the operations involved, so those connectors read the response defensively.

WatchGuard's install is asynchronous with no documented way to confirm on-device completion, so a successful job confirms submission, not installation.

The full breakdown is on Deploy targets.

Workaround. Validate a new target in a staging environment before a production renewal depends on it.

Some targets deliberately stop short of binding

NetScaler creates or updates the sslcertkey object but does not bind it to an SSL vserver. Kemp binds only when you name a Virtual Service. FortiGate imports the leaf only, not an intermediate chain. Citrix StoreFront cannot propagate changes across a server group. Each is a deliberate stop, not a bug, and each is documented on Deploy targets.

A host without the Update Service never updates

--no-update-service at install time, or a container running aethercert-agent run directly, leaves nothing on the host that can replace the binary.

Workaround. Run aethercert-update-service update --agent by hand, or rebuild the image.

The tray runs unelevated

It is launched for the logged-in user from an HKLM Run key, not as a service. Whether it can reach a backend's local pipe therefore depends on the host's own token elevation. It is a convenience - check for updates, open logs, sync now - and nothing depends on it.

Reporting something that is not on this list

Help > Report a Bug in the dashboard. Include the agent's version, the output of aethercert-installer status, and the relevant lines from the day's log.

On this page