Kepware REST Certificates, ThingWorx HTTPS Communication, and Java Truststore Behavior

Hi Experts,

I'm looking for guidance from Kepware, ThingWorx, and security experts regarding certificate handling between ThingWorx and Kepware, particularly around REST-based integrations and Java truststore behavior.

Background

Using Kepware IoT gateway I am downloading MES data.During troubleshooting of a Work Order (WO) download issue between ThingWorx and Kepware, observed that:

• In one environment, WO downloads failed and the issue appeared to be related to an expired Kepware REST server certificate.
• After addressing the certificate issue, WO downloads resumed successfully.
• However, in other environments, the Kepware REST server certificates were also expired, yet ThingWorx-to-Kepware communication and WO downloads continued to function normally.

Initial investigation suggested that the difference may be related to the Java truststore (cacerts) contents on the ThingWorx servers. In some environments, the Kepware certificate appears to be trusted/imported into the JVM truststore, while in others it is not.

This has raised several questions about how certificates are actually being used in the integration architecture.

Areas Where We Need Clarification

1. Role of Kepware REST Certificates

• What specific role does the Kepware REST server certificate play in ThingWorx ↔ Kepware communication?
• Which functions depend on the REST endpoint certificate being trusted?
• Why might an expired or untrusted certificate impact Work Order downloads while other communications continue to work?
• Are IoT Gateway communications independent of the Kepware REST certificate?

2. Java Truststore (cacerts) Behavior

• How does ThingWorx (JVM) perform certificate validation when making HTTPS calls to Kepware?
• Under what circumstances can communication continue despite an endpoint certificate being expired?
• What is the expected behavior when:
  • A certificate is expired but exists in the truststore?
  • A certificate is not present in the truststore?
  • A CA certificate is trusted versus a self-signed certificate?

3. Environment-to-Environment Differences

Assuming the following are identical:

• ThingWorx application configuration
• Kepware configuration
• Tomcat SSL configuration

Could differences in the Java truststore alone explain different behaviors across sites?

Are there any additional configuration locations that should be reviewed (ThingWorx security settings, JVM options, Kepware settings, custom connectors, etc.)?

4. Recommended Long-Term Strategy

From a best-practice perspective, what is the recommended approach for production environments?

Specifically:

• Should all Kepware REST certificates be renewed before expiry?
• Is it recommended to move away from self-signed certificates and use CA-signed certificates?
• Should organizations trust/import the issuing CA certificate rather than importing individual server certificates?
• Are there documented PTC/Kepware recommendations for certificate lifecycle management across multiple sites?

Goal

We are trying to develop a clear understanding of:

1. The relationship between:

   • Kepware REST certificates
   • IoT Gateway communications
   • ThingWorx HTTPS integrations
   • Java truststore validation

2. Why seemingly identical environments can behave differently when certificates expire.

3. The most robust and supportable long-term solution to prevent future communication issues related to certificate management.

Any architectural explanations, deployment experience, troubleshooting guidance, or references to official documentation would be greatly appreciated.

Thank you in advance for your insights.