Target Systems¶
What is a Target System?¶
A Target System is a server, service, or appliance that the Zaita platform deploys certificates to. When a certificate is issued or renewed, a deployment job is dispatched to a Bridge, which authenticates against the target system, installs the certificate and private key, applies any required configuration changes, and restarts the relevant service.
All certificate deployment to target systems is performed exclusively through a Bridge. The SaaS control plane never connects directly to a target system. The target system must be reachable from the Bridge assigned to the deployment job.
How Deployment Works¶
When a certificate deployment job is triggered — either manually from the web portal, via the API, or automatically on certificate issuance — the following sequence occurs:
- The back control plane creates a deployment job and encrypts the payload (including target system credentials) using the assigned Bridge's current public key.
- The Bridge retrieves and decrypts the job payload in memory.
- The Bridge authenticates against the target system using the decrypted credentials.
- The Bridge transfers the certificate and, where required, the private key to the target system.
- The Bridge applies the service-specific configuration — for example, updating a web server binding or reloading a configuration file.
- The Bridge restarts or reloads the target service.
- The Bridge reports the deployment outcome back to the SaaS control plane.
Decrypted credentials are never written to disk by the Bridge. They exist only in memory for the duration of the deployment operation.
Credential Security¶
Target system credentials — such as WinRM passwords or SSH private keys — are stored encrypted in the platform using ECDH key agreement (EC P-521) and AES-256-GCM symmetric encryption. The encryption key is derived from the tenant's Back Control Plane (BCP) public key. This means the Front Control Plane stores ciphertext it cannot itself decrypt — only the BCP, which holds the corresponding private key, can access credential plaintext.
When a deployment job requires credentials, the workflow is:
- The Front Control Plane reads the stored encrypted credential payload.
- It passes the payload to the Back Control Plane, which decrypts it using the tenant's private key.
- The BCP immediately re-encrypts the plaintext credential using the destination Bridge's short-lived public key.
- The plaintext is zeroed from memory and never persisted.
- The re-encrypted payload is forwarded to the Bridge, which decrypts it using its own private key for the duration of the deployment operation.
The Bridge's encryption key pairs have a maximum lifetime of 24 hours and are never reused.
Key Rotation¶
Each stored credential is tagged with a fingerprint of the BCP public key used to encrypt it. If the tenant's BCP key is rotated, the platform detects the mismatch and displays a warning on affected target systems, prompting the operator to re-enter and re-encrypt the credential under the new key.
Note: Key rotation does not automatically invalidate existing deployments, but credentials should be updated promptly after a BCP key rotation to ensure deployment jobs can proceed.
For a full description of the credential encryption model, see Security.
Supported Systems¶
The platform provides built-in deployment support for the following target system types.
Windows — via Windows Remote Management (WinRM)¶
| System | What the platform does |
|---|---|
| Microsoft IIS | Installs the certificate to the Windows certificate store, updates the HTTPS site binding, and restarts IIS |
| Windows Certificate Store | Installs the certificate to the specified Windows certificate store for use by any application that reads from the store |
| Microsoft Exchange Server | Installs the certificate and enables it for the configured Exchange services (SMTP, IIS, IMAP, POP) |
| Remote Desktop Services | Installs the certificate to the Windows certificate store and applies it to the RDP listener |
| Microsoft SQL Server | Installs the certificate to the Windows certificate store and configures SQL Server to use it for encrypted connections |
For Windows target systems, Just Enough Administration (JEA) can be configured to constrain the Bridge's PowerShell session to only the cmdlets required for certificate deployment. This is the recommended approach for enforcing least privilege. See Setting Up a Target System for configuration steps.
Linux — via SSH¶
| System | What the platform does |
|---|---|
| Nginx | Copies the certificate and private key to the configured paths and reloads the Nginx service |
| Apache HTTP Server | Copies the certificate and private key to the configured paths and restarts the Apache service |
| HAProxy | Writes a combined PEM bundle (certificate + private key) to the configured path and reloads HAProxy |
| Postfix | Copies the certificate and private key to the configured paths and restarts the Postfix service |
| Custom Script (Bash) | Copies the certificate and private key to the configured paths and executes a user-supplied Bash script |
The Custom Script option enables deployment to any Linux-based service not listed above. The script receives the certificate and key file paths and is responsible for any service-specific configuration and restart logic.
Deployment Orders¶
Every certificate deployment is tracked as a Deployment Order. Orders are created when a deployment is triggered — either manually from the portal or automatically by the renewal system — and remain visible in the Orders view until the deployment completes or fails.
Order Types¶
| Type | Description |
|---|---|
| Provisioning | First-time deployment of a certificate to a certificate profile that has not previously been deployed |
| Renewal | Replacement of an existing certificate approaching or past its renewal threshold |
Order Statuses¶
| Status | Description |
|---|---|
| Pending | Order created and waiting for the Bridge to pick it up |
| Processing | Bridge has claimed the order and is executing the deployment |
| Complete | Deployment succeeded |
| Failed | Deployment encountered an error — error details are recorded on the order |
| Cancelled | Order was cancelled manually, or was automatically cancelled after being in Pending or Processing status for more than one hour without progress |
Trigger Sources¶
Orders record what initiated the deployment:
| Source | Description |
|---|---|
| Manual | A user triggered the deployment from the portal |
| Renewal Threshold | The automated renewal job determined the certificate was due for renewal |
For information on viewing and managing orders, see Managing Target Systems — Deployment Orders.
Automatic Renewal¶
Each Certificate Profile includes a Renewal Threshold expressed as a percentage of the certificate's validity period. When the elapsed time since the last deployment exceeds that threshold, the platform automatically creates a Renewal order.
Example: A certificate with a 365-day validity and a 70% renewal threshold will trigger a renewal order at day 256 (365 × 0.70).
The renewal check runs daily. If a pending or processing renewal order already exists for a profile, the check skips that profile to avoid duplicate orders.
The renewal threshold can be adjusted per certificate profile. The default value is 70%.
Certificate Profiles¶
Each target system can have one or more Certificate Profiles. A Certificate Profile is a template that defines the full set of attributes for a certificate deployed to that system — including the Common Name (CN), Subject Alternative Names (SANs), key algorithm, digest, validity period, and X.509 extensions such as Key Usage and Extended Key Usage.
Profiles serve as the authoritative definition of what certificate a target system expects. They are not certificates themselves — they are used to generate certificate requests to the PKI when a deployment is triggered.
Multiple Profiles per Target System¶
A single target system can hold multiple profiles. This is particularly useful for systems that host more than one service or virtual host, each requiring a distinct certificate — for example, an F5 load balancer with separate certificates per virtual server, or an IIS server with multiple HTTPS sites.
Per-Profile Deployment Configuration¶
Each profile can override the default certificate file paths and service reload command configured on the target system. This allows a single server to host certificates for multiple services at different paths — for example, two Nginx virtual hosts with certificates in separate directories.
Policy Validation¶
Certificate profiles are validated against tenant certificate policies at save time, using the same policy engine as manual certificate requests. Policy rules that enforce values — such as algorithm, digest, maximum validity, or required SANs — are applied automatically and rendered as read-only fields in the profile form. Violations of hard-fail policy rules block the profile from being saved. Soft-fail warnings are stored against the profile and displayed on the profile view page.
For information on managing certificate profiles, see Managing Target Systems — Certificate Profiles.
Adding Support for Additional Systems¶
For services not covered by the built-in target system types, the Custom Script option on Linux provides full flexibility. On Windows, certificates installed to the Windows Certificate Store are accessible to any application that reads from the store, covering a broad range of services without bespoke deployment logic.
For deployment to network appliances, load balancers, or other systems not accessible via WinRM or SSH, contact [email protected] to discuss your requirements.