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 154: 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 6: 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 alert engine 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:oo 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. Available email substitutable special text strings include:

  • {requester:mail}
    The certificate requester, based on a lookup in Active Directory of the email address associated with the requester on the certificate.

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

  • Your custom email-based metadata field, which would be specified similarly to {metadata:AppOwnerEmailAddress}.
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"
   }
]

Table 155: 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 6: 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 alert engine 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:oo 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. Available email substitutable special text strings include:

  • {requester:mail}
    The certificate requester, based on a lookup in Active Directory of the email address associated with the requester on the certificate.

  • 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.
Tip:  See the Keyfactor API Reference and Utility which provides a utility through which the Keyfactor APIClosed 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 the context of Keyfactor Command, it refers to the workflow builder, which allows you automate event-driven tasks when a certificate is requested or revoked. 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.