How To Resolve Issues Connecting vRealize Orchestrator To Hosted ServiceNow

On one of my vRealize Automation engagements, I was asked by my customer to integrate their vRealize Automation environment with their externally-hosted ServiceNow implementation. Now, this was a typical distributed environment and Orchestrator was buried deep inside a subnet, along with other servers within the deployment. Obviously, the machines talked to each other fine but for connection to ServiceNow to work, Orchestrator needed to be able to communicate with the outside world. Here I should mention that I followed this excellent article (and the package) to connect and it worked once the communication path was sorted so I am just documenting a couple of hurdles in between and how I got around them, in case you need to do the same.

Firewall or Proxy:

The first step in the process is to “Add a SOAP host”. I tried (even though I kinda knew it was going to fail) and after failure, confirmed that there indeed wasn’t a path available. There were a fair number of routers and access policies in between so it was decided that it would be best if we just go through the proxy, unless it was impossible. The “Add a SOAP Host” workflow allows using a proxy so that wasn’t a problem. You might just open a path. The point is that it’s easy to forget that a path needs to open from the Orchestrator to the destination website so it should be arranged otherwise adding the host won’t work.

Using cURL:

Using a proxy allowed the workflow to move forward but now it started to get stuck while trying to add the SSL Certificate, eventually timing out. Using the NetStat technique, I could see Orchestrator being able to talk to the remote end. So, what was happening? To find out, I used cURL, which is available from the Orchestrator appliance.

curl -v -x <Proxy Server:Port> https://<Instance>.service-now.com/cmdb_ci_vmware_instance.do?WSDL

where -v is to have verbose output and -x specifies the proxy. Destination was customer’s ServiceNow instance and the table I was trying to access.

As you can see, cURL verified that I was indeed connecting to the site successfully but as shown in the red box, the SSL certificate for the site couldn’t be verified. The text below basically says that website’s certificate authority is not trusted by the appliance. Just to confirm that was indeed the issue, I used:

curl -v -k -x <Proxy Server:Port> https://<Instance>.service-now.com/cmdb_ci_vmware_instance.do?WSDL

where -k asks cURL to carry on with the untrusted certificate. The resulting output was like this:

which meant I was on the right track. Just so that you know, here is some of the rest of the output, showing what you should see when it works:

Certificate Import:

All of this meant that I needed the appliance to trust the certificate first, for it to let the workflow run properly. I went to the website and exported the certificate from there. As there are different methods of doing so depending on the browser, how to do that is left as an exercise for the reader.

Once exported, I went to vRealise Orchestrator Configuration and imported the certificate into “SSL Trust Manager”.

That was it! Running the “Add a SOAP Host” workflow next was successful and I was able to do the rest without issues.

Hope this helps!