Deploy targets

A deploy target tells the agent what to do with a certificate once it has it. Without one, issuance would leave a certificate sitting in a file nobody reads.

Pick one inline on a certificate job or a certificate policy, or save it as a reusable object under Manage > Deploy Targets and reference it from any number of certificates. A saved target means one copy of an appliance credential instead of one per certificate; editing it changes every certificate that references it at that certificate's next deployment, and deleting one that is still referenced is refused.

The catalogue

31 presets across 7 families. Presets that share a mechanism share a dispatch type and differ only in their defaults and extra fields.

Windows roles

Exchange, AD FS, RDS deployment, SQL Server, Skype for Business, Hyper-V Replica, VMware Horizon and Citrix StoreFront all assume the agent runs on that server itself

• for an RDS deployment, on or able to reach the RD Connection Broker - with the relevant management tooling already installed. aethercert installs none of it.

For a multi-server StoreFront group, run Propagate Changes in the StoreFront console on the other nodes yourself. That is server-group topology the agent has no visibility into.

Every preset that imports into a certificate store offers an exportable private key option, for the case where something else has to re-export the key from the store later. It requires the Standard plan.

Web servers

All four accept an optional HTTP-01 webroot, which makes HTTP-01 challenges write into an existing document root instead of the agent binding port 80.

The NGINX preset does one extra thing

It parses the user directive out of nginx.conf to find which OS user the worker processes run as, and grants that user read access to the private key before reloading.

This matters more than it sounds. NGINX workers almost always run as an unprivileged user (www-data, nginx). A key written root-only cannot be read by them, so the reload appears to succeed while NGINX quietly carries on serving the old certificate. The failure surfaces weeks later, as an expiry.

If the config cannot be read or no user directive is found, the key is left owned by the agent's own user and a warning is logged. Nothing is guessed. The Custom preset does not do this - if you use it for NGINX, handle the permissions yourself.

Why HAProxy is its own preset

HAProxy wants the certificate, chain and private key concatenated into one PEM bundle, not separate files. Configure a Runtime API socket and the new certificate is applied through it with no restart; leave it blank and it falls back to the reload command.

Load balancers

Firewalls

Hypervisors and virtualization

VMware Horizon is filed under Windows roles rather than here: replacing its certificate is a Windows certificate-store operation, not a vSphere API call.

DevOps and orchestration

Authenticate Kubernetes with a least-privilege ServiceAccount token scoped to the one namespace and Secret it needs, never a cluster-admin credential. The Docker target needs the agent's service account to reach the local socket or named pipe, equivalent to docker group membership on Linux.

Custom scripts

Available on both Windows and Linux, for anything the presets do not cover. It runs a script that already exists on the agent host and passes your own variables as environment variables named AC_VAR_<NAME>.

Before a script runs it has to pass four checks, and none of them is skippable:

1. The name resolves inside the agent's scripts directory, with no traversal and no symlink escape.
2. It is a regular file.
3. It is not group- or world-writable.
4. It is owned by root.

Execution is bounded at 60 seconds. The script is run with real argv - exec(scriptPath) on Linux, powershell.exe -File <script> on Windows - never through a shell string, so nothing in a variable's value can inject a command. Its environment is built from scratch rather than inherited: PATH, HOME and LANG on Linux, SystemRoot, windir, PATH and ComSpec on Windows, plus your AC_VAR_* entries. A variable named PATH becomes AC_VAR_PATH, so it cannot shadow anything; a short list of names is refused outright as a guard against typos.

Its exit code and the tail of its output are recorded on the job.

Placeholders in target fields

Any text field on a deploy target - a file path, a script filename, a certificate object name, a custom script variable - can use {{hostname}}, {{hostname_short}} or {{agent_name}}. They are resolved against whichever agent the job is dispatched to, immediately before it is sent.

These are more permissive than the same placeholders in a certificate policy's common name: they are not restricted to hostname-safe characters, and an unknown {{...}} is left in place rather than rejected. That makes them usable for a per-host script argument or an object name that should vary by agent.

What each target needs

An agent runs one operating system, so a Linux agent cannot carry out a Windows-only preset and vice versa. Targets that talk to a remote API work from either. The certificate form filters the list accordingly, and a policy reports a member whose OS cannot run its target as not applied rather than failing the job.

How deployments behave

Every deployment is idempotent. Running the same target twice with the same certificate converges on the same end state rather than accumulating duplicates. File targets overwrite in place; API targets that create named objects upsert them; Windows store imports tag what they create and clean up the previous entry after the new one is confirmed, so a cleanup failure leaves a stale entry rather than no certificate.

Rolling back is redeploying. Because deployment is idempotent, the undo for a bad certificate is deploying the previous one again - the agent caches the material for exactly that. Only Kubernetes implements a real removal, because deleting a Secret is genuinely different from replacing its contents.

Failures are classified. A deploy error the connector recognises as permanent - bad credentials, an object name the target does not know, a request it rejected outright - stops the job immediately instead of burning its remaining retries on an identical failure. Connection refused, a timeout or a 5xx is temporary and retried; an explicit rate limit schedules the next attempt. An error a connector cannot classify is treated as retryable.

TLS to a management endpoint requires TLS 1.2 or newer. Each appliance preset has its own allow self-signed TLS checkbox, which is the only way to lower that for one target. Some appliance management planes are still TLS 1.0 or 1.1 only, where the handshake fails before certificate verification is even reached.

Private keys are written 0600 inside a 0700 directory. The NGINX target widens read access to exactly one resolved user - never to a group, never to world.

Verification status

Every deploy target is implemented against its vendor's own documented API or management tooling. Most have not been exercised against real infrastructure of that type. Validate a new target in a staging environment before relying on it for a production renewal.

For the two in the last row, the vendors publish no example success or error response for the operations involved. Both connectors read their target's response defensively; a failure there is more likely to need a look at the appliance than at aethercert. If a target behaves unexpectedly, include the job's ID when you contact support.