Keyfactor Command ServiceNow Application v2.0 Reference Guide

The Keyfactor Command Certificate Management ServiceNow Application will allow Keyfactor Command customers to submit PFX and CSR enrollment requests, renewals, and revocation requests. Once submitted, the request goes through an approval process. If the request is approved, the user can download the certificate from the ServiceNow Service Portal. This means that requesters and approvers can perform certificate management activities without logging in to the Command instance, saving time and effort for complete lifecycle management of certificates.

Certificate requests and certificates are linked to applications that are defined in the ServiceNow Portal. Depending on role assignment, users can request certificates to be issued or revoked from ServiceNow, creating a ServiceNow ticket to get approval from the application owner. If approved, the certificate is then issued or revoked via the Keyfactor Command API (authenticated via OAuth with a service account) and a notification is sent to the requester. Users will be restricted to requesting and downloading certificates that belong to applications they have permission to manage.

Additionally, there is an ability to see certificates that are coming up for expiration. There are two options for alerting on upcoming expirations.

1. When Command discovers a certificate that is coming up for expiration, an expiration alert with a workflow can be configured to trigger an incident in ServiceNow that will alert the application owner.
2. If the certificates are in ServiceNow, a ServiceNow workflow can be used to trigger the expiration alerts, independently of a Command workflow.

Note that all interactions between the application and Command occur in the context of the service account used to connect to the Keyfactor API and not in the context of the user who is logged in to ServiceNow.

The ServiceNow Marketplace Offering is provided free of charge and does not fall under or receive support under the Keyfactor support policy. Email support is provided via the documented methods as a Keyfactor customer. For more information, refer to the Support Rules of Engagement for ServiceNow Keyfactor Command Certificate Management Application.

Release notes

• Removed support for Command 12.5 and 25.1
• Added the ability to select an Applications table
• Made FQDN requirement configurable to turn off/on
• Added ServiceNow Email Notification option for certificate expiration
• Moved certificate download to the Service Portal
• Fixed an issue with the naming of the downloaded certificates
• Fixed an issue where the certificate dropdown list was not populating based on the selected application
• Moved Key Algorithms and Key Size from the sys_choice table to the x_keyfa_app_keyfactor_key_size_algorithms table

Upgrade notes

Please see Appendices D and E for upgrade instructions.

Known issues

• The application only pulls in the system-wide metadata fields. This will be fixed in a future version.
• The certificates table does not import the serial number. This will be fixed in a future version.
• The certificate renewal presents the thumbprint in an editable field. This will be fixed in a future version.

Application table

In version 1.0, there was a custom application table (x_keyfa_app_applications) to store application owners, approvers, and FQDN.

In version 2.0, we have added the option to use an application table from CMDB. You can set this in the Keyfactor Command Application Properties. When you select a different table, you can create a reference to the Application table in the Application column of the x_keyfa_app_applications table.

The application will then pull the application owner, approver, etc. fields from the table selected by specifying the field names from the Application table to use for application owner, approver, etc. on the Keyfactor Command Application Properties page. You can put multiple column names in these fields to use multiple approvers.

For more information, refer to Appendix C: How the application records work with CMDB.

If you choose to use your own application table the expiration workflow code shared in version one to look up the application owner email in order to send an expiration email will not work. Instead, please refer to Appendix B: Configure expiration alerts with a custom CMDB table.

FQDN

The FQDN requirement can be turned on or off on the Keyfactor Command Application Properties page with the Validate FQDN field checked (for true) or unchecked (for false). This will turn on or off the validation on the certificate request forms to restrict the Common Name and SANs to matching the FQDNs specified on the Application table.

System requirements

• Keyfactor Command 25.2 or higher configured with OAuth authentication
• ServiceNow Yokohama, Zurich, or Australia
  • Flow Designer plugin
  • Integration Hub (with Starter Pack)
• ServiceNow Enterprise license
• Hosted customers that have IP Whitelisting for their Command instance will need to find their ServiceNow IP address and open a Support ticket to get their IP added
  • Required OAuth information:
    • Client ID
    • Client Secret
    • Token URL
    • Note: If you are using Okta as your IdP and get this error (invalid_scope) when trying to generate a token that means that your authorization server does not have a default scope set. You will need to go to your authorization server in Okta, go to the scopes tab, edit the scope used for the client_credentials grant type, and check the 'Set as default' box and save.
• Root of Trust Certificate in .CRT format if not publicly issued/trusted

Installation

The Command ServiceNow application can be downloaded from the ServiceNow marketplace by a ServiceNow admin. Search for Keyfactor Command Certificate Management. It is a free application. Once you have located it, select Get and follow the instructions. The application will require approval from Keyfactor before installation.

There are videos on the listing that can show you a demo and guide you through the installation.

Application configuration

The application requires a few configuration steps to be performed by the ServiceNow admin and the Command admin before it can be used.

Step 1: Command configuration

The ServiceNow application relies on OAuth authentication to communicate with the Command API.

When setting up the application to run in ServiceNow, PKIaaS and CLAaaS customers should contact Keyfactor Support to get a service account created to allow for REST API access as well as exposing the CAs and Templates that you want to use in ServiceNow. Note that all enrollment, renewal, and revocation actions from ServiceNow take place under the context of this service account.

On-premise customers can create a claim in their OAuth Identity Provider and add it to the Command Portal via the Gear icon > Security Roles and Claims. In addition, they should request whitelisting of their ServiceNow IP address.

