Understanding Serverless Discovery: Why SSL Certificates Are Required for MID Server!

[Selva Arun]

Understanding Serverless Discovery: Why SSL Certificates Are Required for MID Server

📋 Purpose

While implementing Kubernetes and Nutanix discovery in ServiceNow, I learned about a different approach to discovery called "Serverless Discovery". This article explains what serverless discovery is, why it requires SSL/TLS certificates on the MID Server, and how it differs from traditional discovery methods.

🎯 What is Serverless Discovery?

During my implementation of Kubernetes and Nutanix discovery, I encountered the term "Serverless Discovery" in the discovery schedule type dropdown. This was different from the traditional "Configuration Items" discovery I was familiar with.

My Initial Confusion

When I first saw "Serverless" as a discovery type, I was confused:

• 🤔 Does this mean no servers are involved?
• 🤔 Why is it called "serverless" when we're discovering servers?
• 🤔 How is this different from normal discovery?

What I Learned

Serverless Discovery is a ServiceNow discovery method that uses REST API calls over HTTPS instead of traditional network scanning protocols like SSH, WMI, or SNMP.

The term "serverless" refers to the discovery method, not the infrastructure being discovered. It means:

• ✅ No traditional SSH/WMI/SNMP probe infrastructure needed
• ✅ No direct server-level access required and uses a Discovery Pattern
• ✅ API-driven communication over HTTPS
• ✅ Ideal for cloud-native platforms and containerized environments

⚠️ Important: Servers still exist - we're just discovering them differently!

🔄 Traditional vs Serverless Discovery: What I Observed

Here's the key difference I noticed during my implementations:

Traditional Discovery (What I Was Used To)

Example: Windows Server Discovery

ServiceNow → MID Server → Opens Multiple Connections: ├── Port 135 (RPC) ├── Port 445 (SMB) ├── Port 3389 (RDP) [optional] └── Uses WMI protocol with Windows credentials

Characteristics:

• Multiple ports and protocols required
• Direct OS-level access (SSH for Linux, WMI for Windows)
• Uses credentials like SSH keys or Windows domain accounts
• Discovery schedule type: "Configuration Items"

Serverless Discovery (What I Implemented for Kubernetes & Nutanix)

Example: Kubernetes Discovery

ServiceNow → MID Server → Single HTTPS Connection: └── Port 6443 (Kubernetes API) └── Uses Bearer Token authentication └── REST API calls to discover pods, nodes, services

Example: Nutanix Discovery

ServiceNow → MID Server → Single HTTPS Connection: └── Port 9440 (Nutanix Prism API) └── Uses Basic Authentication (username/password) └── REST API calls to discover hosts, VMs, storage

Characteristics:

• Single HTTPS endpoint (one port: 443, 6443, or 9440)
• No direct OS access needed
• API-based authentication (tokens or basic auth)
• Discovery schedule type: "Serverless" or "Cloud Application"

Comparison Table

Aspect	Traditional Discovery	Serverless Discovery
Method	Network scanning (SSH, WMI, SNMP)	REST API calls (HTTPS)
Protocols	SSH (22), WMI (135/445), SNMP (161)	HTTPS only (443/6443/9440)
Authentication	SSH keys, Windows credentials	API tokens, Basic auth
Network Access	Multiple ports per device	Single HTTPS endpoint
Schedule Type	"Configuration Items"	"Serverless"
Use Cases	Traditional servers, databases, network devices	Cloud platforms, Kubernetes, containers, hypervisors
Example Platforms	Linux/Windows servers, Oracle DB, Cisco switches	Kubernetes, AWS, Azure, VMware, Nutanix

🔐 Why SSL/TLS Certificates Are Required for MID Server

This was the most confusing part of my implementation. Here's what I learned:

The Problem I Encountered

When I first ran my Kubernetes discovery schedule, it failed with this error:

❌ Error:

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.cert.certPathBuilderException: unable to find valid certification path to requested target

Translation: The MID Server doesn't trust the SSL certificate from the Kubernetes API server.

Understanding the HTTPS Connection

Serverless discovery patterns connect to API endpoints using HTTPS (secure HTTP). When the MID Server attempts to connect, an SSL/TLS handshake must occur:

