PUT Alerts Expiration

The PUT /Alerts/Expiration method is used to update an expiration alert. This method returns HTTP 200 OK on a success with details about the alert.

Tip:  The following permissions (see Security Roles and Claims) are required to use this feature:

/monitoring/alerts/modify/

Important:  Any previously populated fields that are not submitted with their full existing data using this method will be cleared of their existing data. When using this method, you should first do a GET to retrieve all the values for the record you want to update, enter corrected data into the field(s) you want to update, and then submit all the fields using PUT, including the fields that contain values but which you are not changing.

Table 207: PUT Alerts Expiration Input Parameters

Name

In

 Description
id Path Required. An integer indicating the Keyfactor Command reference ID of the expiration alert.
DisplayName Body Required. A string indicating the display name for the expiration alert. This name appears in the Expiration Certificate Request Alerts grid in the Management Portal.
Subject Body

Required. A string indicating the subject for the email message that will be delivered when the alert is triggered.

Tip:  Substitutable special text may be used in the subject line. Substitutable special text uses a variable in the alert definition that is replaced by data from the certificate or certificate metadata at processing time. For example, you can enter {cn} in the alert definition and each alert generated at processing time will contain the specific common name of the given certificate instead of the variable {cn}.
Message Body

Required. A string indicating the email message that will be delivered when the alert is triggered. The email message is made up of regular text and substitutable special text. If desired, you can format the message body using HTML.

For example:

Copy 
"Hello {requester:givenname}, \n\nThe certificate in the name {cn} issued on {certnotbefore} from {CAreqID} using the {template} template will expire on {certnotafter}. If this certificate is still in use, please consider getting a new one. \n\nCertificate information includes: \n\n<table> \n<tr><th>Certificate Details</th><th>Metadata</th></tr> \n<tr><td>Serial Number: {serial}</td><td>App Owner First Name: {metadata:AppOwnerFirstName}</td></tr> \n<tr><td>Thumbprint: {thumbprint}</td><td>App Owner Last Name: {metadata:AppOwnerLastName}</td></tr> \n<tr><td>SANs: {san}</td><td>App Owner Email Address: {metadata:AppOwnerEmailAddress}</td></tr> \n<tr><td>DN: {dn}</td><td>Business Critical: {metadata:BusinessCritical}</td></tr> \n</table>\n\nThanks! \n\nYour Certificate Management System"

See Table 10: Substitutable Special Text for Expiration Alerts for a complete list of available substitutable special text strings.

Note:  The $(requester:givenname) substitutable special text token is only supported in environments using Active Directory as an identity provider.
ExpirationWarningDays Body

Required. An integer indicating the number of days prior to expiration to send the warning.

Example:  When alerts run, the legacy alerting system or workflow reports on all the certificates expiring within the next X days (e.g. 30 days) from the execution time that have not previously been reported on. This means that if the alerts run daily and have been running daily regularly for some time, only a single day of expiring certificates will be reported on by any given alert run.

For example, say you create a new alert that has never run before for collection A and set it to 30 days. You configure it to run daily at 5:00 am. The alert runs for the first time at 5:00 am on July 1st. All the certificates in collection A that will expire between July 1st at 12:00 am UTC and July 31 at 12:00 am UTC will be alerted on. The next day when the alert runs again at 5:00 am on July 2nd, the certificates in collection A expiring between July 31st at 12:00 am UTC and August 1st at 12:00 am UTC will be alerted on.

If alerts are missed for a period of time (due to an outage, for example), the next run of the alerts will check the previous successful run date for the alerts and report on certificates expiring X days from that outage window. For example, using the collection A alert referenced above, say an outage caused the alerts not to run on August 1 and August 2. On August 3, the alert would run again at 5:00 am, and the certificates in collection A expiring between August 30th at 12:00 am UTC and September 2nd at 12:00 am UTC would be alerted on.
Recipients Body

An array of strings containing the recipients for the alert. Each alert can have multiple recipients. You can use specific email addresses and/or use substitutable special text to replace an email address variable with actual email addresses at processing time.

When entering email addresses on the Recipients parameter, if more than one recipient is added to a string, all recipients in that string receive the same email and can see the other recipients on the email. To do this, enter email addresses separated by commas or semi-colons withing the string. To include multiple strings, separate each string by a comma within the array. 

"Recipients": [
 "{certemail}", 
 "pkiadmins@keyexample.com,bbrown@keyexample.com"
]

Available email substitutable special text strings include:

  • {requester:mail}, {principal:mail}, {certemail} and your custom email-based metadata field, which would be specified similarly to: {metadata:AppOwnerEmailAddress}.

    Note:  The $(requester:mail) and {principal:mail} substitutable special text token is only supported in environments using Active Directory as an identity provider.
CertificateQueryId Body

Required. An integer indicating the certificate collection on which to base the alert.

Use the GET /CertificateCollections method (see GET Certificate Collections) to retrieve a list of all the certificate collections to determine the collection ID.
RegisteredEventHandler Body

An object containing the event handler configuration for the alert, if applicable. ClosedShow event handler details.

For more information about event handlers, see Using Event Handlers.
EventHandlerParameters Body

An array of objects containing the parameters configured for use by the event handler. The type of data will vary depending on the configured handler. ClosedShow event handler parameter details.

