For me it doesn't work. I installed certificates like described in this article but still same info: "The Installer was unable to find required root certificates". I am trying to install this version: KEPServerEX6-6.15.132.0.exe. Where could be a problem?
My name is Chris and I'm the Kepware Community Agent. Kepware has had a lot of success resolving this issue through the use of the following knowledge base article (particularly the KEPServerEX 6.8 / TKS 6.8 and all newer releases instructions) which JM_10724634 may have referenced:
If the article instructions do not resolve the install issue, I recommend opening a support ticket with the Kepware Support Team to see if a remote session could be facilitated to assist with the resolution. Here is a link to the My Kepware page where a support ticket can be opened:
Thank you for your reply. But as I mentioned in my post and reacted to previous post. Your solution with installing root certificated DOESN'T work. So any other solution how to instal KEPServerEX6-6.15.132.0.exe ? I can provide you remote session, so you can try install it on your own. Thanks, Jiri
Greetings,
as per title, I am unable to connect a Kepware server to a cloud instance of TWx. I've been able to connect multiple other servers, so the issue must be on this machine.
I configured the Project->Thingworx tab like I always do, after creating an industrial connection via ManApps and following the relative instructions, but I always get this error:
The machine which is running Kepware is still running Windows 7 and in order to install and run Kewpare I had to follow this article (CS321323) to install the required certificates, could my issue be related to this?
With the help of the support we've got to the cause of the problem, which was... a firewall.
I feel kinda dumb as I didn't bother to check before, but my colleagues assured me that the device wasn't blocked by any sort of firewall and it clearly wasn't the case.
Thank you all for the support and sorry for having wasted your time with my (non)issue.
The Thingworx instance is in the cloud, does it have a static IP address?
I don't know if TWx is running on SSL, but all the other Kepwares I configured use port 443 and had no issues and are currently communicating with the platform.
Hi @anarwal,
This Cloud instance is running on https (port 443) so you will need to configure the ThingWorx certificate in KEPServer to allow for the connection. Have you tried downloading the root certificate from ThingWorx and setting it up in the KEPServerEX Settings as per Configuring KEPServerEX/ThingWorx Industrial Connectivity to connect to SSL/TLS enabled ThingWorx Platform ?
No, I didn't try. I will try as soon as I can reach the device (the plant is now in production, I'll have to wait its next scheduled maintenance later this week) and let you know.
I did download some certificates in order to install Kepware (see my original post), are those sufficient or do I need to download the ones suggested in the article you posted?
The article you mentioned seems specific to the KEPServerEX installation and unrelated to ThingWorx and I believe that importing the ThingWorx root certificate into the KEPServerEX truststore is still required to allow for a connection between ThingWorx and KEPServerEX.
I've tried following the article you linked, I downloaded and imported the certificate in Kepware, but unfortunately I'm still getting the "could not establish a websocket connection".
Any other ideas? Could it be related to the Windows 7 version on the machine?
Do you have multiple Kepware servers connecting to ThingWorx with the same Industrial Connection Thing ?
Can you create another Industrial Connection Thing in ThingWorx and try again to connect with Kepware.
I tried both of those settings last week, I get "danieli-dev.cloud.thingworx.com:8080/Thingworx/WS, error = could not initialize a secure socket connection." if I use the port 8080 with its relative settings and "danieli-dev.cloud.thingworx.com:443/Thingworx/WS, error = could not establish a websocket connection." if I use the 443 port with its relative settings.
I have a scheduled remote support session tomorrow with PTC Support, I'll let you know if we solve this issue.
Hello, I am trying to write my first OPC client application. My server is KepserverEX 6 and I am receiving the error of the topic when trying to connect to the server. The certificate is located in folder CertificateStores\App\private inside the project folder and was issued by Kepserver.
In the other hand, the endpoint of my server is configured without encryption (security policy: none). I only use user and password because server and client are both in a isolated network without internet access. Is really needed to have a certificate in my scenario? could I connect to my server without certicate?
Actually I have a certificate that I get from Kepserver connecting from OPC Watch with encryption enable. Kepserver has returned a certificate to the client in both pfx and der formats, and these are the files that I have copied to my .net client. However, my .net client still says that certificate is not found, despite there are two files in the StorePath.
I have modified the code following your comments and the reference client, Randy. CheckApplicationInstanceCertificate is returning true. And I have set AutoAcceptUntrustedCertificates to "true" in my client.Config.xml.
Thank you Randy, this works but a new error is been raised now: Certificate is not trusted. I am comparing my code with the ConsoleReferenceClient, but I realized that this error is triggering in the Reference Client also. I set in the Reference Client my serverurl, username and password, and this is the output:
It seems that the client does not accept the server certificate, probably because it is self-signed. I tried installing the server certificate in my trusted root certification authorities certificate store, but it didn't solve the problem. I also tried to set these couple of settings in config.xml
I think there are two sides, right? Server must trust the client and client must trust the server. According the error message of my previous post, client is rejecting the server certificate. How can I make client trust the server's self-signed certificate?
There is no problem in server side. Client certificates appear in the configuration manager. Just clicking on "trust" the client is able to comunicate. I have other clients working: OPC Watch and Wonderware Historian.
Now I don't know which certificate the error is referring to, the client's or the server's. The subject showed in the error is about the server certificate, so I am assuming the client does not trust the server's certificate. I've been stuck at this point for several days.
When your device or other client attempts to connect to AWS IoT Core, the AWS IoT Core server will send an X.509 certificate that your device uses to authenticate the server. Authentication takes place at the TLS layer through validation of the X.509 certificate chain. This is the same method used by your browser when you visit an HTTPS URL. If you want to use certificates from your own certificate authority, see Manage your CA certificates.
When your devices or other clients establish a TLS connection to an AWS IoT Core endpoint, AWS IoT Core presents a certificate chain that the devices use to verify that they're communicating with AWS IoT Core and not another server impersonating AWS IoT Core. The chain that is presented depends on a combination of the type of endpoint the device is connecting to and the cipher suite that the client and AWS IoT Core negotiated during the TLS handshake.
AWS IoT Core supports two different data endpoint types, iot:Data and iot:Data-ATS. iot:Data endpoints present a certificate signed by the VeriSign Class 3 Public Primary G5 root CA certificate. iot:Data-ATS endpoints present a server certificate signed by an Amazon Trust Services CA.
Certificates presented by ATS endpoints are cross signed by Starfield. Some TLS client implementations require validation of the root of trust and require that the Starfield CA certificates are installed in the client's trust stores.
Using a method of certificate pinning that hashes the whole certificate (including the issuer name, and so on) is not recommended because this will cause certificate verification to fail because the ATS certificates we provide are cross signed by Starfield and have a different issuer name.
For backward-compatibility, AWS IoT Core still supports Symantec endpoints. For more information, see How AWS IoT Core is Helping Customers Navigate the Upcoming Distrust of Symantec Certificate Authorities. Devices operating on ATS endpoints are fully interoperable with devices operating on Symantec endpoints in the same account and do not require any re-registration.
To see your iot:Data-ATS endpoint in the AWS IoT Core console, choose Settings. The console displays only the iot:Data-ATS endpoint. By default, the describe-endpoint command displays the iot:Data endpoint for backward compatibility. To see the iot:Data-ATS endpoint, specify the --endpointType parameter, as in the previous example.
Depending on which type of data endpoint you are using and which cipher suite you have negotiated, AWS IoT Core server authentication certificates are signed by one of the following root CA certificates:
These certificates are all cross-signed by the Starfield Root CA Certificate. All new AWS IoT Core regions, beginning with the May 9, 2018 launch of AWS IoT Core in the Asia Pacific (Mumbai) Region, serve only ATS certificates.
4a15465005