Work with your Identity Access Management (IAM) Team to obtain the OAuth Client ID/Secret and Token URL from the Identity Provider that Keyfactor Command is using for Authentication/Authorization using OAuth.

If you plan to use the same Client ID, which is integrated with Keyfactor Command, you can pull the Client ID and Token URL from Keyfactor Command by performing the following steps:

1. Click the Gear icon, then select Identity Providers.
2. Double-click the Identity Provider, such as Command, then select the Parameters tab to pull the necessary information. You will still need to work with your IAM team to obtain the Client Secret, but this may help the IAM Team identify the integrated client.  

NOTE: If you plan to create a new client for the integration, ensure the corresponding claim is added to the respective tabs in the Security Roles and Claims section in Keyfactor Command via the Gear icon.

For Identity Providers that require a scope to generate a token using the Client Credentials grant type follow the below steps.

Scroll down to the bottom section:

Select OAuth Entity Scopes and double click the “Insert a new row” to enter a Name. Double click under OAuth scope and enter a value for the scope required for the client credentials grant type.

Then, create a Claim and assign it the following permissions.

Global permissions

• Certificate Templates
  • Read
• Certificates
  • Requests Manage
  • Enrollment
    • Csr
    • Pfx
  • Collections
    • Download Private Key (Private Key Import and Private Key Read)
    • Read
    • Revoke
• Enrollment Pattern 
  • Read
• Metadata – Types
  • Read

Assign the Claim you created for this role.

The security role also needs to be added as an Allowed Requester on the Enrollment Patterns and the Enrollment Pattern needs to be the Default Pattern for Template. Failure to do this will lead to the templates not being populated in the ServiceNow Enrollment forms since the application uses an API command to get only the templates the security role has permissions to request.

Step 2: Obtain Keyfactor API endpoint

During the configuration, you will need to know the KeyfactorAPI endpoint. This will be unique to your Command installation. The Keyfactor Command administrator should provide this to the ServiceNow administrator in advance of configuring the application.

To find the Keyfactor API endpoint:

1. In Keyfactor Command, click the Question Mark icon and select Keyfactor API Endpoint Utility (aka: Swagger Interface).
2. Based on the URL, obtain the Keyfactor Website API, which is reflected after the FQDN, such as KeyfactorAPI.
   
   

ServiceNow configuration

Step 1: Follow the setup instructions

In the ServiceNow Portal, navigate to All > Keyfactor Command > Setup Instructions. Then select the green Get Started button.

The setup instructions will guide you through the steps described below via the green Get Started buttons in the task list.

Step 2: Update Application Registry

Service Now will use the OAuth information provided to generate a Bearer Token for authentication against the Keyfactor Command APIs. You will need the Client ID, Client Secret, Token Endpoint, and if your IdP requires it, a scope.

In this step, the Application Registry Record named Keyfactor Command is installed.

1. Navigate to All > System OAuth > Application Registry.
2. Open record with name “Keyfactor Command”.
3. On the form, fill in the following fields.

Field	Description	Values
Name	A unique name that identifies the application	Ex: Keyfactor Command
Client ID	Client ID of application registered in third-party OAuth server.	Ex: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Client Secret	Client secret of application registered in third-party OAuth server.	Ex: tqeWfjGrQeDxxxxxxxxxxxxxxZ4qS9z4r6LN0L0xxxxxxxT_Rk5DHTU6DyFY
Redirect URL	OAuth callback endpoint. Leave it empty for auto-generation.	https://xxxxxxx.service-now.com/oauth_redirect.do
Token URL	OAuth Server's token endpoint.	https://kftest2.us.auth0.com/oauth/token This value depends on architecture of Keyfactor Command for each customer and can be validated by looking at how Keyfactor Command’s authentication is configured.
Accessible from	This registry should be accessible from Keyfactor Command ServiceNow Application scope.	All Application Scopes
Active		true
Refresh Token Lifespan	Time in seconds the Refresh Token will be valid.	Ex: 864,000,000
Send Credentials	OAuth Client will populate client credentials in the request as per the choice selected	In Request Body (Form URL-Encoded)

For Identity Providers that require a scope to generate a token using the Client Credentials grant type, complete the following steps.

1. Scroll to the bottom section.
   
   
2. Select OAuth Entity Scopes, and then double-click Insert a new row to enter a Name.
3. Double-click under OAuth scope to enter a value for the scope required for the client credentials grant type.

Step 3: Validate OAuth Entity is present

In this step, the OAuth Entity named Keyfactor Command - OAuth Entity Profile is installed.

1. Navigate to All > System OAuth > Application Registry.
2. Open the record named Keyfactor Command.



3. Scroll down to “OAuth Entity Profiles” and validate that the OAuth Entity Profile named “Keyfactor Command - OAuth Entity Profile” is present.



4. Cross-validate the record. No changes required here.

Step 4: Check OAuth 2.0 credentials

In this step, the credential named Integration Keyfactor - Oauth2.0 is installed.

1. Navigate to All > Connections & Credentials > Connections.
2. Open Integration Keyfactor.

3. Update the Connection URL field with the Keyfactor Command instance URL, as shown below.
   
   For example: https://appname.eastus2.cloudapp.azure.com/This value will be based on your Command configuration. It is the part of the URL you use to access the Command portal minus the “KeyfactorPortal”.
   

