ITOM Academy: Certificate Inventory and Management Best Practices

Business-focused summary: Certificate Inventory & Management Best Practices (ServiceNow ITOM Academy)

Why certificate inventory management is needed

• Visibility + CMDB business context is the “foundation/fuel” for downstream automation and (implied) AI/workflow success.
• Primary operational risk: proactively track expiring TLS certificates to prevent outages and compliance failures.
• Regulatory/timing pressure: TLS certificate lifetimes are being reduced to 47 days, creating a tighter renewal cadence challenge.
• Business impact of poor practices:
  • ~Half of surveyed enterprises reported certificate-related outages in the prior year.
  • Manual processes can drive “six-figure losses” due to rising certificate volumes and operational inefficiency.
• Outcome goals (solution intent):
  • Prevent outages via proactive expiring-certificate identification.
  • Reduce manual tracking through built-in automation workflows.
  • Scale operational capacity as certificate volumes and requirements grow.

Framework / operational playbook elements (as described)

• CMDB-driven inventory + relationships
  • Discover certificates → populate CMDB with unique certificate records and (where applicable) installed certificate records.
  • Use CMDB/service mapping context to understand service impact if a certificate expires.
• Discovery-to-automation workflow
  • Discovery methods feed inventory → automated tasks/requests/incidents → CA signing → CMDB update → change management artifacts.
• Policy-based automation
  • Renewal task creation based on configurable expiration thresholds.
  • Optional exception handling: proactive renewal for most, reactive incident creation for non-compliant/exception cases.

Key KPIs / targets / timelines mentioned

• 47-day TLS certificate lifetime reduction (upcoming official change).
• Proactive renewal task lead time:
  • Example/config: creating renewal tasks 60 days prior to expiration (also described as adjustable).
  • Out-of-the-box renewal threshold examples: 15 / 30 / 60 / 90 days (configurable).
• Out-of-box renewal task/incident behavior:
  • Create renewal tasks based on threshold.
  • For expired/non-compliant certs, create incidents (described as an alternative initial approach).

Solution overview: Certificate Inventory and Management app

• Store application: “Certificate inventory and management” (ServiceNow Store) with a Certificate Management Workspace and automation workflows.
• Core outcomes:
  • Proactive expiring-certificate identification (outage prevention).
  • Reduced operational effort (automation vs manual tracking).
  • Improved governance through workflow + lifecycle visibility.

---

How the system works (execution model)

1) Certificate discovery methods (to populate CMDB)

Certificates are discovered via four main methods, selected based on use cases:

• Port-based discovery (port probe / IP-based)

  • User defines subnets/IP ranges and ports (examples: 443, 8443, 9443 or other encryption ports).
  • Detects certificates “hanging off” open ports.
  • Creates:
    • Unique certificate record
    • Installed certificate record (adds location/installation context)
  • If service mapping is enabled, enables service impact context.

• Pattern-based discovery (Java/Windows key stores)

  • Searches for certificates in key stores using patterns.
  • Creates unique + installed records and relationships to services (when service mapping is available).

• CA-signer API-based discovery

  • Pulls an inventory of unique certificates from supported certificate authorities.
  • Does not rediscover installed infrastructure context.
  • Generates lifecycle tasks like renewal based on platform definitions.
  • Supported (as stated): AWS, GCP, Microsoft, Sectigo, DigiCert, GoDaddy, Entrust.

• URL-based discovery (for DMZ / managed service providers)

  • User provides URLs; the platform retrieves certificate details.
  • Creates unique certificate only (no infrastructure install context), but still supports renewal workflows.

Demo implementation note (port probe)

• The port probe is not enabled by default after app install.
• Must enable the TLS/SSL certificates port probe under discovery definitions and ensure it’s within the app’s scope.
• Port probe discovery targets can be customized (e.g., supported services like HTTPS, Tomcat SSL, IBM SSL, plus custom services/higher ports).

2) Lifecycle automation after discovery

Once certificates are in CMDB, the platform supports automated workflows:

• Renew / request / revoke actions via out-of-the-box catalog items.
• Proactive task creation before expiration:
  • Configurable threshold (example shown: 60 days, also 15/30/60/90 described).
  • Renewal tasks assigned using certificate ownership metadata.
• Reactive incident creation for expired or non-compliant certificates (policy-based).
• Automated fulfillment via UI + workflow routing
  • Users (employee portal / kubernetes manager described in UI context) submit requests to fulfill:
    • new certificate
    • renewal
    • revoke
  • Then workflows route to the appropriate CA and update CMDB.

