Certificate Profiles
Configure the certificate profiles that define enrollment rules for each protocol.
A certificate profile defines the enrollment rules for a specific protocol — it connects a PKI connector to settings such as authorization mode, key types, renewal period, and certificate template constraints. Each protocol (EST, SCEP, ACME, WebRA) has its own set of profiles; a profile created for EST cannot be used for WebRA, and vice versa.
You must have at least one profile for a protocol before any client or user can enroll through it.
The two most common starting points are:
- EST profiles — used by
horizon-cliautomation commands and direct EST enrollment. - WebRA profiles — used for manual certificate requests through the Horizon web interface.
SCEP and ACME profiles follow the same pattern with protocol-specific fields.
This guide covers the most common configuration options. Not all fields are documented here. For advanced configuration refer to the Evertrust Horizon documentation.
Prerequisites
- A PKI connector for the CA that will issue certificates. For SwissSign, see Configure SwissSign MPKI.
Create an EST profile
In Horizon, go to Protocol > EST and click Add. The profile editor is split into tabs, described below.
EST Specific Configuration
This tab contains all settings specific to the EST protocol.
General
| Field | Description |
|---|---|
| Name | Unique identifier for this profile. Referenced by automation policies and horizon-cli. Names cannot be changed after creation. |
| Display name | Human-readable label shown in the UI. Can be changed later. |
| Enabled | Uncheck to disable enrollment on this profile without deleting it. Default: enabled. |
| PKI Connector | The connector that will issue certificates for requests against this profile. |
Authorization mode
Controls how enrolling clients authenticate. Choose one:
| Mode | How it works | Use when |
|---|---|---|
| Authorized | Clients authenticate with an API key (api_id / api_key). | Unattended automation via horizon-cli. |
| Challenge | Clients present a one-time password obtained from a Horizon operator via --challenge. | One-off enrollments or environments without a service account. |
| x509 | Clients authenticate using an existing trusted certificate. | Renewal by Proof of Possession — the client proves ownership of the certificate being renewed. |
| Auto-validation | Requests are approved automatically without human review. | Environments where the CA and template provide sufficient control. |
Each mode requires selecting a CA for enrollment and optionally enables a whitelist to restrict which clients are accepted.
Renewal management
| Field | Description |
|---|---|
| Renewal period | How far in advance of expiry the Horizon Client starts attempting renewal (e.g. 30 days). |
| Renewal CAs | (Optional) Restrict which CAs may issue the renewed certificate. |
Crypto Policy
| Field | Description |
|---|---|
| Decentralized enrollment | The client generates the private key locally and submits a CSR. The private key never leaves the host. Always prefer this mode. |
| Centralized enrollment | Horizon generates the private key and returns the certificate and key as a PKCS#12 bundle. Only use this when key escrow is a hard requirement — it means the private key is generated and handled server-side. |
| Default Key Type | The key type used when no key type is specified by the client, or when centralized enrollment is used and Horizon generates the key. |
| Authorized Key Types | Restricts which key types clients may submit. Leave empty to allow all. Common values: rsa-2048, rsa-4096, ec-secp256r1, ec-secp384r1. |
Common Configuration
This tab contains settings shared across all profile types.
Constraints
Constraints restrict which values are accepted in certificate requests for this profile.
| Field | Description |
|---|---|
| Allowed email domains | A regex pattern that contact emails and RFC822 SANs must match. Applied to the domain part after @. Leave empty to allow any. |
| Allowed DNS domains | A regex pattern that DNS SAN values must match. Leave empty to allow any. |
Workflow
This tab configures authorization levels and approval flows for each certificate operation — who can request, approve, and act on certificates under this profile. Refer to the Evertrust Horizon documentation for details.
Template
This tab defines the structure of the certificate's Subject DN, SANs, and extensions. It is optional — if left empty, CSRs are passed through to the PKI as-is.
When a template is defined, it constrains which fields are accepted and how they are filled. For each DN element or SAN you can set:
- Mandatory — the field must be present in the request.
- Editable by requester / approver — whether the value can be overridden at request time.
- Default value — a fixed value applied if the requester does not supply one.
- Regex — a pattern the submitted value must match.
- Computation rule — a dynamic expression that sets the value, overriding requester input.
When a template is defined, at least one mandatory Common Name must be included in the Subject DN. Any CSR field not covered by the template is rejected.
For public TLS certificates, we recommend the following settings:
| Section | Element | Enable | Mandatory | Editable by requester | Maximum |
|---|---|---|---|---|---|
| Subject DN composition | CN | Yes | Yes | Yes | — |
| SANs composition | DNS | Yes | — | Yes | 1 for single-domain certificates, otherwise unrestricted |
Metadata
This tab controls how organizational metadata is attached to certificates issued under this profile.
Labels
Labels are custom key-value tags attached to each certificate. Define which labels appear on the request form, which are mandatory, and whether requesters or approvers can set or change them. Useful for tracking ownership, environment (prod, staging), or any classification your organization needs.
Ownership policy
Determines who owns certificates under this profile and how that ownership is recorded.
| Field | Description |
|---|---|
| Owner | The individual responsible for the certificate. Configure whether it is mandatory and who can set it. |
| Contact email | A notification address tied to the certificate, used for expiry alerts. Configure whether it is mandatory and who can set it. |
| Team | Associates the certificate with a Horizon team for shared visibility and access. Configure whether it is mandatory and who can set it. |
Notifications / Triggers
This tab wires notification triggers to certificate and request lifecycle events.
Certificate lifecycle notifications fire when a certificate is enrolled, renewed, revoked, or nearing expiry.
Request lifecycle notifications fire at each stage of the approval workflow — when a request is submitted, pending approval, approved, or cancelled. Use these to alert approvers when action is required, or to confirm outcomes to requesters.
Select a pre-existing email, REST, or groupware notification for each event you want to cover.
Reference the profile
After saving, the EST profile name is referenced in an automation policy. See Automation Policies for the next step.
Other protocol profiles
Each protocol requires its own profile. The prerequisite is always the same — a compatible PKI connector — and the creation steps follow the same tab structure.
| Protocol | Navigate to | Used by |
|---|---|---|
| WebRA | Protocol > WebRA | Manual certificate requests in the Horizon web interface |
| SCEP | Protocol > SCEP | SCEP-capable devices and MDM systems |
| ACME | Protocol > ACME | ACME clients (e.g. certbot, cert-manager) |
To reuse an existing profile as a starting point, open the profile list and click Duplicate next to any profile. This creates a copy with all settings preserved, which you can then rename and adjust.