4. Navigate to All > Connections & Credentials > Credentials, Open “Integration Keyfactor - Oauth2.0”.
   
   
5. Please test the above configuration by clicking on “Get OAuth Token”.
6. Please validate if you are getting the “OAuth token flow completed successfully” message after clicking on “Get OAuth Token”.

Step 5: Populate key algorithms and sizes

Please follow Appendix E: Populating the x_keyfa_app_keyfactor_key_size_algorithms values to populate the key sizes and algorithms table. In a future version, these will be pulled from the Enrollment Patterns defined in Command.

Configure Keyfactor Command integration properties

Step 1: Configure logging properties

From All > Keyfactor Command > Administration > Properties, you can configure the following areas.

Logging properties

Step 2: Populate Application table and data

The Keyfactor Command ServiceNow Application requires Enterprise applications to be imported or created in ServiceNow so application owners can enroll/renew/revoke certificates directly from ServiceNow using the catalogs provided in this application.

There are two ways a ServiceNow system administrator can configure the applications table that is used.

• Use the custom table the application ships with (x_keyfa_app_applications)
• Specify a different CMDB table (supported starting with version 2.0 of the application)

If you are upgrading, you can continue to use the x_keyfa_app_applications table or migrate to using a different CMDB table. Refer to Appendix D: Migrate from a custom Applications table to a CMDB Applications table for more information.

In version 2.0, there is the option to configure the use of a different CMDB table.

To configure this:

1. Go to Keyfactor Command Integration Properties.
2. Find the Keyfactor Command Application Properties section in the Keyfactor Command Certificate Management application scope.
3. Change the value in the Add the cmdb_ci class used for the application linking. Leave empty if custom application flow is used area to the name of the table you would like to use (for example, cmdb_ci_application_software).

Step 3: Retrieve metadata attributes

The Keyfactor Command ServiceNow Application provides functionality to populate metadata attributes when enrolling in a PFX or CSR certificate. These metadata attributes are dynamically populated based on the Template selected on catalog form.

Upon installation of the application or whenever there is a new metadata attribute created in the Keyfactor Command application, the ServiceNow system administrator must perform the following steps.

The attribute counts and names used in this procedure are just for reference. These vary based on configurations in your Keyfactor Command instance.

1. Retrieve Metadata attributes for Command PFX Request Catalog.
2. Modify the Certificate Template field by selecting each allowed value that will trigger the Keyfactor Command API to retrieve metadata attributes tied to the templates.
   
3. After a few seconds, reload the page to see the newly created service catalog variables for Metadata attributes.
   
4. The system-wide metadata will be retrieved.

In a future version, the metadata will reflect the configuration on the Enrollment Pattern.

Keyfactor Command Expiration Flow

Please refer to Appendix A: Configure the Command Expiration Workflow with the x_keyfa_app_applications table for creation of expiration workflow in Command if you are using the x_keyfa_app_applications Applications table.

Note: If you are using your own Applications table, the REST API step to look up the application owner email will need to be adjusted. This will need to be done with the assistance of your ServiceNow admin as this is a ServiceNow API call and outside the scope of what Keyfactor can support.

ServiceNow Expiration Flow

Another option for an Expiration notification is to use the ServiceNow flow. The alert is in System Notification>Email>Notifications>Certificate Expiration Alert.

There are two properties defined in the Keyfactor Command Application-->Properties that are used for this:

• A list of number of days (comma-delimited) to send alerts for certificates that are expiring.
• Email address to send alerts for certificates that are expiring if application owners do not have an email address.

Import certificate data from Command

Certificate data for active certificates can be imported from Command to allow users to select a certificate for renewal.

1. Go to Administration > Scheduled Script Executions in the Native Portal while logged in as a ServiceNow administrator.
2. Select Keyfactor Certificate Import. Validate that the Active checkbox is selected.
3. Select Execute Now.
4. Certificate records will be populated in the Certificates table and are ready to be assigned to applications.
5. Once assigned to an application, the certificates will appear in the Certificates and Renewal views for Application Owners.

User roles

There are four types of users that interact with this application.

• Application Owner/Requester: A ServiceNow user owning an Enterprise application that uses certificates. A given user could own multiple applications. Application Owners can submit catalog requests for CSR, PFX enrollments and renewal, and revocation from ServiceNow Service Portal.
• Application Approver: Each configured application has a specific ServiceNow user who is responsible for approving enrollment requests related to the application. The Application Approver approves the requests in ServiceNow. Application approvers belong to an Approval Group associated with the Application in ServiceNow.
• Keyfactor Command Administrator: The Keyfactor Administrator is the person responsible for managing the configuration of Command for integrating with ServiceNow. This includes service account creation, template and enrollment pattern configuration, and any workflows.
• ServiceNow Administrator: The ServiceNow Administrator is the person responsible for managing the ServiceNow specific aspects of the application, like installing the application and configuring OAuth to connect to Command. The ServiceNow Administrator is also responsible for making a record of any customizations made to the application, as those will be overwritten during an upgrade.

Create ServiceNow users

1. Log in to the ServiceNow Service Native Portal.
2. In the All menu, locate Users.
3. Navigate to System Security > Users and Groups > Users.
4. Enter information about the user.
5. Scroll to the grid and select Roles.
6. Add permissions for the user according to the following list (per user).
   • Application Owner
     • Itil
     • x_keyfa_app.application_owner
   • Application Approver
     • Itil
   • Keyfactor Administrator
     • Admin
     • x_keyfa_app.admin

Create ServiceNow Approval Group

