Deploy targets
Where a certificate lands once issued: Windows roles, web servers, load balancers, firewalls, hypervisors, Kubernetes, Citrix NetScaler, Docker, and custom scripts.
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.
It is chosen per certificate, in Build > Certificate Job, grouped by platform and vendor: Windows roles, web servers, load balancers, firewalls, hypervisors & virtualization, DevOps & orchestration, and custom scripts.
A deploy target can also be saved as a standalone, reusable object under Manage > Deploy Targets instead of configured inline on every certificate - useful when many certificates deploy to the same appliance or cluster, since it means one saved credential instead of one per certificate.
Windows roles
| Preset | What it does |
|---|---|
| Certificate store | Imports into the local machine certificate store. Creates no binding - use it when another process picks the certificate up by thumbprint. Also what NPS (RADIUS/PEAP), RRAS (IKEv2 VPN) and DirectAccess need - they auto-select a matching certificate by hostname. |
| IIS | Imports into the store and creates or updates the site's HTTPS binding. Also what NDES (SCEP), AD CS Web Enrollment, WSUS, Print Server (Internet Printing) and SCCM/MECM's management/distribution points need - they're all IIS sites under the hood. |
| Exchange | Runs Import-ExchangeCertificate and enables the certificate for the services you choose - IIS, SMTP, POP, IMAP. |
| ADFS | Imports into the store, then runs Set-AdfsSslCertificate or Set-AdfsCertificate, depending on the certificate usage you select (service communications, token signing, or token decrypting). |
| RDP / RDS listener | Imports into the store and points a standalone Remote Desktop listener at it via WMI - for a single server, not a full RDS deployment. |
| RDS deployment | Runs Set-RDCertificate against a full Remote Desktop Services deployment - RD Gateway, RD Web Access, RD Connection Broker, or RD Licensing. |
| WinRM (HTTPS listener) | Imports into the store and replaces the WinRM HTTPS listener, so PowerShell remoting over HTTPS picks up the new certificate. |
| SQL Server | Imports into the store and points the SQL Server Database Engine instance's Native Client configuration at it, with an option to force encryption and restart the service. |
| Skype for Business / Lync | Runs Import-CsCertificate then Set-CsCertificate for the certificate usages you select. |
| Hyper-V Replica | Imports into the store and configures it as the Hyper-V Replica server's authentication certificate. |
| VMware Horizon | Imports into the store under the exact name Horizon requires, then restarts the Connection Server service. |
| Citrix StoreFront | Imports into the store and creates or updates the IIS HTTPS binding StoreFront serves from. |
Exchange, ADFS, RDS deployment, SQL Server, Skype for Business, Hyper-V Replica, VMware Horizon and Citrix StoreFront all assume the agent runs on that server itself (RDS deployment: on or reachable from the RD Connection Broker), with the relevant management tooling already installed. aethercert does not install Exchange, ADFS, Skype for Business or Citrix tooling.
Every preset above that imports into the certificate store supports an exportable private key option under Advanced Options, for the case where something else needs to re-export the key from the store later. It requires the Standard plan.
Web servers
All three Linux file-based presets do the same thing: write the certificate, chain and private key to disk, then run a reload command. They differ only in their defaults.
| Preset | Default reload command |
|---|---|
| NGINX | systemctl reload nginx, plus the key-permission handling below |
| Apache | systemctl reload apache2 |
| Custom | None - set your own paths and command for anything else that reads certificates from disk |
The NGINX preset does one extra thing
It parses the user directive out of nginx.conf (default /etc/nginx/nginx.conf,
configurable) to find which OS user the worker processes run as, and grants that user
read access to the private key - chown plus mode 0600 - 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.
HAProxy
Unlike NGINX and Apache, HAProxy wants the certificate, chain and private key concatenated into one PEM bundle, not separate files - so this is its own preset rather than a variant of the file-based ones above. If you configure a Runtime API socket, the new certificate is applied with zero downtime through it; otherwise it falls back to a full reload.
Load balancers
F5 BIG-IP
Uploads the certificate and key via F5's iControl REST API and creates or updates the
named SSL objects. If you configure a Client SSL profile, that profile is updated to
reference them too. Partition-aware (defaults to Common).
Kemp LoadMaster
Uploads the certificate to a Kemp/Progress LoadMaster over its management API. If you configure a Virtual Service, the new certificate is bound to it automatically.
Citrix NetScaler
Uploads the certificate and key to a Citrix ADC / NetScaler appliance over its Nitro
management API, and creates or updates the matching sslcertkey object. It works from
an agent on either operating system - it is a plain HTTPS call.
It does not bind the certificate to an SSL vserver. That is environment-specific enough that it is left as a deliberate manual step in NetScaler after deployment.
Firewalls
FortiGate
Imports the certificate as a FortiOS local certificate via FortiOS's REST/monitor API, VDOM-aware. Only the leaf certificate is uploaded - a chain FortiGate needs to serve alongside it isn't included, and would need importing separately as a CA certificate in FortiOS.
Palo Alto Networks (PAN-OS)
Imports the certificate and key via the PAN-OS XML API, then commits the change and waits for the resulting commit job to finish - PAN-OS requires an explicit commit before an imported certificate takes effect.
Cisco Secure Firewall (FMC)
Updates an Internal Certificate object on a Firepower Management Center. FMC stages configuration centrally; list device UUIDs to also push ("Deploy") the change to those managed devices, or leave it blank to update the object only.
Sophos Firewall
Uploads the certificate via Sophos Firewall's own API.
WatchGuard Firebox
Imports and installs the certificate via WatchGuard Cloud's REST API. This works only for a Firebox that is fully managed through WatchGuard Cloud - a device that Cloud only monitors, with configuration still done locally, cannot be reached this way.
Hypervisors & virtualization
VMware vCenter Server
Replaces vCenter Server's own Machine SSL certificate - what a browser or API client sees connecting to vCenter itself - via the vSphere Automation REST API. Does not touch individual ESXi hosts' certificates.
Nutanix Prism
Imports the certificate into Nutanix Prism (Central or Element) via its certificate-management API. The key type is detected automatically from the issued certificate.
Proxmox VE
Uploads a custom certificate to a Proxmox VE node via its REST API, using an API token.
DevOps & orchestration
Kubernetes
Creates or updates a kubernetes.io/tls Secret via the cluster's own API server
directly - no kubectl or cluster tooling required on the agent host. Authenticates
with a bearer token; use a least-privilege ServiceAccount token scoped to the one
namespace and Secret it needs, never a cluster-admin credential. You can optionally list
Deployments in the same namespace to restart afterward, since most workloads only read a
mounted Secret when their pod starts and won't notice it changed underneath them
otherwise.
Docker container
Talks to the Docker Engine API directly - not the docker CLI - over the local Unix
socket (/var/run/docker.sock on Linux and macOS) or named pipe
(\\.\pipe\docker_engine on Windows). The agent's service account needs access to it,
equivalent to docker group membership on Linux.
It copies the certificate, chain and key into the running container at the paths you configure - paths inside the container, not on the agent host - and then either runs your reload command inside the container via the Exec API, or, if you leave that blank, restarts the container outright.
Custom script
Available under both Windows and Linux, for anything the presets do not cover.
It runs a script that already exists on the agent host, passing your own variables
as environment variables named AC_VAR_<NAME>. Values are never interpolated into a
shell command, so nothing in a variable's value can inject additional commands. Flag a
variable secret and it is stored encrypted in Vault and never shown again once
saved.
This is deliberate, and it is the single most important boundary in the product: the dashboard is never a channel for pushing new code onto your infrastructure. A compromised account can at most change which already-approved script runs, and with what variables. It cannot introduce script content.
Placeholders in target fields
Any text field on a deploy target - a file path, a script filename, a certificate 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 a certificate name
that should vary by agent.
What each target needs
| Target | Requirement on the host |
|---|---|
| Windows store, IIS | Local administrator |
| Exchange | Agent on the Exchange server, Exchange Management Shell present |
| ADFS | Agent on the ADFS server, ADFS PowerShell module present |
| RDS deployment | Agent on or reachable from the RD Connection Broker, RemoteDesktop PowerShell module present |
| SQL Server | Agent on the SQL Server host |
| Skype for Business / Lync | Agent on the front-end server, Management Shell present |
| Hyper-V Replica | Agent on the Hyper-V host |
| VMware Horizon | Agent on the Connection Server itself |
| Citrix StoreFront | Agent on the StoreFront server itself |
| Linux file-based presets, HAProxy | Write access to the configured paths, and permission to run the reload command |
| F5, Kemp, NetScaler, FortiGate, Palo Alto, Cisco FMC, Sophos, WatchGuard, vCenter, Nutanix, Proxmox | Network reach to the management endpoint, and API credentials with permission to manage certificates |
| Kubernetes | Network reach to the cluster API server, and a ServiceAccount token scoped to the target namespace |
| Docker | Access to the Docker socket or named pipe |
| Custom script | The script already present in the agent's scripts directory |
Verification status
Every deploy target is implemented against its vendor's own documented API or
management tooling. Most have not yet been exercised against real infrastructure of that
type - validate a new target in a staging environment before relying on it for a
production renewal. linux_file, nginx, docker, windows_store and netscaler are
the most battle-tested; everything added more recently carries a higher share of
first-production-use risk. If a target behaves unexpectedly, contact support
with the certificate job's ID.