MID Server API Endpoint (Kubernetes/Nutanix) | | |------- 1. Hello (Let's Connect) -------->| | | |<------ 2. Here's My SSL Certificate -----| | | |------- 3. Validating Certificate... -----| | (Checks Java truststore) | | | |<------ 4. ✅ Trust Established ---------| | | |------- 5. Encrypted API Calls Begin ---->|

At Step 3, the MID Server checks: "Do I trust this certificate?"

If the certificate isn't in the MID Server's trust store, the connection fails.

Why This Security Check Exists

The SSL/TLS handshake ensures:

1. Server Identity Verification - Confirms we're connecting to the real Kubernetes/Nutanix API, not an imposter
2. Encrypted Communication - Protects credentials and data in transit
3. Certificate Chain Validation - Verifies the certificate is issued by a trusted authority

⚠️ Without this: Someone could intercept the connection, steal credentials, or inject malicious data.

🔧 Why Java Keystore? (The Part That Confused Me Most)

My Initial Mistake

When I first encountered the certificate error, I thought:

• "I'll just install the certificate in Windows Certificate Store"
• "Maybe I need to add it to the Linux system trust store"

Both were wrong! ❌

What I Learned

The MID Server runs on Java, and Java maintains its own certificate trust store completely separate from the operating system.

This means:

• ❌ Installing in Windows Certificate Store → MID Server can't see it
• ❌ Installing in Linux /etc/ssl/certs/ → MID Server can't see it
• ✅ Installing in Java keystore (cacerts) → MID Server can see it! ✅

Java Truststore Location

Windows MID Server: C:\Program Files\ServiceNow\<MID_NAME>\agent\jre\lib\security\cacerts Linux MID Server: /opt/servicenow/mid/agent/jre/lib/security/cacerts

This cacerts file is Java's trusted certificate store - like a phonebook of "certificates I trust."

📝 The Certificate Import Process (High-Level)

Here's the general workflow I followed for both Kubernetes and Nutanix:

1Export the SSL Certificate

From the target platform (Kubernetes API server, Nutanix Prism):

• Using a web browser (view certificate → export)
• Using OpenSSL command
• Using platform-specific tools

Result: A .cer or .crt file containing the public certificate

2Transfer to MID Server

Copy the certificate file to your MID Server host (Windows or Linux)

3Import into Java Keystore

Use the keytool command (comes with Java):

Windows:

cd "C:\Program Files\ServiceNow\<MID_NAME>\agent\jre\bin" keytool -import -alias my-platform-cert -keystore ..\lib\security\cacerts ^ -file C:\temp\certificate.cer -storepass changeit -noprompt

Linux:

cd /opt/servicenow/mid/agent/jre/bin ./keytool -import -alias my-platform-cert -keystore ../lib/security/cacerts \ -file /tmp/certificate.crt -storepass changeit -noprompt

Key Parameters:

• -alias → A friendly name for the certificate
• -keystore → Path to Java's cacerts file
• -file → Path to the certificate file
• -storepass → Password for keystore (default is changeit)

4Verify Import

keytool -list -keystore ../lib/security/cacerts -storepass changeit | grep my-platform-cert

5Restart MID Server

⚠️ CRITICAL: Always restart the MID Server service after importing certificates!

The MID Server reads the truststore at startup. Without a restart, it won't see the new certificate.

🚀 Real-World Examples: What I Implemented

I successfully implemented serverless discovery for two platforms:

Example 1: Kubernetes Discovery

What I Discovered:

• Kubernetes Clusters
• Nodes (worker and master)
• Namespaces
• Pods, Services, Deployments
• ReplicaSets

Authentication Method: Bearer Token (Kubernetes Service Account)

Certificate Source: Kubernetes API Server (https://<k8s-api>:6443)

📖 Full Implementation Guide:
Kubernetes Discovery with ServiceNow - Complete Se... - ServiceNow Community

Example 2: Nutanix Discovery

What I Discovered:

• Nutanix Clusters
• AHV Hypervisor Hosts
• Virtual Machines
• Storage Containers
• Networks

Authentication Method: Basic Authentication (username/password)

Certificate Source: Nutanix Prism Central/Element (https://<prism-ip>:9440)

📖 Full Implementation Guide:
Knowledge Article: Supplemental Guide to Nutanix A... - ServiceNow Community

⚠️ Common Certificate Errors I Encountered

1. SSLHandshakeException: PKIX Path Building Failed

Error Message:

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.cert.certPathBuilderException

What It Means: Certificate not in Java truststore

Solution: Import certificate using keytool and restart MID Server

2. Certificate Name Mismatch

Error Message:

Certificate for <10.0.0.100> doesn't match any of the subject alternative names

What It Means: Certificate was issued for a hostname/FQDN, but you're connecting using an IP address

Solutions:

• Use the FQDN in your discovery target instead of IP
• Regenerate the certificate with the IP in Subject Alternative Name (SAN)

3. MID Server Not Restarted

Symptom: Certificate imported successfully, but discovery still fails with SSL error

What It Means: MID Server hasn't reloaded the truststore

Solution: Always restart MID Server service after certificate changes

4. Wrong Java Truststore Modified

Symptom: Certificate shows in keystore listing, but discovery still fails

What It Means: Multiple Java installations on server; modified the wrong one

Solution:

• Check which Java the MID Server uses (check wrapper.conf)
• Import certificate to the correct Java installatio

🛠️ Best Practices I Learned

1. Certificate Management

Track Expiration Dates:

• Most SSL certificates expire after 1-2 years
• When certificates renew on the target platform, re-import to MID Server
• Set calendar reminders 30 days before expiration

Check Certificate Expiration:

keytool -list -v -keystore cacerts -storepass changeit -alias my-cert | grep "Valid until"

2. Multiple MID Server Environments

If you have DEV, TEST, PROD MID Servers:

• ✅ Import certificates to each MID Server separately
• ✅ Document which certificates are on which servers
• ✅ Keep certificate files in a secure, accessible location

3. Use Descriptive Certificate Aliases

Good naming:

-alias k8s-prod-cluster-01 -alias nutanix-prism-central-prod -alias k8s-dev-api-cert

Avoid generic names:

-alias cert1 -alias kubernetes -alias test

4. Always Test Before Production

My workflow:

1. ✅ Export certificate from target platform
2. ✅ Import to DEV MID Server first
3. ✅ Test discovery in DEV environment
4. ✅ Document the process
5. ✅ Repeat for TEST and PROD MID Servers

5. Security Reminder

NEVER disable SSL verification in production!

While testing, you might see suggestions like:

• Using -k flag in curl
• "Skip certificate validation" options

❌ Do not do this in production!

Disabling SSL verification:

• Exposes credentials to man-in-the-middle attacks
• Cannot verify server identity
• Violates security compliance

Always use proper certificate trust!

📊 When to Use Serverless Discovery

Based on my experience, serverless discovery is ideal for:

✅ Good Fit for Serverless Discovery:

• Cloud platforms (AWS, Azure, GCP)
• Container orchestration (Kubernetes, OpenShift)
• Hypervisors with REST APIs (Nutanix, VMware vCenter)
• SaaS applications with APIs
• Load balancers (F5, Citrix NetScaler)
• Public cloud services

❌ Not Ideal for Serverless Discovery:

• Traditional Windows/Linux servers (use traditional WMI/SSH)
• Network switches without REST APIs (use SNMP)
• Legacy systems without API support
• Databases on standalone servers (use native protocols)

Rule of Thumb: If the platform has a REST API endpoint, consider serverless discovery!

🎓 Key Takeaways: What I Want You to Remember

After implementing both Kubernetes and Nutanix discovery, here's what's most important:

1. Serverless ≠ No Servers

"Serverless" refers to the discovery method (API-based), not the infrastructure. Servers still exist; we're just discovering them differently.

2. HTTPS Means SSL Certificates

Serverless discovery uses HTTPS for security. This means:

• SSL/TLS certificates are mandatory
• Certificates must be in the MID Server's Java truststore
• Certificate issues are the #1 cause of discovery failures

3. Java Truststore ≠ OS Certificate Store

The MID Server uses Java's own certificate store, completely separate from Windows or Linux system trust stores.

Always import to Java keystore!

4. Always Restart MID Server

After importing certificates, always restart the MID Server service. Java reads the truststore at startup.

5. Test, Document, Repeat

For each platform:

1. Test certificate export/import process
2. Document the steps
3. Test discovery in non-production
4. Apply to production with confidence

📚 Additional Resources

Java Keytool:

• Oracle Java Keytool Documentation

💡 Final Thoughts

When I started implementing Kubernetes and Nutanix discovery, I was confused by the term "serverless" and frustrated by SSL certificate errors. Through trial and error (mostly error! 😅), I learned:

• Serverless discovery is just a different approach - using APIs instead of traditional protocols
• SSL certificates aren't optional - they're fundamental to HTTPS security
• Java truststore management is key - you must understand where certificates go
• Documentation helps everyone - that's why I'm sharing this!

If you found this helpful, please mark it as 'Helpful' below. This helps other community members find solutions faster!

For detailed implementation steps for specific platforms, please refer to my Kubernetes and Nutanix guides linked above.

ℹ️ Article Information

Concept Explanation Lessons Learned

Last Updated: October 2025

Platforms Referenced: Kubernetes, Nutanix

Author: Community Contributor

⚠️ Disclaimer: This article reflects my personal implementation experience and lessons learned. For detailed implementation steps, refer to the platform-specific guides linked above. Always consult official ServiceNow documentation and test in non-production environments.

Questions or feedback? Please comment below or reach out via the ServiceNow Community!

Thank you for reading! 🙏

---

Keywords: ServiceNow Discovery, Serverless Discovery, SSL Certificates, TLS, MID Server, Java Keystore, Certificate Trust, API-Based Discovery, ITOM, Discovery Troubleshooting, Kubernetes, Nutanix