1. In the All menu, locate Groups.
2. Select System Security > Users and Groups > Groups.
3. Click New.
4. Enter a name and other group details.
5. Click Submit.
6. Search for the group.
7. Select Group Members.
8. Add your Application Approver user.

Create an application

There are two processes for creating an application.

• x_keyfa_app_applications table: Use this process if you have chosen to use the custom applications table that is shipped with the product.
• cmdb_ci class: Use this process if you have chosen to use a CMDB table for the applications data.

x_keyfa_app_applications table

Use this process if you have chosen to use the custom applications table that is shipped with the product.

1. Log in to the ServiceNow Service Portal as a user in the role specified in List of roles allowed to create new application on the Keyfactor Command > Properties page, as described in the “Populate Application Data” section of the setup instructions.
2. Select Keyfactor > Applications.
   
3. Select Create New.
   
4. Enter a name.
5. Select the Application Owner/Requester as the Application Owner. This is the user who will create requests to enroll or revoke certificates.
6. In Approval group, select the Approval Group you created earlier.
7. Enter the FQDN that will be on the certificate subject if you have selected to validate the FQDN on the Keyfactor Command > Properties page, as described in the “Populate Application Data” section of the setup instructions. (Multiple FQDNs can be added as comma-separated values.)

cmdb_ci class

Use this process if you have chosen to use a CMDB table for the applications data.

1. Log in to the ServiceNow Service Portal as a user in the role specified in List of roles allowed to create new application on the Keyfactor Command > Properties page, as described in the "Populate Application Data” section of the setup instructions.
2. Select Keyfactor > Applications.
   
3. Select Create New.
   
4. Select an Application from the dropdown list.
   
5. If you have configured the application to check for FQDNs during certificate requests, enter a comma-separated list of FQDNs.

Configure emails for notifications

The application creates incidents and sends email notifications via Flows in the Flow Designer.

1. Within the flow, navigate to the Send Notification action, then click on Notification to open the pop up to navigate to the notification message.
   
2. Click the Information icon to open the pop up.
   

3. Then select Open Record and navigate to What it will contain to modify the message.

   Any modifications may be overwritten during an upgrade, so make a note of them in case that happens.
   

Using the Command ServiceNow application

To view all the catalog items available, browse to Catalog > Browse Category > Software > Show more items or you can search for "Command". Once you have used the items, they will be available from the Keyfactor > Catalog menu.

Request a PFX certificate

1. Log in to the ServiceNow Service Portal as the Application Owner/Requester.
2. Select Keyfactor Command > Catalog.
   
3. Select Command PFX Request.
   
4. Enter the Request Type.
   • Choose New to create a new certificate.
   • Choose Renewal to renew an existing certificate.
5. Select the Application.
6. Enter the certificate details, ensuring that the Common Name matches one of the FQDNs that were put on the Application.
   • For a New request, this will mean entering the certificate details.
   • For a Renewal request, this will mean selecting the certificate to be renewed.
7. Select the Key Algorithm and Key Size.
8. Enter the SANs and any other data.
9. Click Request. This will create an incident and send an email to the approver to review and approve or deny the request.
10. You will receive an email when the request is approved or denied.

Request a CSR certificate

To use a CSR generated in the Command Portal, you must disable the Application Setting Enable warning for CSR generated in Command.

1. Log in to the ServiceNow Service Portal as the Application Owner/Requester.
2. Select .Keyfactor Command > Catalog.
   
3. Select Command CSR Request.
   
4. Select the Application.
5. Select the Certificate Template and Certificate Authority.
6. Paste in your CSR.
7. Enter any other data.
8. Click Request. This will create an incident and send an email to the approver to review and approve or deny the request.
9. You will receive an email when the request is approved or denied.

Request a certificate revocation

1. Log in to the ServiceNow Service Portal as the Application Owner/Requester.
2. Select Keyfactor Command > Catalog.
   
3. Select Command Certificate Revocation.
   
4. Select the Application.
5. Select the Certificate.
6. Select the Revocation Reason.
7. Enter any Comments about why the certificate needs to be revoked.
8. Click Request. This will create an incident and send an email to the approver to review and approve or deny the request.
9. You will receive an email when the request is approved or denied.

Approve a Request

1. Log in to the ServiceNow Service Portal as the Application Approver.
2. Select Approvals.
   
3. Click the Request to view the details.
4. Choose to Approve or Reject the request.

Download a certificate

Certificates can be downloaded as PEM or, if the private key is available, PFX/P12 files.

Depending on the user role, there are a few places certificates can be downloaded from.

1. Go to Keyfactor Command > Certificates.

   

2. Find the certificate in the grid that you want to download.

3. Select Download Cert (PEM) or Download Cert (PFX).
   If the certificate was requested via CSR, Command may not know the private key and therefore the Download Cert (PFX) option may not be visible.
   

    

4. Confirm you want to download the certificate.
   
5. When the file is ready for download, you will see a banner similar to this:
   
   Be sure to copy the password if you are downloading a PFX and select Click here to download the certificate.
6. When you are done downloading, you can use the Back to List button at the bottom of the page.

Certificates are not stored in ServiceNow. When a download is requested, an API call is made to the Command API to get the certificate. In this way, there is no need to have the private key stored in ServiceNow.

Obtain a list of expiring certificates

To get to a list of expiring certificates go to Keyfactor Command > Expiring Certificates.

Expiring certificates are reported to ServiceNow via an Expiration Workflow in Command.

