Integrating QRS API with signed certificate while still retaining Hub access?

[Jim]

I'm working on integrating the QRS API in our application. I've gotten the basics down and can call /app and /task without a problem. In Postman, I can do it by disabling SSL verification. Replicating that in our application wasn't too much trouble until I ran into the certificate verficiation issue. I'd like to avoid an insecure connection and use the signed certificate we already have so the REST call can do its work without a problem.

The problem with that is it returns "PKIX path building failed" or "No trusted certificate found". I managed to solve this by using "add sslcert ipport=xx.xx.xx.xx:4242 certhash=abcd appid={1234}"  and having both the Qlik self-signed cert + our signed cert on the same port. Postman works with SSL verfication on after t hat. Unfortunately, this causes the Hub to be inaccessible with "Error: unable to get local issuer certificate" when it tries to call /qrs/license... 

I've tried "add sslcert ipport=127.0.0.1:4242...."  or localhost. I've tried accessing the hub by using localhost/hub and 127.0.0.1/hub but all the same result. The only solution is to remove the certificate from that port so only the Qlik one remains.

Is it possible to call QRS with a signed certificate? Could I force QRS api to listen to more than 1 or a different port? Or will I have to make that custom Java action so I can ping QRS without SSL verfication?

[Levi_Turner]

@Jim : Short answer: no. You cannot swap the internal certificates to one validated from an internal or external PKI.

Longer answer: This shouldn't be an issue for an integration. I am not a Java guy in the least*, but insofar as you are on a modern version of Qlik Sense, you should be able to bundle the client and root into a JKS which allows for chain validation to the root. The reason why I qualify the modern bit is that on modern JDK versions (I worked with a customer who hit this going from JDK 1.7 to 1.8), the root needs to have a specific attribute on the certificate which earlier builds of Qlik Sense did not add. See https://support.qlik.com/articles/000075724 for a pointer.

From my notes from the engagement I had with the customer, the except they hit was something like:

IdatActionHelper:getQlikSenseTicket:Directory:IOException:javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: sun.security.validator.ValidatorException: TrustAnchor with subject "CN=<ServerName>-CA" is not a CA certificate ]

If that's the case, then ideally you'd be able to upgrade to either Feb2020 or April2020 to have the installer resolve this issue. From there, re-export the root and client, bundle into the Java side and you should be good to go.

* So I cannot answer Java specific techniques or modules or approaches

[Jim · Accepted solution]

Solved! I added the root.pem/root.cer file as the Authority and that validates the certificate for our server. I've completed the integration for some basic calls such as starting/stopping tasks and retrieving app statuses.

Thanks for mentioning the 1.7 to 1.8 thing. We run java 1.8 (Adopt Open JDK 😎 so we'll have no transition issue if all goes well.