PKI Connectors

Description

A "PKI Connector" is a configuration piece that allows to establish the communication with any supported PKI. Additionally, it enables to map a specific certificate profile within the connected PKI.

PKI Connectors Diagram

Common prerequisites

To grant "Horizon" proper access to a given PKI, three categories of requirements must be gathered:

  • Credentials: It could be either certificates (PKCS#12 format) or technical accounts (login/password) allowing to authenticate against the PKI API.

  • Permissions: The credentials must be granted with the proper permissions on the PKI in order to be able to manage certificate lifecycle (enroll, revoke, renew).

  • Profile/Certificate information: This information is used to map certificate types and/or certificate fields.

Asynchronous certificate lifecycle

Some PKIs cannot return a certificate within Horizon’s synchronous request timeout, typically because they require an extended validation (manual review, email or phone confirmation, …​). Connectors that support asynchronous issuance let Horizon return a non-final request status, then resume the lifecycle in the background.

When a request has been submitted, but no certificate has yet been delivered, it is In Progress. The request is polled periodically by a background process until the certificate is available or the order is canceled. As the requester, an in_progress request can be canceled. As an approver, it can be denied. Either action cancels the underlying order on the PKI.

Asynchronous behavior is only used by enrollment workflows that opt in to it (currently WebRA enroll and renew). Protocol-driven workflows (ACME, SCEP, EST, …​) still run in synchronous mode to preserve their existing semantics.

At enrollment time, Horizon first performs a short synchronous polling cycle within the connector’s configured timeout. If a certificate is returned during that window, the request completes as usual. Otherwise, the request is switched to in_progress and a background process takes over.

Asynchronous Enrollment decision flow
Figure 1. Asynchronous Enrollment decision flow

Once a request is in_progress, a background actor polls the PKI on the schedule defined by horizon.async-poll.interval (default: every 5 minutes). Retry intervals grow in 5-minute increments up to one hour. A successful poll updates the certificate; a transient error logs an event and reschedules the next poll; a fatal error switches the request to failed.

Public PKI reissue

To accommodate the gap between order lifetime (typically one year) and the reduced certificate lifetime imposed by the CA/Browser Forum (200 days, decreasing toward 47 days), public PKI connectors that support it now reissue a certificate on the same order during renewal instead of creating a new order, as long as the order is still valid.

The behavior is automatic and transparent:

  • on renewal, if the connector reports an order expiration metadata (PKI_ORDER_EXPIRATION) and the order is not in its renewal period, Horizon issues a reissue against the existing order and inherits the original order expiration;

  • if the order is in its renewal period, or if the connector does not expose an order expiration, Horizon falls back to a classic enroll, which creates a new order on the PKI.

This guarantees that the certificate issued by a renewal is never already in its renewal period, and that subscriptions are consumed through to their end.

Reissue vs. classic enroll decision flow
Figure 2. Reissue vs. classic enroll decision flow

Connectors with reissue support are:

  • GlobalSign MSSL

  • Nameshield