Depending on how your administrator configures the workflow, you may receive notifications from Command as well as ServiceNow. It is also possible that your administrator could configure the workflow to automatically renew the certificate for you. Check with your administrator for details.

Appendix A: Configure the Command Expiration Workflow with the x_keyfa_app_applications table

This workflow will create a ticket in ServiceNow when a certificate is coming up for expiration. This applies only if you have configured the application to use the default x_keyfa_app_applications table. 

Note: There is also a sample workflow on the store listing that includes a look up of the Application Owner Email. If you are using your own Applications table and want to use the Command workflow, the REST API step to look up the application owner email will need to be adjusted. This will need to be done with the assistance of your ServiceNow admin as this is a ServiceNow API call and outside the scope of what Keyfactor can support.

In Command, do the following to create the expiration workflow:

• Create a collection of certificates.
• Create an Expiration Alert based off that collection and choose “Use Workflows”.
• Create a Workflow of type “Expiration”. You can use the code below to create a JSON file to import into the workflow definitions in Command to start with a sample workflow.

{
  "Id": "24f2c475-01c5-4aaa-bd8f-1ab87c3ef73e",
  "DisplayName": "ServiceNow Expiration Workflow",
  "Description": "The workflow creates an incident in ServiceNow.",
  "Key": "10",
  "KeyDisplayName": "ServiceNow Expiration Workflow",
  "IsPublished": false,
  "WorkflowType": "Expiration",
  "Steps": [
    {
      "Id": "b4a9ca87-3298-4d3b-baea-4ec1e628e006",
      "DisplayName": "Start-NOOP",
      "UniqueName": "StartNOOP",
      "ExtensionName": "NOOPStep",
      "Enabled": true,
      "ConfigurationParameters": {},
      "Signals": [],
      "Conditions": [],
      "Outputs": {
        "continue": "OAuthRESTRequest1"
      }
    },
    {
      "Id": "6b4720f2-ed69-4865-8fee-8498a200704b",
      "DisplayName": "Get certificate data OAuth",
      "UniqueName": "OAuthRESTRequest1",
      "ExtensionName": "OAuthRESTRequest",
      "Enabled": true,
      "ConfigurationParameters": {
        "Headers": {
          "x-keyfactor-requested-with": [
            "APIClient"
          ],
          "x-keyfactor-api-version": [
            "1"
          ],
          "grant_type": [
            "client_credentials"
          ]
        },
        "DataBucketProperty": "APIResponse",
        "Verb": "GET",
        "client_id": "<your Command Client ID>",
        "client_secret": null,
        "TokenEndpoint": "https://<your Oauth>.us.auth0.com/oauth/token",
        "scope": "",
        "audience": "https://<your Command URL>/KeyfactorAPI",
        "URL": "https://<your Command URL>/KeyfactorAPI/Certificates/$(certid)?includeLocations=true&includeMetadata=true&collectionId=0&verbose=2",
        "ContentType": "application/json",
        "RequestContent": ""
      },
      "Signals": [],
      "Conditions": [],
      "Outputs": {
        "continue": "ParseResponseData"
      }
    },
    {
      "Id": "4db06c64-c896-425f-af20-a8608609aa27",
      "DisplayName": "Send Request to ServiceNow via REST",
      "UniqueName": "RESTRequest2",
      "ExtensionName": "RESTRequest",
      "Enabled": true,
      "ConfigurationParameters": {
        "Headers": {
          "Accept": [
            "application/json"
          ]
        },
        "DataBucketProperty": "SNOWAPIResponse",
        "Verb": "POST",
        "UseBasicAuth": true,
        "BasicUsername": null,
        "BasicPassword": null,
        "URL": "https://<your ServiceNow instance>.service-now.com/api/now/import/x_keyfa_app_expirartion_alert/insertMultiple",
        "ContentType": "application/json",
        "RequestContent": "{   \n\"records\":[\n      {\n         \"certId\" : \"$(certid)\",\n         \"CN\":\"$(ObjectResponseCN)\",\n         \"IssuedDN\" : \"$(ObjectResponseDN)\",\n         \"ExpirationDate\" : $(ObjectResponseExpirationDate),\n         \"Thumbprint\" : \"$(ObjectResponseThumbprint)\",\n          \"SerialNumber\" : \"$(ObjectResponseSerialNumber)\",\n          \"SAN\" : \"$(ObjectResponseSubjectAltNameElements)\"\n      }\n   ]\n}\n"
      },
      "Signals": [],
      "Conditions": [],
      "Outputs": {
        "continue": "EndNOOP"
      }
    },
    {
      "Id": "907c8f4b-faff-472e-be08-c704892582af",
      "DisplayName": "Parse Response Data",
      "UniqueName": "ParseResponseData",
      "ExtensionName": "PowerShell",
      "Enabled": true,
      "ConfigurationParameters": {
        "ScriptParameters": {
          "APIResponse": "$(APIResponse)"
        },
        "ScriptContent": "param(\n[string]$APIResponse\n)\n \n$ObjectResponse = ConvertFrom-Json -InputObject $APIResponse\n \n$ObjectResponseCN = $ObjectResponse[0].IssuedCN\n\n$ObjectResponseDN = $ObjectResponse[0].IssuedDN\n\n$ObjectResponseThumbprint = $ObjectResponse[0].Thumbprint\n\n$ObjectResponseSerialNumber = $ObjectResponse[0].SerialNumber\n\n$ObjectResponseExpirationDate = $ObjectResponse[0].NotAfter\n\n$ObjectResponseSubjectAltNameElements = $ObjectResponse.SubjectAltNameElements[0].Value\n\n$SANCount = $ObjectResponse.SubjectAltNameElements.Count\n\nfor ($i = 0; $i -lt $SANCount; $i++) \n    {\n        if ($i -eq 0)\n        {\n            $SANs += $ObjectResponse.SubjectAltNameElements[$i].Value\n        }\n        else\n        {\n            $SANs += \";\" + $ObjectResponse.SubjectAltNameElements[$i].Value\n        }\n    }\n \n$result = @{ \"ObjectResponseCN\" = $ObjectResponseCN; \"ObjectResponseDN\" = $ObjectResponseDN; \"ObjectResponseThumbprint\" = $ObjectResponseThumbprint; \"ObjectResponseSerialNumber\" = $ObjectResponseSerialNumber; \"ObjectResponseExpirationDate\" = $ObjectResponseExpirationDate; \"ObjectResponseSubjectAltNameElements\" = $SANs}\nreturn $result"
      },
      "Signals": [],
      "Conditions": [],
      "Outputs": {
        "continue": "RESTRequest2"
      }
    },
    {
      "Id": "927f1326-df8f-458f-b3b3-dc26e0e701f7",
      "DisplayName": "End-NOOP",
      "UniqueName": "EndNOOP",
      "ExtensionName": "NOOPStep",
      "Enabled": true,
      "ConfigurationParameters": {},
      "Signals": [],
      "Conditions": [],
      "Outputs": {}
    }
  ],
  "DraftVersion": 4,
  "PublishedVersion": 3,
  "Enabled": true
}

