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.