How certificate installs work

Issuing a certificate is only half the job. The new certificate also has to reach the server that uses it. An install closes that gap: it tells ITVA where to deliver the certificate and what to run after delivery. With auto renew and auto install both on, a certificate renews and reaches the server without anyone touching it.

Installs belong to an enrollment

You add installs on the Installs card of an enrollment. An enrollment can have more than one install, for example one for each server behind a load balancer. Each install has its own target, format, and settings.

The Install button is available only after the enrollment has a certificate. Issue the first certificate before you add installs.

When an install runs

• When you save it. Creating or editing an install delivers the latest certificate of the enrollment immediately.
• When a new certificate arrives. If Auto Install is on, the install runs each time the enrollment issues, renews, or reissues a certificate. This includes automatic renewals. Auto Install is on by default.
• When you ask for it. Select Reinstall on an install to deliver the latest certificate again.

Each run is a job with the status Pending, Running, Completed, or Failed. The enrollment history also records when each install starts, succeeds, or fails, with the error message.

Install methods

SSH

Use SSH to put the certificate on a server that ITVA manages as a device. An SSH install has three settings:

• Device: the server. It must have a primary or secondary probe.
• Path: where the probe writes the certificate file on the server.
• Script (optional): commands that run on the server after the file is written. Use {{PATH}} in the script for the value of Path. On Windows Server, the script runs in PowerShell. On other servers, it runs in the shell of the SSH account.

The script is where you copy the file into place and reload the service. If the script fails, the install job fails and shows the error from the server.

HTTP

Use HTTP to send the certificate to an API, such as a load balancer or a secrets manager. An HTTP install runs one or more saved HTTP requests, in order. In the URL, headers, or body of a request, use {{ certificate.value }} for the certificate and {{ certificate.key }} for the private key. PEM formats are sent as text. Other formats are sent as Base64.

Formats

If you turn on Include private key, you must also set a Password. ITVA uses it to encrypt the key in the file. PKCS12 does not support ML-DSA keys yet. For ML-DSA, use a PEM format.

Where the private key comes from

An install can only include the private key if ITVA has it. This depends on the key source you chose when you issued the certificate:

• ITVA Generated Private Key or Provide a Private Key: ITVA stores the key, so the install can include it.
• Generate on Device: the key never leaves the server. It stays at the Private Key Path you set. Leave Include private key off, and copy the key into place in the script.
• Provide a CSR: ITVA never sees the key. This source also cannot renew automatically, so use it only for manual renewals.

Examples: renew and install end to end

These guides show a full setup on a Linux server, with the key generated on the server and a script that puts the files in place and loads them:

• Automating SSL/TLS Certificate Renewals in Apache
• Automating SSL/TLS Certificate Renewals in NGINX
• Automating SSL/TLS Certificate Renewals in Tomcat