Appendix B: Configure expiration alerts with a custom CMDB table

If you are using a CMDB table, expiration alerts can be configured from ServiceNow instead of Command.

The Scheduled Job can be configured at https://<your ServiceNow instance>/sysauto_script.do?sys_id=212ba201ff54c710aef9f7677c4fd960&sysparm_record_target=sysauto.

By default, it runs at 1:00 AM every day.

The job uses two values set in the System Properties (see Step 2: Populate Application table and data) to get a list of comma-delimited days before expiration intervals when the alerts will be sent and a fail-safe email address to send alerts to if the Application record does not have an Application Owner email.

The email can be configured at System Notification>Email>Notifications>Certificate Expiration Alert or more directly by the URL below (replacing with your ServiceNow instance):

https://<your ServiceNow instance>/now/nav/ui/classic/params/target/sysevent_email_action.do%3Fsys_id%3Defeee2c5ff54c710aef9f7677c4fd978%26sysparm_view%3Dadvanced%26sysparm_record_target%3Dsysevent_email_action%26sysparm_view_forced%3Dtrue

The content of the notification can be changed under the tab What will contain - Message HTML (editor HTML).

Appendix C: How the application records work with CMDB

In the Keyfactor Command ServiceNow integration, if you select option to use an application table from CMDB when configuring the application, application data is managed using a reference‑based model that works alongside your existing CMDB. The CMDB remains the authoritative source for application information—such as application owners, technical contacts, and other core attributes. The Keyfactor integration introduces a separate Keyfactor application table that references CMDB application records rather than duplicating them. This ensures that application details stay consistent and up to date while allowing Keyfactor‑specific certificate workflows to operate independently of CMDB maintenance activities. The underlying enrollment forms reference the x_keyfa_app_applications table to populate the application dropdown, but the approvals and flows reference the CMDB table for owner and approver information.

An application appears in the Keyfactor application table only when it is intentionally enabled for certificate‑related processes. Creating this record indicates that the application participates in certificate requests, approvals, and metadata handling through Keyfactor Command. Any changes made to the underlying CMDB application record—such as updates to owners or related attributes—continue to be managed in the CMDB and are reflected automatically wherever that information is referenced by the integration. The Keyfactor application record does not modify or override CMDB data; it simply links to it.

This design provides both control and flexibility. Organizations can decide exactly which applications should be enabled for certificate lifecycle management without impacting their broader CMDB structure. Removing or modifying a record in the Keyfactor application table affects only certificate workflows and does not change the CMDB itself.

Follow the instructions in “Create an Application” abnove to get the record that references your CMDB table into the x_keyfa_app_applications table.

For environments with a large number of applications, records can be created in bulk using a Fix Script, making it easy to onboard applications while preserving a clean separation between CMDB ownership and certificate management configuration. After configuring your application table information as described in Configure Keyfactor Command integration properties go to System Definition > Fix Scripts > Load Keyfactor Apps and run the script.

Expiration Alert from Command

Note that if you are using the Command expiration alert workflow, the REST API step to get the certificate owner will need to be updated to reflect your instance's application table. Your ServiceNow Admin should be able to help you with this.

There is also the option to rely on the expiration alerts in ServiceNow outside of Command instead of using the Workflow. Please see ServiceNow Expiration Flow above.

Appendix D: Migrate from a custom Applications table to a CMDB Applications table

To migrate your existing Application data to use the CMDB Application table, a reference to the CMDB Application table needs to be added to the custom table (x_keyfa_app_applications).

Navigate to Keyfactor Command > Tables > Applications. Then update the empty Application field with the related CMDB table application record.

For environments with a large number of applications, records can be created in bulk using a Fix Script, making it easy to onboard applications while preserving a clean separation between CMDB ownership and certificate management configuration. After configuring your application table information as described in Configure Keyfactor Command integration properties go to System Definition > Fix Scripts > Load Keyfactor Apps and run the script.

