Skip to main content

Script types

DigiCert​​®​​ Trust Lifecycle Manager supports the following script types to customize agent-based certificate lifecycle management on your servers:

Important

Use one of the following languages for your custom agent scripts, based on the host operating system:

  • Windows: bat, cmd, or PowerShell script

  • Linux: shell script (any)

If you use a different language/format to do work, use one of the above scripting languages as a wrapper to ensure compatibility.

Custom automation

Use custom automation scripts to manage certificates for custom server applications through DigiCert agents.

This type of script allows you to use your own ACME client like Certbot on your server to manage certificate lifecycles for applications not natively supported by Trust Lifecycle Manager.

You configure the custom automation script to invoke the third-party ACME client with the options needed to request and install certificates for your application.

To learn more, see Set up managed automation for custom applications.

Pre- or post-installation

Use pre- or post-installation scripts to do extra work before an automation event (pre-installation) or after the local DigiCert agent installs the certificate in an automation event (post-installation).

This type of script allows you to do any type of work needed to facilitate PKI operations on your servers, such as readiness testing, preparation, or clean up.

With pre-installation scripts, the DigiCert agent will cancel the automation event if the script does not return a success code of 0. This helps you control when a certificate is automated based on an external input.

Important

Return 0 from a pre-installation script for success, or non-zero for failure. Avoid using return codes 1, 127, or 4294770688 as they are pre-defined by the agent for other purposes.

You can use different pre- or post-installation scripts per web server application. To simplify management, Trust Lifecycle Manager allows you to assign the scripts across multiple agents in bulk.

SNI information

Trust Lifecycle Manager requires administrators to supply a list of active domains in order to discover and automate certificates on websites using Server Name Indication (SNI). You can use SNI information scripts to dynamically learn the SNI domains on your servers so you don't need to configure them manually.

For example, you might read the SNI domains directly from your web server configuration to ensure that your DigiCert agents always have the latest information.

Set up your SNI script to output the SNI information as JSON in the following format.

Example 1. JSON output format for SNI information script
[
   {
        "IP": "10.1.2.3",
        "Port": "8443",
        "Domain": "www.example.com"
    },
    {
        "IP": "10.1.2.3",
        "Port": "8443",
        "Domain": "app2.example.com"
    }
]

The following is an example SNI information script that uses the Microsoft PowerShell scripting language to read the latest SNI information from the local IIS web server. It outputs the information as JSON to use to dynamically configure the local DigiCert agent.

Example 2. SNI information script (PowerShell) for IIS web server application
$bindingInfo = get-website | select -ExpandProperty Bindings | Select -ExpandProperty Collection | where sslFlags -eq 1 | select bindingInformation

$res = @{}

foreach($ele in $bindingInfo) {
        $list = $ele.bindingInformation.split(":")
        $res[$list[2]] = @{IP=$list[0]; Port=$list[1]; Domain=$list[2]}
}

$thumbs = Get-ChildItem IIS:SSLBindings | Foreach-Object {
        [PSCustomObject]@{
                Host       = $_.Host
                Thumbprint = $_.Thumbprint
        }
}

echo($res.values | ConvertTo-Json)

To simplify management, Trust Lifecycle Manager allows you to assign SNI information scripts across multiple agents in bulk.

In this section: