Issue with scriptlibrary calling doHttpRequest using GET with https URL
I am trying to call 3rd party rest application from HPSM Scriptlibrary wherein I am calling doHttpRequest function with GET method and passing a HTTPS url. After executing the script, I am getting below error.
"Error calling method: doHttpRequest in class: com/hp/ov/sm/server/utility/HttpClient Exception (javax.net.ssl.SSLHandshakeException: java.security.cert.Certifi
cateException: No subject alternative names present)"
I could understand that I need to import certificate in HPSM server. However I am not able to figure out where exactly I should import the certificate file and how to detect the same at run time.
I am attaching the code written in the scriptlibrary.
Please help me troubleshoot this issue at the earliest.
hope you are doing fine.
I wanted to let you know that a ticket was already open for this issue, it is under investigation and as soon as possible the engineer will contact you with an update.
Customer Support Engineer
If you find that this or any other post resolves your issue, please be sure to mark it as an accepted solution.
If you are satisfied with anyone’s response please remember to give them a KUDOS by clicking on the STAR at the bottom left of the post and show your appreciation.
Add the public key to the target URL into your trustStoreFile on the ServiceManager application servers. Depending on the requirements of the site you're targeting, they may require the public key for your ServiceManager application (the private key should already be stored in your keystore file on the app servers)
Also additional information that certificate was provided to us is not contain FQDN it was created for local machine, localshot.localdomain. It is not correct certificate so it is route couse of such error, am I right?
We try to import it into IE and we can add it to trustStoreFile on the Service Manager in order to use doHttpRequest command in SM.
Think of certificates like a kind of identification - like a passport or a driver's license - and the site you're visiting is like some place that requires you to prove ID. Consider the following analogy
So, you try to get in to this place, and they ask you to provide your ID. If you don't have any ID, they don't let you in.
If you have ID, but it's something you printed out on your home computer, the guard at the door doesn't let you in, because even though the picture on the ID looks like you, he doesn't trust the source.
If you have ID from an official source, but the picture on the ID doesn't look like you, the guard at the door doesn't let you. he trusts the source, but the ID you're presenting doesn't match who you are.
It's only when you have official ID that looks like you that he will allow you in.
In the same way, if you try to connect to a secure site and you don't have a certificate, the site doesn't even try to let you in. If you have a certificate, but it's not from a source your target site trusts, it doesn't let you in. If you have a certificate from a source the target trusts, but the information in the cert doesn't match the server DNS or IP address of the server presenting the cert, it doesn't let you in.
If you're using mutual authentication, then not only does the site you're hitting require you to present a valid cert, from a trusted cert signer, that correctly identifies your server, but you perform the same check - you check his ID to see if it's from a valid source and it looks like him.
It sounds like what you've got is the third issue - you're hitting a site, your certificate is a trusted signer, but the picture in the ID doesn't look like 'you'. The Subject Alt Name attribute on the certificate doesn't match the server name or IP address of your Service Manager server presenting the cert.