Appendix E: Populating the x_keyfa_app_keyfactor_key_size_algorithms values

When using version 2 of the application, the Key Size and Algorithm values need to be populated in the x_keyfa_app_keyfactor_key_size_algorithms table.

These values can be input manually or imported from the XML file below.

XML file for import

<?xml version="1.0" encoding="UTF-8"?>
<unload unload_date="2026-05-07 15:49:53">
<x_keyfa_app_keyfactor_key_size_algorithms action="INSERT_OR_UPDATE">
<key_algorithm>ECC</key_algorithm>
<key_size>384</key_size>
<sys_created_by>system</sys_created_by>
<sys_created_on>2026-05-07 15:06:38</sys_created_on>
<sys_id>2596089cffbc8bd0aef9f7677c4fd950</sys_id>
<sys_mod_count>0</sys_mod_count>
<sys_updated_by>system</sys_updated_by>
<sys_updated_on>2026-05-07 15:06:38</sys_updated_on>
</x_keyfa_app_keyfactor_key_size_algorithms>
<x_keyfa_app_keyfactor_key_size_algorithms action="INSERT_OR_UPDATE">
<key_algorithm>ECC</key_algorithm>
<key_size>521</key_size>
<sys_created_by>system</sys_created_by>
<sys_created_on>2026-05-07 15:06:48</sys_created_on>
<sys_id>b79608dcffbc8bd0aef9f7677c4fd9a1</sys_id>
<sys_mod_count>0</sys_mod_count>
<sys_updated_by>system</sys_updated_by>
<sys_updated_on>2026-05-07 15:06:48</sys_updated_on>
</x_keyfa_app_keyfactor_key_size_algorithms>
<x_keyfa_app_keyfactor_key_size_algorithms action="INSERT_OR_UPDATE">
<key_algorithm>ECC</key_algorithm>
<key_size>160</key_size>
<sys_created_by>system</sys_created_by>
<sys_created_on>2026-05-07 15:05:53</sys_created_on>
<sys_id>a66680dcffbc8bd0aef9f7677c4fd9ba</sys_id>
<sys_mod_count>0</sys_mod_count>
<sys_updated_by>system</sys_updated_by>
<sys_updated_on>2026-05-07 15:05:53</sys_updated_on>
</x_keyfa_app_keyfactor_key_size_algorithms>
<x_keyfa_app_keyfactor_key_size_algorithms action="INSERT_OR_UPDATE">
<key_algorithm>ECC</key_algorithm>
<key_size>224</key_size>
<sys_created_by>system</sys_created_by>
<sys_created_on>2026-05-07 15:06:19</sys_created_on>
<sys_id>748680dcffbc8bd0aef9f7677c4fd9c4</sys_id>
<sys_mod_count>0</sys_mod_count>
<sys_updated_by>system</sys_updated_by>
<sys_updated_on>2026-05-07 15:06:19</sys_updated_on>
</x_keyfa_app_keyfactor_key_size_algorithms>
<x_keyfa_app_keyfactor_key_size_algorithms action="INSERT_OR_UPDATE">
<key_algorithm>ECC</key_algorithm>
<key_size>256</key_size>
<sys_created_by>system</sys_created_by>
<sys_created_on>2026-05-07 15:06:29</sys_created_on>
<sys_id>538644dcffbc8bd0aef9f7677c4fd9ba</sys_id>
<sys_mod_count>0</sys_mod_count>
<sys_updated_by>system</sys_updated_by>
<sys_updated_on>2026-05-07 15:06:29</sys_updated_on>
</x_keyfa_app_keyfactor_key_size_algorithms>
<x_keyfa_app_keyfactor_key_size_algorithms action="INSERT_OR_UPDATE">
<key_algorithm>RSA</key_algorithm>
<key_size>3072</key_size>
<sys_created_by>system</sys_created_by>
<sys_created_on>2026-05-07 14:52:33</sys_created_on>
<sys_id>5b53c058ffbc8bd0aef9f7677c4fd9e3</sys_id>
<sys_mod_count>1</sys_mod_count>
<sys_updated_by>system</sys_updated_by>
<sys_updated_on>2026-05-07 15:05:06</sys_updated_on>
</x_keyfa_app_keyfactor_key_size_algorithms>
<x_keyfa_app_keyfactor_key_size_algorithms action="INSERT_OR_UPDATE">
<key_algorithm>RSA</key_algorithm>
<key_size>4096</key_size>
<sys_created_by>system</sys_created_by>
<sys_created_on>2026-05-07 14:52:41</sys_created_on>
<sys_id>c163c058ffbc8bd0aef9f7677c4fd9ef</sys_id>
<sys_mod_count>1</sys_mod_count>
<sys_updated_by>system</sys_updated_by>
<sys_updated_on>2026-05-07 15:05:11</sys_updated_on>
</x_keyfa_app_keyfactor_key_size_algorithms>
<x_keyfa_app_keyfactor_key_size_algorithms action="INSERT_OR_UPDATE">
<key_algorithm>RSA</key_algorithm>
<key_size>8192</key_size>
<sys_created_by>system</sys_created_by>
<sys_created_on>2026-05-07 14:55:08</sys_created_on>
<sys_id>cdf3cc9cff7c8bd0aef9f7677c4fd915</sys_id>
<sys_mod_count>1</sys_mod_count>
<sys_updated_by>system</sys_updated_by>
<sys_updated_on>2026-05-07 15:05:22</sys_updated_on>
</x_keyfa_app_keyfactor_key_size_algorithms>
<x_keyfa_app_keyfactor_key_size_algorithms action="INSERT_OR_UPDATE">
<key_algorithm>RSA</key_algorithm>
<key_size>2048</key_size>
<sys_created_by>system</sys_created_by>
<sys_created_on>2026-05-07 14:52:26</sys_created_on>
<sys_id>d153c058ffbc8bd0aef9f7677c4fd910</sys_id>
<sys_mod_count>4</sys_mod_count>
<sys_updated_by>system</sys_updated_by>
<sys_updated_on>2026-05-07 15:05:00</sys_updated_on>
</x_keyfa_app_keyfactor_key_size_algorithms>
<x_keyfa_app_keyfactor_key_size_algorithms action="INSERT_OR_UPDATE">
<key_algorithm>RSA</key_algorithm>
<key_size>6144</key_size>
<sys_created_by>system</sys_created_by>
<sys_created_on>2026-05-07 14:52:50</sys_created_on>
<sys_id>d7630458ffbc8bd0aef9f7677c4fd9f3</sys_id>
<sys_mod_count>1</sys_mod_count>
<sys_updated_by>system</sys_updated_by>
<sys_updated_on>2026-05-07 15:05:17</sys_updated_on>
</x_keyfa_app_keyfactor_key_size_algorithms>
<x_keyfa_app_keyfactor_key_size_algorithms action="INSERT_OR_UPDATE">
<key_algorithm>RSA</key_algorithm>
<key_size>16384</key_size>
<sys_created_by>system</sys_created_by>
<sys_created_on>2025-08-01 13:00:53</sys_created_on>
<sys_id>f0e5f2da478b6a908f2dd6d3706d4300</sys_id>
<sys_mod_count>1</sys_mod_count>
<sys_updated_by>system</sys_updated_by>
<sys_updated_on>2026-05-07 15:05:29</sys_updated_on>
</x_keyfa_app_keyfactor_key_size_algorithms>
</unload>

