Benefits

• Take inventory of all your TLS certificates
• Keeps you informed of impending expirations
• Creates certificate tasks via flows to renew expiring certificates
• Creates incidents for already expired certificates
• Prioritizes certificate importance
• Helps you proactively manage your certificates
• Helps you avoid manually tracking large volume of certificates
• Prevents costly outages due to expired or expiring certificates

Request apps on the Store

Visit the ServiceNow Store website to view all the available apps and for information about submitting requests to the store. For cumulative release note information for all released apps, see the ServiceNow Store version history release notes.

Requirements

Make sure the ITOM Visibility [com.snc.itom.vis.license] plugin, Discovery [com.snc.discovery] plugin, and Configuration Management for Scoped Apps (CMDB) [com.snc.cmdb.scoped] plugin are installed and activated and that you have upgraded to Orlando or later. You can then download the Certificate Inventory and Management application from the ServiceNow Store.

How Certificate Inventory and Management works

Certificate Inventory and Management allows Discovery to automatically scan for certificates on specific ports through your existing CI-based Discovery schedules. In addition, you can create new Discovery schedules to scan individual URLs.

In Version 1.1.7 Certificate Inventory and Management, you can also scan for certificate authorities (CA) and import certificates from files.

The initial part of the process is different depending where the certificates are discovered from.

• Discovery via Ports
  The port probe [tls_ssl_certs] automatically scans 14 default preauthorized ports.

  • Typical ports for SSL: 443, 8443, 9443, 636 (ldaps), 993 (imaps), 995 (popssl), 989, 990
  • StartTLS ports: 25 (smtp), 110, 143, 389, 21, 587 (smtp)

  As part of the CI Discovery process during Shazzam, the MID Server executes scanners to get the certificate chain information from the IP port number. It captures various certificate attributes and other data including certificate hierarchy. The MID Server transforms the certificates to an XML payload containing the certificate information and shares the XML payload with the instance. The Shazzam sensor on the instance picks up the ECC queue entry and adds a new record into the Discovered Certificate [sn_disco_certmgmt_certificate_history] table.

• Discovery via URL

  The Certificate URL [sn_disco_certmgmt_cert_url] table holds a list of URLs to target for certificate discovery. Each record also has an optional reference to the Unique Certificate [cmdb_ci_certificate] table, to see what certificate is related to the given URL definition. The necessary parameters from the Discovery Schedule are combined to create and initialize the Discovery status. The [CertificateDiscoveryFromURLScan] probe discovers the certificate chain for each of the URLs in the batch and outputs an XML payload that contains the certificate chain for each certificate. It also adds a new record into the Discovered Certificate [sn_disco_certmgmt_certificate_history] table.

• Discovery via Import Certificates (Version 1.1.7 Certificate Inventory and Management)
  The Import certificates are discovered using the pattern Import SSL Certificate, which uses the following:

  • Host name/IP on which the certificates are hosted
  • Folder in which certificates are present
  • TLS_keepOriginalCertificate: If the TLS_keepOriginalCertificate parameter is set to true, it will increase the payload size which can cause out-of-memory issues.
  • Mid_temp_folder: The folder on the MID Server where the files will be copied temporarily.

  Note: Auto-select MID Server option is NOT supported for Windows and Linux mid combinations. If the MID Server is used for storing the original certificates files, then Host name/IP should be set to blank or localhost and the particular MID Server should be selected for the Discovery schedule.

• Discovery via CA authority (Version 1.1.7 Certificate Inventory and Management)

  Once the Certificate Inventory and Management credential is set up with either GoDaddy or DigiCert Certificate Authority and the Discovery schedule runs, the GoDaddy or DigiCert pattern makes REST API calls to (GoDaddy or DigiCert), collects certificate information, retrieves the list of certificates, and stores it in the [cmdb_ci_certificate], [certificate_domain], and [sys_attachment] tables.

  The following are arguments for GoDaddy and DigiCert patterns:

  • Start_offset: The offset position to read certificates from the CA authorities. The default value is 0.
  • Limit: The number of certificates to be read from the start_offset. The default value is 1500.
  • CredentialAlias: The Alias for the credentials of the CA.
  • If the TLS_keepOriginalCertificate parameter is set to true, then the certificate file is attached to the Certificate CI. This will increase the payload size and can cause out-of-memory issues.

• From this point on, the process is the same.

  The Unique Certificate [cmdb_ci_certificate] and Installed Certificate [sn_disco_certmgmt_cmdb_installed_certificate] tables are then populated with the TLS certificate chains, signed by the certificate authority and root. After certificates have been discovered, a scheduled job automatically checks the Unique Certificate [cmdb_ci_certificate] table for expiring and expired certificates. Certificate tasks and incidents are then created and assigned. You can also manually request new certificates and renew certificates see Certificate Inventory and Management workflow for more information.

  To optimize system performance, a table cleaner automatically deletes old certificate records after a specified number of days from these two tables:

  • Discovered Certificate [sn_disco_certmgmt_certificate_history] table: older than 30 days
  • Installed Certificate [sn_disco_certmgmt_cmdb_installed_certificate] table: older than 90 days