Hi Developers,
I'm using GetJSON content loader function available in TWX. Its throwing the below given error:
“Error:JavaException: javax.net.ssl.SSLPeerUnverifiedException: Host name 'xxx.com' does not match the certificate subject provided by the peer (CN=xxx, OU=xxx, O=xxx, L=xxx, ST=xxx, C=xxx)”
"ignoreSSLErrors" in the params of GetJSON service also doesn't seem to affect the result.
I tried the same call from postman and only when I turned off the “SSL Certificate Verification” in its settings I was able to get the json output.
So how can i pass the insecure tag along with the REST service from Thingworx or how to turn off the SSL verification setting on the platform. Also how to pass the request body using the GetJSON service.
Thanks and Regards,
Saran
Solved! Go to Solution.
I see this issue is due to mismatch of server hostname with CN of certificate installed at local keystore file.
On this I went on to search over internet to find if there is a way if we can edit/change the CN of cert installed at local keystore but I think we cannot change the CN once an SSL cert is issued and hence we need to setup a new SSL cert matching the names and go through the issue/installation process again.
Meanwhile are you able to locate what is the exact mismatch between the names ? Below is the command to know the cert’s information – follow below 2 links that might help
keytool -list -v -keystore keystore_name
https://knowledge.digicert.com/solution/SO28992.html
https://knowledge.digicert.com/solution/SO15739.html
further I found this link very informative in understanding the reasons for mismatch between the hostnames/CN – see if this helps in determining the cause
Looks like similar issue was reported in JIRA TW-38279 scheduled to be fixed in ThingWorx 8.4.
For now to resolve your error add the server or CA certificate to Java cacerts keystore. If you are not sure how to do this you can follow instructions in this article https://www.ptc.com/en/support/article?n=CS282851
Hi @MarekP.Nowaczyk,
Thanks for your reply.
I'll certainly try out your fix. I hope this article is applicable for TWX 8.3 ( which is we're facing the issue) since it was mentioned that it applies to ThingWorx Platform 7.4 F000.
.
Regards,
Saran
Hi @MarekP.Nowaczyk,
I have imported the certificate into Java keystore and I validated the Thumbprint in the keystore list. Then I rebooted the server and tested the service. But the issue still persists.
Is there any other reason why it could have failed?
Regards,
Saran
Hi @SaranKarthick.
If you click the security icon next to the url, does the common name match the one you are entering in the url? If you are testing locally from the ThingWorx server and using localhost, you will receive this error since localhost doesn't match the domain on the certificate.
We would need more information regarding the circumstances under which you are receiving this error to determine further.
Regards.
--Sharon
Hi @slangley,
Based on your observation i checked the error message and it seems that the hostname doesn't match the CN property of the certificate. So if i change the common name of the certificate in my local keystore to match the hostname it should work i think. Is my assumption correct? If so how can i change that?
Also i tested the same content loader function for another "Not Secure" site and it worked as expected. I don't have a certificate for this site in my keystore and yet it was still able to hit the site.
Regards,
Saran
I see this issue is due to mismatch of server hostname with CN of certificate installed at local keystore file.
On this I went on to search over internet to find if there is a way if we can edit/change the CN of cert installed at local keystore but I think we cannot change the CN once an SSL cert is issued and hence we need to setup a new SSL cert matching the names and go through the issue/installation process again.
Meanwhile are you able to locate what is the exact mismatch between the names ? Below is the command to know the cert’s information – follow below 2 links that might help
keytool -list -v -keystore keystore_name
https://knowledge.digicert.com/solution/SO28992.html
https://knowledge.digicert.com/solution/SO15739.html
further I found this link very informative in understanding the reasons for mismatch between the hostnames/CN – see if this helps in determining the cause
Hi @SaranKarthick.
If one of the previous responses helped you to solve your problem, please mark the appropriate one as the Accepted Solution for the benefit of others with the same issue.
Regards.
--Sharon
Hi @slangley,
We're still validating the fix you have suggested. Once completed i'll update this topic correspondingly.
Regards,
Saran
Hi @SaranKarthick.
I'm just following up to see if you have resolved your issue. If so, please mark the appropriate reply as the Accepted Solution. Or if different from one of the solutions provided, please post the solution and mark your response as the Accepted Solution.
Regards.
--Sharon