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