Appendix F: Password length

By default, the application uses a 12-character password. Support for reading settings directly from the Command instance is planned for a future release, though a target release date has not yet been confirmed. In the interim, the password settings can be manually adjusted.

For downloading a PFX

There are two coded places where the length needs to be changed: the native interface button in the Certificate form and the Service Portal Certificate widget.

Native interface button in the Certificate form

1. Access System UI > UI Actions.

2. Search for Download cert (PFX).

   Alternatively, you can access the UI Action directly by using the following URL, where <your instance> is your ServiceNow instance name.

   https://<your instance>.service-now.com/sys_ui_action.do?sys_id=9ca6e9fe478c56508f2dd6d3706d4389&sysparm_record_target=sys_ui_action&sysparm_record_row=1&sysparm_record_rows=1&sysparm_record_list=name%3DDownload+cert+%28PFX%29%5EORDERBYorder

3. In the Script text area (line 15), locate the following line:

   password = GlideSecureRandomUtil.getSecureRandomString(12);

4. Replace 12 with the desired password length.

   For example, to generate a 16-character password, update the line as follows:

   password = GlideSecureRandomUtil.getSecureRandomString(16);

5. Save to update the UI Action.

Service Portal Certificate widget

1. Access Service Portal > Widgets.

2. Search for:

   • Name: Certificate
   • ID: kf-cert

   Alternatively, you can access the widget directly by using the following URL, where <your instance> is your ServiceNow instance name.

   https://<your instance>.service-now.com/now/nav/ui/classic/params/target/sp_widget.do%3Fsys_id%3D4bc734ad47c7fe108f2dd6d3706d4393%26sysparm_record_target%3Dsp_widget%26sysparm_record_row%3D1%26sysparm_record_rows%3D1%26sysparm_record_list%3Dname%253DCertificate%255EORDERBYDESCsys_updated_on

3. In the Server script text area (line 182), locate the requestPFX function.

4. Locate the following line:

   password = GlideSecureRandomUtil.getSecureRandomString(12);

5. Replace 12 with the desired password length.

   For example, to generate a 16-character password, update the line as follows:

   password = GlideSecureRandomUtil.getSecureRandomString(16);

6. Save to update the widget.

If the widget is not editable, you must clone the widget before making changes. After cloning the widget, the new widget will need to be embedded in the appropriate portal page.

For PFX enrollment

Use this procedure to ensure the PFX enrollment call to Command follows the password setting configured in Command.

There are two coded places where the length needs to be changed for enrolling a PFX certificate: the PFX enrollment action item and the PFX enrollment flow item.

PFX enrollment action item

1. Access Flow Designer > Actions.
2. Search for Enroll PFX certificate.
3. Select Step 1 - REST Step - New PFX.

4. In the Request Content text area, locate the following value:

   "Password": action➛Password,

5. Add quotation marks ("") around action➛Password so that the value appears as follows:

   "Password": "action➛Password",

6. Click somewhere outside the Request Content text area.
7. Save and update the action.

PFX enrollment flow item

1. Access Flow Designer > Flows.
2. Search PFX Enrollment.
3. In the Actions section (line 25), locate Enroll PFX Certificate.
4. In the Action Inputs section, delete the value from the Password field so that the field is blank.
5. Click somewhere outside the Action Inputs section.
6. Save and activate the flow.