Target System Best Practices¶

Service Accounts¶

Use a Dedicated Deployment Account¶

Create a dedicated service account on each target system exclusively for use by the Zaita platform. Do not share accounts with other automation tools, applications, or human users. A dedicated account:

Makes audit logs unambiguous — all deployment activity is clearly attributable to the platform.
Enables targeted credential rotation without affecting other tools.
Limits the blast radius of a compromised credential to deployment operations only.

Apply Least Privilege¶

Grant the deployment account only the permissions required for certificate installation and service management. Avoid administrator or root-level access where a narrower permission set is sufficient.

Recommended minimum permissions by system type:

System	Minimum Permissions
Microsoft IIS	Write to certificate store; manage IIS bindings; restart IIS service
Windows Certificate Store	Write to the specific target store only
Microsoft Exchange Server	Manage Exchange certificates; restart specified Exchange services
Remote Desktop Services	Write to certificate store; modify RDP listener configuration
Microsoft SQL Server	Write to certificate store; modify SQL Server network configuration; restart SQL Server service
Nginx / Apache / Postfix	Write access to certificate and key file paths; permission to run the reload/restart command via `sudo`
HAProxy	Write access to the PEM bundle path; permission to run the reload command via `sudo`
Custom Script	Write access to certificate and key file paths; permission to execute the deployment script

For Linux systems, use sudoers entries scoped to the exact commands the deployment account needs to run, rather than granting unrestricted sudo access:

zaita-deploy ALL=(ALL) NOPASSWD: /bin/systemctl reload nginx
zaita-deploy ALL=(ALL) NOPASSWD: /bin/systemctl restart apache2

Use JEA for Windows Target Systems¶

For Windows target systems, configure a Just Enough Administration (JEA) endpoint rather than granting the deployment service account local administrator rights. JEA constrains the PowerShell remoting session to only the cmdlets required for certificate deployment, providing defence in depth even if the service account credentials are compromised.

Key benefits of JEA for certificate deployment:

Session-level least privilege — the deployment account can only run the cmdlets explicitly listed in the role capability file, regardless of the account's underlying permissions.
Virtual account execution — the JEA session runs under a temporary virtual administrator account that is created and destroyed per session. The connecting service account never holds persistent admin privileges on the target system.
Full transcript logging — every command executed in the JEA session is recorded to a transcript file, providing a detailed audit trail of all deployment operations.
No credential exposure — the connecting account authenticates to a constrained endpoint. Even if the session is hijacked, the attacker is limited to the allowed cmdlets.

See Setting Up a Target System — Configuring Just Enough Administration (JEA) for step-by-step configuration instructions.

Authentication¶

Prefer SSH Key Authentication over Passwords¶

For Linux target systems, use SSH key-based authentication rather than password authentication. Key-based authentication is more resistant to brute-force attacks and eliminates the need to store a password in the platform.

Generate a dedicated Ed25519 or ECDSA key pair for each target system. Store the private key in the platform and install the corresponding public key on the target system.

Use WinRM over HTTPS¶

For Windows target systems, always configure WinRM over HTTPS (port 5986) rather than HTTP (port 5985). WinRM over HTTP transmits credentials and session data in plaintext and should never be used in production environments. See Setting Up a Target System for configuration steps.

Rotate Credentials Regularly¶

Rotate service account passwords and SSH keys on a regular schedule. When rotating:

Update the credential in the platform first.
Run a Test Connection to verify the new credential is working.
Deactivate the old credential on the target system.

This order prevents a gap where the platform holds an invalid credential.

Network Design¶

Ensure the Bridge Can Reach the Target System¶

The assigned Bridge must have direct network access to the target system on the required port (WinRM: 5986; SSH: 22). Verify this access before registering the target system. If the target system is in a different network segment from the Bridge, ensure the necessary firewall rules are in place.

Assign Bridges by Network Segment¶

Register target systems with the Bridge that is deployed in the same network segment. Avoid cross-segment deployments where possible — they increase network dependency and complicate firewall rules. See Bridges — Best Practices for guidance on Bridge placement.

Do Not Expose Target Systems to the Internet¶

Target systems should not be accessible from the internet. The Bridge-mediated model means the SaaS control plane never needs to reach your target systems directly. Keep target systems on private network segments and restrict access to known hosts only.

Automatic Renewal¶

Set the Renewal Threshold Based on Your Risk Tolerance¶

The renewal threshold determines how early the platform triggers a renewal order before the certificate expires. The default of 70% is appropriate for most environments, but consider adjusting it based on your operational needs:

Higher threshold (for example, 80%) — renewal is triggered earlier in the certificate's lifetime, giving more time to resolve any deployment failures before expiry. Recommended for environments with infrequent Bridge polling or complex deployment scripts.
Lower threshold (for example, 50%) — renewal is triggered later, which reduces the number of unnecessary renewals for short-lived certificates. Acceptable where deployments are reliable and fast.

Tip: For certificates with very short validity periods (30 days or fewer), set the threshold to 50% or lower to avoid triggering renewal almost immediately after each deployment.

Trigger the First Deployment Manually¶

Automatic renewal only activates after a profile has been deployed at least once — the renewal calculation depends on the recorded deployment timestamp. After creating a certificate profile, manually trigger the first deployment from the profile page. Do not rely on the automated renewal job to initiate the initial provisioning.

Monitor the Orders View¶

Review Admin → Target Systems → Orders regularly to confirm deployments are completing and renewals are running on schedule. Failed orders do not automatically retry — investigate and resolve failures promptly, then trigger a new deployment manually. A certificate that expires before renewal is deployed will cause service outages.

Deployment Validation¶

Test Connections Before Going Live¶

Always run a Test Connection after registering a new target system and after any change to credentials, hostname, or Bridge assignment. A successful test confirms the deployment path is working before a certificate is actually deployed.

Monitor Deployment History¶

Review the deployment history for each target system periodically to confirm deployments are completing successfully. Failed deployments are logged with error details — investigate and resolve failures promptly to ensure certificates are renewed before expiry.

Verify Service Restarts¶

After the first deployment to a new target system, manually verify that the service restarted successfully and is presenting the new certificate. Some environments have service restart restrictions (for example, change management policies or rolling restart requirements) that may prevent automated restarts from completing. Account for these in your on_success script or custom deployment configuration.

Operational¶

Use Descriptive Names¶

Name target systems clearly to reflect their hostname, role, and environment (for example, prod-web-01 — Nginx or exchange-au — Exchange Server). Clear naming makes deployment history and audit logs significantly easier to interpret.

Disable Before Maintenance¶

Disable a target system in the platform before performing maintenance that would temporarily interrupt SSH or WinRM access — for example, patching, firewall changes, or credential rotations. This prevents deployment failures from being logged during the maintenance window. Re-enable the system and run a connection test when maintenance is complete.