For example, for a PowerShell handler:

Copy 
"EventHandlerParameters": [
   {
      "Id": 28,
      "Key": "cn",
      "DefaultValue": "cn",
      "ParameterType": "Token"
   },
   {
      "Id": 29,
      "Key": "AppOwnerFirstName",
      "DefaultValue": "metadata:AppOwnerFirstName",
      "ParameterType": "Token"
   },
   {
      "Id": 30,
      "Key": "Text",
      "DefaultValue": "Expiration Alert: Enterprise Web Server",
      "ParameterType": "Value"
   },
   {
      "Id": 32,
      "Key": "ScriptName",
      "DefaultValue": "MyScript.ps1",
      "ParameterType": "Script"
   }
]
Use Workflows Body A Boolean indicating whether the alert uses workflows to deliver the alerts (true) or the legacy alerting system (false). The default is true.

Table 208: PUT Alerts Expiration Response Data

Name Description
Id An integer indicating the Keyfactor Command reference ID of the expiration alert.
DisplayName A string indicating the display name for the expiration alert. This name appears in the Expiration Certificate Request Alerts grid in the Management Portal.
Subject

A string indicating the subject for the email message that will be delivered when the alert is triggered.
Message

A string indicating the email message that will be delivered when the alert is triggered. The email message is made up of regular text and substitutable special text. If desired, you can format the message body using HTML.

See Table 10: Substitutable Special Text for Expiration Alerts for a complete list of available substitutable special text strings.
ExpirationWarningDays

An integer indicating the number of days prior to expiration to send the warning.

Example:  When alerts run, the legacy alerting system or workflow reports on all the certificates expiring within the next X days (e.g. 30 days) from the execution time that have not previously been reported on. This means that if the alerts run daily and have been running daily regularly for some time, only a single day of expiring certificates will be reported on by any given alert run.

For example, say you create a new alert that has never run before for collection A and set it to 30 days. You configure it to run daily at 5:00 am. The alert runs for the first time at 5:00 am on July 1st. All the certificates in collection A that will expire between July 1st at 12:00 am UTC and July 31 at 12:00 am UTC will be alerted on. The next day when the alert runs again at 5:00 am on July 2nd, the certificates in collection A expiring between July 31st at 12:00 am UTC and August 1st at 12:00 am UTC will be alerted on.

If alerts are missed for a period of time (due to an outage, for example), the next run of the alerts will check the previous successful run date for the alerts and report on certificates expiring X days from that outage window. For example, using the collection A alert referenced above, say an outage caused the alerts not to run on August 1 and August 2. On August 3, the alert would run again at 5:00 am, and the certificates in collection A expiring between August 30th at 12:00 am UTC and September 2nd at 12:00 am UTC would be alerted on.
Recipients

An array of strings containing the recipients for the alert. Each alert can have multiple recipients. You can use specific email addresses and/or use substitutable special text to replace an email address variable with actual email addresses at processing time.

When entering email addresses on the Recipients parameter, if more than one recipient is added to a string, all recipients in that string receive the same email and can see the other recipients on the email. To do this, enter email addresses separated by commas or semi-colons withing the string. To include multiple strings, separate each string by a comma within the array. 

"Recipients": [
 "{certemail}", 
 "pkiadmins@keyexample.com,bbrown@keyexample.com"
]

Available email substitutable special text strings include:

  • {requester:mail}, {principal:mail}, {certemail} and your custom email-based metadata field, which would be specified similarly to: {metadata:AppOwnerEmailAddress}.
CertificateQuery

An object indicating the certificate collection on which the alert is based. ClosedShow certificate querydetails.

For more information about certificate collections, see Saving Search Criteria as a Collection.
RegisteredEventHandler

An object containing the event handler configuration for the alert, if applicable. ClosedShow event handler details.

For more information about event handlers, see Using Event Handlers.
EventHandlerParameters

An array of objects containing the parameters configured for use by the event handler. The type of data will vary depending on the configured handler. ClosedShow event handler parameter details.
Use Workflows A Boolean indicating whether the alert uses workflows to deliver the alerts (true) or the legacy alerting system (false).
Workflow Id A string indicating the Keyfactor Command reference GUID of the workflow used to deliver alerts for this expiration alert.
Workflow Name A string indicating the name of the workflow used to deliver alerts for this expiration alert.
Workflow Published Version An integer indicating the published version of the workflow used to deliver alerts for this expiration alert.
Workflow Enabled A Boolean indicating whether the workflow used to deliver alerts for this expiration alert is enabled (true) or not (false).
Tip:  See the Keyfactor API Reference and Utility which provides a utility through which the Keyfactor APIClosed An API is a set of functions to allow creation of applications. Keyfactor offers the Keyfactor API, which allows third-party software to integrate with the advanced certificate enrollment and management features of Keyfactor Command. endpoints can be called and results returned. It is intended to be used primarily for validation, testing and workflowClosed A workflow is a series of steps necessary to complete a process. In Keyfactor Command, it refers to the workflow builder, which allows you to automate event-driven tasks such as when a certificate is requested, revoked or found in a certificate store. development. It also serves secondarily as documentation for the API. The link to the Keyfactor API Reference and Utility is in the dropdown from the help icon () at the top of the Management Portal page next to the Log Out button.