EST

EST (RFC 7030) is a modern, HTTPS-based certificate enrollment protocol designed as a secure replacement for SCEP. Clients authenticate using one of several supported modes, then request and receive certificates over a standard TLS connection. Horizon ships a full EST client in horizon-cli.

How it works

1. The client connects to the Horizon EST endpoint over HTTPS.
2. The client authenticates using one of the supported authorization modes (see below).
3. The client submits a CSR; Horizon validates it against the profile and issues the certificate.
4. On renewal, the existing certificate authenticates the request — no human involvement needed.

Authorization modes

Horizon's EST profile supports four authorization modes, configured per profile:

• Challenge — the client presents a one-time password generated in the Horizon WebRA or via API. Used for initial enrollment when the device has no existing certificate.
• X509 — the client presents an existing certificate from a trusted CA (mutual TLS). An optional whitelist restricts which certificates are accepted.
• Authorized — the client presents an existing Horizon-issued certificate. Tighter than X509 as it requires the certificate to already be known to Horizon.
• Auto Validation — enrollment requests are approved automatically based on configurable rules and a threshold (a minimum number of rules must pass). No operator action required after setup.

The Horizon Agent (horizon-cli) uses the Challenge mode for initial enrollment and then transitions to certificate-based authentication for all subsequent renewals, eliminating the need for any further human involvement.

Enrollment modes

EST profiles support two enrollment modes, which can be enabled independently:

• Decentralized (default) — the client generates its own key pair and submits a CSR. Horizon signs it and returns the certificate.
• Centralized — Horizon generates the key pair server-side and returns a PKCS#12 bundle. Useful for devices or systems that cannot generate their own keys. Private keys can optionally be escrowed in Horizon for later recovery.

Where EST fits

• Linux servers and appliances — horizon-cli handles enrollment and renewal as a system service, executing post-renewal scripts (reload Nginx, restart the JVM, etc.) after each certificate replacement.
• Modern network devices — routers and firewalls that advertise RFC 7030 support can enroll directly without the agent.
• IoT and embedded devices — compact protocol, TLS-only transport, no DCOM or Active Directory dependency.

The Horizon Agent (horizon-cli) uses EST by default and is the recommended enrollment method for any server or workstation that can run it. If you are choosing between EST and SCEP for a device, prefer EST.

Compared to SCEP

EST uses mutual TLS for renewal rather than a shared challenge password, making credential exposure narrower and renewal more secure. SCEP remains the right choice for devices that do not support EST — most legacy network equipment falls into this category.

Compared to ACME

Both EST and ACME are standards-based and automatable. ACME requires domain validation through a challenge; EST authenticates the device itself using a challenge password or existing certificate. EST is better suited to internal devices without public DNS, or any workload where proving domain ownership is not meaningful.

EST endpoint URL

The Horizon EST endpoint follows this pattern:

https://<horizon-host>/api/v1/est/<profile-name>/

Each EST profile has its own endpoint, so different profiles can enforce different authorization modes and issuance policies.

Configuring EST in Horizon

EST is enabled per-profile under Protocols → EST. Refer to the Horizon Client EST documentation for enrollment and renewal commands.

Automation guides using EST

• Windows IIS — via horizon-cli automate