Choose the right protocol
When to use the Horizon Agent, and which enrollment protocol to pick when you can't.
Horizon supports several certificate enrollment protocols. Before choosing one, ask a simpler question first: can the Horizon Agent run on this system? If yes, use the Agent. That recommendation applies in almost every case where you are enrolling certificates on a server or workstation.
Use the Horizon Agent where you can
The Horizon Agent (horizon-cli) is the recommended enrollment method for any system that can run it: Linux servers, Windows servers, and workstations outside of Group Policy auto-enrollment. The Agent uses EST (preferred) or SCEP under the hood, handles initial enrollment and all subsequent renewals automatically, and can run post-renewal scripts to reload services after a certificate is replaced.
The Agent removes the need to choose, configure, and maintain a protocol integration directly. It speaks to Horizon, tracks certificate expiry, and renews before certificates expire — without any human involvement after the initial setup. When the CA/Browser Forum caps publicly trusted TLS certificates at 47 days, automation of this kind is not optional; the Agent is the most reliable way to meet that requirement.
Use the Agent for:
- Linux servers running web servers, application servers, or any TLS-terminating service
- Windows servers not enrolled via Group Policy
- Any workload where you control the operating system and can install a service
If a system can run the Agent, do not work around it by configuring ACME, a raw EST client, or a manual SCEP workflow. The Agent is the more maintainable path.
Protocol quick reference
When the Agent cannot be used, choose the protocol that matches what the endpoint already supports.
| Protocol | Use when | Auth | Notes |
|---|---|---|---|
| Agent (EST/SCEP) | Any server or workstation that can run horizon-cli | Challenge password → mTLS renewal | Always preferred |
| WSTEP / WCCE | Windows domain members via Group Policy | Kerberos (AD) | Zero client change; built into Windows |
| ACME | Apps and appliances with a built-in ACME client | Domain validation or EAB | Only where Agent cannot be used |
| EST | Modern network devices that speak RFC 7030 | Challenge password or mTLS | Prefer over SCEP when supported |
| SCEP | Network gear, MDM platforms (Intune, Jamf), legacy devices | Challenge password | Use when nothing else is available |
When the Agent is not an option
Applications and appliances with a built-in ACME client
Some software and appliances have an ACME client integrated directly and no practical alternative enrollment path. In these cases ACME is not a trade-off — it is simply what the system supports. Examples:
- Caddy and Traefik — both terminate TLS and renew certificates natively using ACME. Deploying a separate Agent alongside them adds complexity without benefit.
- Proxmox VE — the hypervisor management interface includes a built-in ACME client. There is no other supported automated enrollment method for the Proxmox UI certificate.
- Synology DSM — Synology NAS devices have a native ACME integration for the device management certificate. EST and SCEP are not available on DSM.
- Cisco Secure Firewall (ASA/FTD) — Cisco has added native ACME support to ASA and Firepower Threat Defense for VPN and management interface certificates, in addition to existing SCEP support. Where the device runs a firmware version that includes the ACME client, it is the simpler path for publicly trusted certificates.
Some of these systems also expose an API that could in principle be used to push certificates issued by Horizon — Proxmox, for example, has a REST API that accepts certificate uploads. This is technically possible using the Horizon Client's post-renewal hooks with custom scripting, but it falls outside our service offering and is not a supported configuration. ACME remains the recommended path for all systems listed above.
When one of these systems is already managing TLS for a workload, configure it to use Horizon's ACME endpoint. Prefer the Agent for any general-purpose server where you have a choice — the Agent provides more control over renewal timing, post-renewal hooks, and certificate visibility in Horizon, and does not require DNS credentials or public port 80 access.
See ACME.
Network devices
Firewalls, switches, routers, and VPN concentrators rarely support the Horizon Agent. For these:
- Use EST if the device supports RFC 7030. EST uses TLS for transport and mTLS for renewal, making it more secure than SCEP. Most modern network operating systems that support automated enrollment support EST.
- Use SCEP if the device does not support EST. SCEP is universally supported across network gear and is the correct fallback for devices that cannot speak EST or ACME.
Do not configure ACME on network devices unless the device has an ACME client built in. The DNS-01 challenge required for wildcard or internal hostname certificates introduces DNS write credentials into the device — an attack surface without commensurate benefit on infrastructure that already has SCEP or EST.
MDM-managed endpoints
For mobile devices and managed endpoints enrolled through Intune or Jamf, use SCEP. MDM platforms request SCEP certificates on behalf of the device; the device itself does not interact with Horizon directly. Configure Horizon's SCEP endpoint in the MDM platform and let it handle certificate delivery.
See SCEP.
Summary
The decision is straightforward in most cases:
- Can the Horizon Agent run here? Yes → use the Agent.
- Is this a Windows domain member enrolling via Group Policy? Yes → use WSTEP/WCCE.
- Does the system have a built-in ACME client with no other enrollment path? Yes → use ACME.
- Is this a network device? Use EST if supported; SCEP otherwise.
- Is this an MDM-managed endpoint? Use SCEP.
If none of the above apply, revisit whether the Agent can be deployed. In almost every remaining case it can.