3) CA integration / signing automation

• Automated routing policies determine how/where the request goes for signing.

• Signing delivery methods described:

  • Direct API integrations (examples stated): DigiCert, Microsoft, Entrust.
  • ACME protocol-based integration for CAs where ACME is deployed.
    • Mentioned: CA signing via EJBC A través Acme, and Let’s Encrypt / ZeroSSL-style flow is mentioned by protocol name.
    • Specific list includes JBCA through Acme, Let’s Encrypt, and similar ACME-backed services.

• After signing:

  • Platform retrieves signed certificate + intermediate/root chain
  • Stores into CMDB
  • Auto-generates a change request (change governance artifact)

• Last-mile deployment:

  • Not supported yet, but explicitly called out as planned future roadmap.

4) Governance + visibility dashboards

• Certificate Management Workspace
  • Inventory tracking
  • Renewal/new/revoke request tracking
  • Certificate record drill-down: routing policies, discovered context, certificate chain relationships
• Workspace also supports operational monitoring of tasks and their fulfillment status.

---

Concrete examples from the demo / best-practice guidance

Example: Enable port-probe discovery and run discovery schedules

• Enable port probe “TLS SSL certificates” (not default).
• Configure IP-based discovery schedule:
  • pick discovery type (example: IP-based)
  • add subnet (example shown: 0/24)
  • select midserver
• Run weekly CA-based API discovery schedules (example shows weekly cadence).
• Add URL-based discovery entries and store next-time-run certificates in CMDB.

Example: Automated certificate request using catalog items

• Request flow demonstrated with:
  • Generating a CSR and private key (if CSR not provided)
  • Private key handling guidance:
    • platform generates the private key but is not a secure vault
    • operator must download/store privately in a secure location
• Then:
  • request submitted
  • automation routed to CA signer based on attributes
  • workflow includes DNS challenge (example shown for ACME-style request)
  • upon success: downloads signed certificate + chain, stores in CMDB, and creates a change ticket

Example: Renewal task automation and assignment

• Renewal tasks are configured to create based on expiration threshold.
• Tasks get assigned to certificate owners (when ownership metadata exists).
• Demo described ability to monitor task status and handle failures (example failure due to midserver down, then rerun when up).

Best-practice recommendations (explicitly stated)

• Avoid creating automated renewal tasks before certificate owners are known
  • Recommendation given: consider disabling “enable renewal task creation for all discovered certificates” initially to prevent orphan tasks.
• Alternative early-phase approach:
  • Disable renewal task automation for discovered certs
  • Instead, create incidents for expired certificates so teams can respond without misassignment.
• Adjust incident workflow parameters
  • Can configure:
    • expiring threshold (out-of-box example 60)
    • incident caller/user id
    • incident assignment group behavior (implied configurability)

Troubleshooting guidance (patterns / permissions)

• If pattern-based discovery (Java/Windows key stores) doesn’t find certs:
  • likely permission issue with the credentials used to query key stores.
• Use discovery logs/pattern logs to identify errors and run troubleshooting.

---

Kubernetes / agent-based execution and bulk import (operations)

• Kubernetes discovery support

  • Platform can support external issuer downloads by deploying a container image using Docker recipe/binary and deploying via Helm or Kubernetes YAML.
  • Enables discovery + renewal of external issuers in Kubernetes contexts.

• Agent Client Collector (ACC) support

  • ACC can be used for certificate discovery (mentioned as added in Q2/Q3 timeframe).
  • Policy may be disabled/inactive by default after upgrade; requires enabling.
  • Port/probe-defined services should match ACC discovery configuration (JSON config deployed with the check).

• Bulk import option

  • Bulk import into CMDB is still available via discovery schedule selection flow (use import option instead of API URL).

---

License / packaging model (product ops)

• Certificate Inventory and Management is included in the ITM Visibility license.
• Discovery does not consume CA usage (i.e., it’s inventory/discovery work, not CA “transactions”).
• Future roadmap may change licensing, but current state: included with ITM Visibility license.

---

Presenters / sources (as mentioned in the subtitles)

• John Mario Deui (Outbound Product Management, IT team)
• Derek Kitsman
• Suri (Inbound Product Team)
• Support team mentioned in the background: Ran Zuli, Bran Quinn, Yoling Young
• Additional names thanked at the end: Steve, Brian, Ryan