Outbound REST Call fails with "Session contains no certificates - Untrusted" No MID Server!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-19-2025 10:01 AM
Hi Team,
this might be a bit of a unique issue but maybe someone has an idea.
Requirement: I need to access a webservice that is not public.
The webservice runs in an azure environment and is accessible within the network via http.
What we did so far: Created a public fqdn (server1.customer.com) that points to the internal server (server2.customer.com) that hosts the webservice.
Firewall rules are applied and seems work correctly.
Connections from the instance IPs are allowed.
So far, so good.
Problem: I only get the certificate error if I use server1-123.customer.com. (server1 but with a slightly different name)
If I use server1.customer.com, the error is "java.net.UnknownHostException: server1.customer.com"
Same error if I use the internal server name "java.net.UnknownHostException: server2.customer.com"
We've created self signed certificates for server1 and server2 and imported them into ServiceNow's certificates. Both of them are valid until 2028.
Since the Endpoint url (server1-123.customer.com) is slightly different then the certificates cn ServiceNow refuses to use the certificate for the connection (Just my assumption)
Maybe worth mentioning is, that the fqdn server1-123.customer.com belonged to a long decommissioned server.
The only thing I've found to circumvent the naming issue ist to change the property "com.glide.communications.httpclient.verify_hostname" to false. Which resulted in an "Unknown Host" error..
I'm running out of ideas, unfortunately.
Had anyone a similar requirement and setup?
TIA
Cheers Bernd

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-19-2025 10:30 AM
Because your endpoint is different, your cert isn't valid and SN is rightly refusing to connect. Your best (and correct) course of action is to create a new cert, or map the server1.customer.com to internally route to server1-123.customer.com