About Venafi Adaptable Driver PowerShell scripts
Venafi Adaptable Drivers utilize PowerShell scripts—one for each driver—that contains functions called during various stages of the certificate lifecycle; or in the case of the Adaptable Log Channel, that can be used to perform virtually any programmatic task in response to the logging of a Trust Protection Platform event.
For the Adaptable Application driver, the script can only be defined at the policy level—and is locked automatically—by selecting it from a drop-down list. After you've selected a script, it appears in a read-only field on the associated object in Trust Protection Platform.
TIP When creating new PowerShell scripts for use with adaptable drivers, keep in mind that the file name is used to identify your script from within the associated object (and within the policy for the Adaptable Application driver) in Trust Protection Platform. Using logical names can help you and other administrators recognize the purpose and intent of each script.
PowerShell scripts include functions that work with Venafi Adaptable Drivers and the certificate hosting platform.
When using the Adaptable Application or Adaptable Log Channel drivers, you can define up to 12 text fields, two yes/no (Boolean) fields, and one password credential field in your PowerShell script. Fields are defined near the top of each PowerShell script (in the Begin Field Definitions section).
As part of configuring your fields, you can specify properties for each one:
- Should the field be enabled (visible to the user)?
- Can the field's value be applied using a policy? and
- Should the field require users to enter a value?
You set each property by simply typing a zero (0) to disable or a one (1) to enable it. So, for example:
Text1|Certificate Name|110
In this case, a field would be presented to the user labeled "Certificate Name" (1=enabled) and would be policyable (1=enabled), but not mandatory (0=disabled).
Once you save your script to the correct directory on the Trust Protection Platform server, your new fields appear in the related object in Trust Protection Platform (and for the Adaptable Application, in the related policy).
EXAMPLE Here's an example of field definitions defined in a PowerShell script used with the Adaptable Application driver and how they appear in Trust Protection Platform based on property settings:
The input parameters and response format for each function is predefined. All functions receive a set of general parameters, whereas those parameters that are specific to the function are only passed to it. All of the standard provisioning functions must be present in your script, but the Remote Generation functions are optional and their absence is used to indicate a lack of support for "Generate Key/CSR on Application=Yes".
Functions are called at specific stages of the provisioning lifecycle. For more information, see PowerShell script reference for Adaptable Application.
Trust Protection Platform runs on the Windows Server operating system where PowerShell is already included. PowerShell is also an extremely flexible programming language because it can execute PowerShell cmdlets (both native and third party), .NET classes, and any binary that runs on Windows.
By using PowerShell, scripts that are to be used by the Adaptable Application driver can be developed and tested independently of Trust Protection Platform, making integration simpler.