Highlighted
Super Contributor.
Super Contributor.
1111 views

OpsCx REST WebService Policy SSL/TLS

Hi all

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 ?

regards

 

Steve C

Labels (1)
Tags (1)
0 Likes
8 Replies
Highlighted
Super Contributor.
Super Contributor.

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.

 

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

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:

https://docs.microfocus.com/itom/Operations_Connector:10.11/BSMC/security/sec_prep_certs#.24filename.7C  

Volker

0 Likes
Highlighted
Respected Contributor.
Respected Contributor.

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.

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

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.)

CP.

0 Likes
Highlighted
Honored Contributor.
Honored Contributor.

Hi guys

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..
0 Likes
Highlighted
Trusted Contributor.
Trusted Contributor.

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?

Kind regards

0 Likes
Highlighted
Honored Contributor.
Honored Contributor.

Hi
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..
Highlighted
Trusted Contributor.
Trusted Contributor.

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!

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.