Certify is extensible via PowerShell scripts tasks which can be configured to run before or after the Certificate Request. From v5 onwards these are found under the Tasks tab for your managed certificate. See Tasks for more information.
The scripts are provided a parameter
$result which contains the status and details of the managed certificate being requested. You can execute any commands including creating new processes, or using other command line tools.
A common use for scripting is to use your new certificate for services other than IIS websites, such as Microsoft Exchange, RDP Gateway, FTP servers and other services. The app also has a range of built-in deployment tasks which also use scripting internally.
By default the background service runs as Local System, so your scripts will execute in that context, this can be important for issues regarding permissions, file system encryption etc. You can optionally configure your task to run as a specific user if network access or special permissions are required.
Do not store scripts under the C:\Program Files\CertifyTheWeb* folder. File stored there will be deleted next time you update the app
Here is a sample PowerShell script which demonstrates a few commonly accessed pieces of information:
$result.ManagedItem object is an instance of the ManagedCertificate class, so all of the properties it has will be available in your script:
Notes: Pre-request scripts/tasks are executed immediately before the Certificate Request is about to be made (including the challenge file configuration checks).
$result.IsSuccessvalue will always be
- If for some reason your script would like to prevent the Certificate Request from being executed, you may set
$trueand the site your script was executed for will be skipped.
Deployment task (post-request) scripts are executed immediately after the Certificate Request was completed, and the certificate was automatically installed and configured according to the site configuration within Certify.
By default these run if the request was successful but you can change the task trigger (On Success, On Fail, etc). You can also configure them for manual execution only, so that you can perform them during a maintenance window, or via a windows scheduled task using the command line.
$result.IsSuccessvalue indicates whether or not the Certificate Request was successfully completed.
$result.Messagevalue provides a message describing the reason for failure, or a message indicating success.
Legacy uses for scripting (v4.x and lower) may have previously included CCS Export, PEM file creation etc however these functions are provided by built-in Deployment Tasks which you should use instead unless the built-in functionality does not meet your requirements.
Note: this is an example only, by default the app will use the certifytheweb.com API to notify you of repeated failures.
This example removes any previous certificate with the same FriendlyName (
vdm) then renames the Friendly Name property of the new certificate to
vmd. It then restarts the
In the Certify UI, you may test scripts by clicking the ▶ button. You should ideally test scripts after you have completed a successful certificate request so that you have real results and a certificate to work with.
$result.ManagedItem.CertificatePathvalue will be set to the filename (including path) of the PFX file containing the requested certificate, unless the site is new and has not had a successful Certificate Request, in which case the value will not be set.
PowerShell Execution Policies may be set by your administrator which affect script execution. The app will try to set the policy to "Unrestricted" by default which may conflict with higher level policy settings. You can set the default script execution policy in the server settings file (then restart the Certify background service)
"PowershellExecutionPolicy":""(blank string) to use the default policy set by your administrator.