Navigate and Windhcill using 3rd party Certificates

[BryanK]

I have been looking around everywhere for a understandable install guide to get windchill and navigate working. 

The problem I keep running into is that PTC kb has lots of different methods but none seem complete. If you use a combination of them it just seems to make the situation worse. Add to this that the configuration seems to change from build to build and after installing 8.5 something that worked in 1.8 or earlier doesn't seem to work anymore. 

This KB is the one that i have followed with the most success.

https://www.ptc.com/en/support/article?n=CS247505

But now I'm stuck (for 2 weeks) 

Authentication works. I can log in with windchill users.

The Thingworx-IntegrationRuntime just doesnt seem to work. 

I don't know if its the certificates, the CA certificate order or if its thingworx or apache?

Is there some sort of trouble shooting method to get to the root cause?

Is there "Picture" of how its all supposed to connect? 

Any help will be appreciated.

Thanks in advance.

[barko]

First, define Thingworx-IntegrationRuntime just doesnt seem to work, such as:

The service doesn’t start

The verticle doesn’t deploy

The wss connection fails

The route has failed error

Each would have a different troubleshooting path.

Assuming this is a certificate issue (most common issue), begin by collecting these logs:

ThingWorx applicationLog.log

IntegrationRuntime log

Windchill HTTPServer access.log

Windchill HTTPServer error.log

In <HTTPServer>/conf/httpd.conf file, find the LogLevel statement (usually in the vicinity of line 307) and set the value to debug (by default it is set to warn). The value debug must be lowercase. Save the file and restart HTTPServer. Reproduce the issue. If the request reaches HTTPServer, debug will identify which certificate causes an issue in the error.log and you can decide what to do once you know that.

If you are not reaching HTTPServer, its helpful to create a debug log for IntegrationRuntime. This gets more involved for Navigate 8.5 because the IntegrationRuntime-settings.json file is encrypted. To get a plain text IntegrationRuntime-settings.json file, you need to decrypt the file. Article CS310540 has steps for decryption. Alternatively, you can create an IntegrationRuntime-settings.json file from scratch in a text editor. An example is at ThingWorx 8 Help Center>ThingWorx Model Definition in Composer>Modeling>Integration connectors>Integration Connectors Prerequisites> Initial Setup of Integration Runtime Service for Integration Connectors. (http://support.ptc.com/help/thingworx_hc/thingworx_8_hc/en/#page/ThingWorx%2FHelp%2FComposer%2FIntegrationConnectors%2FInitialSetupofIntegrationRuntimeServiceforIntegrationConnectors.html)

With a readable IntegrationRuntime-settings.json file, stop the ThingWorx-IntegrationRuntime service and start IntegrationRuntime manually in a CMD shell using this command:

java -Djavax.net.debug=ALL -DconfigFile=<path>\integrationRuntime-settings.json -jar <path>\integration-runtime-<version>-<build>.jar > <path>\abcd.txt

Replace path, version and build with values that match your system. The debug log will be stored as the text file “abcd.txt”.

The debug log abcd.txt will log all the steps in the SSL handshake, and include the CertificateRequest from the server stating which Certificate Authorities will be acceptable, and the details of all the certificates provided in the truststore. This can be helpful chasing certificate issues.

The HTTPServer ca-bundle.crt is the truststore for some steps in the validation on the Windchill side. Some instructions for how to organize ca-bundle.crt are in Article C288818.

Troubleshooting an issue as complex as those in IntegrationRuntime takes experience. If you can, I recommend you file a case with Tech Support. The steps above were learned the hard way by looking at many cases, and they are not all-inclusive, just typical.

[BryanK]

Thanks for your detailed answer. This does help a lot. I suppose I could have been more detailed with "it doesent work".

Mostly the problem comes in at "The route has failed error" flavor.

There are different "Software caused connection abort: recv failed" etc etc depending on the black hole that I go down. 

I have been looking at the 4 log files you suggested and but not with debug enabled so that will help a lot. 
I think my challenge is understanding the certificates, keystore, truststore jssecacerts. What goes where and why. 

Thanks For the Help. If i find anything of use to share I will add it to this.

[barko]

The  "Software caused connection abort: recv failed" is an unhelpful message, so you should skip over that and look to see what has caused the connection to close. Most often the validation of the ThingWorx certificate failed, and that caused the system to close the connection. Then the system tries to catch up on sending messages to the client (ThingWorx) that it has closed the connection, but the messages cannot be received because the connection is already closed. So you get a bunch of messages about not being able to deliver the message. They translate to “something didn’t work” – we already knew that.

With LogLevel debug set, the error.log may describe which certificate failed (almost always the ThingWorx cert) and may include an error code or message that describes why it failed. Aside from an incorrectly configured certificate (usually incomplete extensions) the most frequent causes are self-signed certificates and certificates for systems that use an alias. You can add the alias to the Subject Alternative Name extension, but solving issues with self-signed certs is a trial and error process.