OpsCx REST WebService Policy SSL/TLS
I have created a simple REST webservice policy for topology.
I'm calling the service from PowerShell and it's working ok but i'm receiving ssl/tls errors
Invoke-RestMethod : The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
I can bypass all errors with some embedded c# delegate for my session but I'd rather not.
What's the proper way to do this ?
It seems this is due to you are using an invalid certificate or the certificate wasn't issued by a trustworthy authority.
If it's production environment, it's better to use valid certificate by Verisign, etc.
I agree with SeanSun, you should try to fix the cause.. Are you still running OpsCx with its self-signed certificate? Then you should replace it with a trusted certificate, see:
I have run into simiar issue before. I am curios though with your solution, because the Web Service Listener actually uses the certificate of the Agent not the web certifcate of the tomcat instance of the Ops Connector. Isnt that true? I was under impression you cant change the agent certificate becase it is signed by your OMi instance not your CA. Please correct me if I am wrong here.
Yep, you're right. The only option is to use the certificates set within the agent. This certificate is issued to the coreId which leads to verification errors reported when the hostname is checked against the CN (also since there is no SAN list in the certificate). Some tools (e.g. done with Java, php, …) can selectively disable hostname verification, some others can only disable checking completely (like the curl CLI). If only hostname verification is disabled the certificate is still verified against the trusted list and communication will only be established it that was successful which is what would be sufficient in this case. (My tacky workaround was to add the coreId as an alias in the hosts file when working with the curl CLI.)
we first solved it using curl as suggested with option to ignore host verification.
now we found a better solution:
simply install a proxy server on the connector server (nginx, apache) and install your certificates. Then redirect all Requests to the OpsCx REST Listener Port 30005.
The internal agent certificate is now hidden to the user and other tools..
I'm having the same thoughts. We're running OpsCx behind a loadbalancer (F5 VIP). The CA signed certificate for the loadbalancing URL is configured for port 30000, as this is the user interface.
On the REST webservice listener port 30005 however the F5 isn't configured to provide the CA signed certificate, so it provides the agent certificate.
We now have several working Micro Focus integrations on the OpsCx using the REST webservice listener, like SCOM, SAP Solution Manager, Azure Log Analytics and vRealize.
Now we also want to use the OpsCx REST webservice listener for other integrations using webhooks, so a hostname verify would be welcome in such a webhook post request.
Is it possible to configure the REST webservice listener port on the F5 to provide the CA signed certificate to support hostname verification, or will this break the existing integrations?
I hope you get answee from MF internal guys. As long this is not happening I suggest the following workaround:
1) Install a apache or nginx as proxy on the OpsCx server and listen on port xxx.
This port es exposed to the outside and probably needs accordingly a firewall rule.
2) in the proxy redirect traffic to the OpsCx Port 30005.
3) configure nginx or apache to use your certificates
with this approach you are even able to hide the exact RestListener URL and can support multiple active versions of the same listener policy. In case of upgrades you do not need to update source systems like SCOM but still you can make REST API versions like /v1/MsSCOM and /v2/MsSCOM..
hope this helps 😉
ps: of course the approach is much easier to implement under Linux than Windows..
I'v put a loadbalancer / virtual IP in front of the OpsCx servers, port xxxxx. This port uses the CA certificate and redirects traffic to the rest webservice port 30005.
All works fine now, thanks!