Certificate Discovery for Certificates with Password

[Morgan2]

Hi guys,

Hoping someone else has run into this. For several of our Linux servers, they have certificates that are password protected. When discovery tries to scan them, it fails with the io_error of "SSLHandshakeException - Received fatal alert: handshake_failure". The port is 8443, so nothing crazy. The server can be scanned normally with no other issues. Is there a place to store a password for certificate discovery? I can't find anything about it anywhere. I opened a case with ServiceNow regarding this issue and got nowhere.

Thanks!

[AJ-TechTrek]

Hi @Morgan2 ,

As per my understanding Issue Summary is

When Discovery hits a password-protected SSL certificate, the connection fails during SSL handshake with:
SSLHandshakeException - Received fatal alert: handshake_failure
This typically happens when:
* The server expects a client-side certificate or mutual TLS (mTLS).
* The keystore has a password and the MID Server doesn't know how to provide it.
* Discovery doesn't support passing a certificate password in the probe.

Direct Answers to Your Questions
Is there a place to store a password for certificate discovery?
No, by default ServiceNow Discovery does not have a built-in configuration to store passwords for SSL certificate access during scanning (such as keystore/truststore passwords). Discovery only supports:
* Providing protocol-specific credentials (SSH, SNMP, WMI, etc.)
* Using credentials for web services APIs (basic auth, OAuth, etc.)
* It does not support sending client certificate passwords or interacting with encrypted keystores out of the box.

Solution Options & Workarounds
1. Use SSH for Linux Discovery (Avoid SSL on 8443)
If your goal is standard Discovery of Linux servers, you do NOT need to use HTTPS (8443) at all:
* Use SSH credentials to connect to the server for Host, App, and Software discovery.
* Make sure port 22 is reachable and the SSH credential works.
Why this matters: Discovery on 8443 is likely triggering a Web Service (HTTP/HTTPS) or Port Probe, which expects an open and simple SSL handshake — not a password-protected cert.

2. Skip Certificate-Based Scanning in Probes
If this port (8443) is not critical to CMDB data population, configure the Discovery Behavior or Port Probes to skip scanning that port:
* Go to: Discovery > Discovery Schedules
* Edit the schedule > under "Behavior", configure port exclusions.
* Or modify the port probe pattern to avoid sensitive SSL ports.

3. Custom Probe with Client Cert + Password (Advanced)
If this HTTPS endpoint (on 8443) must be discovered and requires:
* Client certificate + password
* Mutual TLS
Then you may:
* Create a custom probe using the MID Script include to invoke Java HTTPS client.
* Store the certificate in a keystore on the MID Server.
* Modify the probe to use that keystore with password during connection.
This is non-trivial, not officially supported out-of-the-box, and needs strong Java + MID Server customization experience.

4. Scan with External Tools + Import
If Discovery can't handle it natively:
* Use external scanners (e.g., nmap, OpenSSL, custom bash scripts) from a central scanning server with access to the certs.
* Import results via IntegrationHub ETL, import sets, or custom script to the CMDB.

Quick Checklist:-

What to Check	Action
Is port 8443 essential to Discovery?	If not, skip it using behavior rules
Are you trying to connect to an HTTPS API for app discovery?	Use HTTP Credentials (basic/OAuth) instead
Does the service require mTLS?	MID Server can't provide passworded certs natively
Can you SSH to the server?	Use SSH credentials instead for normal Linux discovery
Still need to hit 8443?	Build a custom MID Script Probe (Advanced)

Important Notes on MID Server and Keystores
If you go the custom MID Script Probe route:
* Store the certificate in the keystore file on MID.
* Reference it in the probe script like:
System.setProperty("javax.net.ssl.keyStore", "path/to/keystore.jks");
System.setProperty("javax.net.ssl.keyStorePassword", "your-password");
* You cannot store cert passwords in ServiceNow credential tables.

Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
 

Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025

[Morgan2]

You mention ServiceNow does not support discovery of password protected certificates. Is there a SN doc you can point me to that specifies that?

These few password protected certs are in the minority and we have an active certificate mgmt process in place, so skipping discovery of port 8443 is a no go. And yes, normal discovery of the server works fine, it's just the weird certificates we're having trouble with.

Thanks!