Custom CA root certificate for Qlik's internal communication

[vegard_bakke]

We got a nice challenge here from a client. They have a strict security policy, and do not allow any self-signed certificates. Therefore, Qlik Sense' self-signed CA certificate does not meet the requirement, and gets deleted by a security policy.

(Note, we are not talking about the HTTPS certificate here, and pasting the thumbprint info QMC.)

Apparently some other companies have done this successfully with Qlik Sense. (After all, it's just certificates.) But one needs to get all attributes that are referred to by the Qlik code right.

(For example:  Subject: QlikClient, etc)

Does anyone know what the requirements for creating proper certificates might be?

And what references we might need to change?

(All I find is referring to changing the https certificates. So, I get overwhelmed with false positives in my searches.)

Crossing my fingers,

Vegard 

[vegard_bakke]

Could this API be of any use?
https://help.qlik.com/en-US/sense-developer/November2020/Subsystems/RepositoryServiceAPI/Content/Sen...

The documentation is very slim. Hard to tell what exactly is can or can't do.

[vegard_bakke · Accepted solution]

If anyone out there is in the same situation, here is what I got from Qlik Support. 
Remember, you are probably on your own if you decide to do this. It is not supported by Qlik.

(Not tried it myself.)

Creds to Damien who managed to dig up this information:

- - - - - -

[04.03 14.01] Damien Villaret
There is no supported way to do it, but as you said, I've heard of some other customers doing it successfully.
Let me see if I can find some information on that.

​
[04.03 14.27] Damien Villaret
So, this is how Qlik Sense fetches the certificates:
Sense specific certificates are identified by QS services via so called certificate extension. There are three custom Sense specific certificate extensions, all identified by a unique extension key, in the form of an OID (Object Identifier):

• 1.3.6.1.5.5.7.13.1: The symmetrical database key, only exists on the service certificate, encrypted with the private key of the service certificate
• 1.3.6.1.5.5.7.13.2: The algorithm of the database key, also only exists on the service certificate and encrypted likewise
• 1.3.6.1.5.5.7.13.3: Identifies a certificate as a Sense certificate and the value of this extension tells the role of the certificate: either "root", "service" or "client", it is unencrypted and exist on all certificates

If there is more than one root certificate that matches our OID of 1.3.6.1.5.5.7.13.3 , system will refuse to start due to security reasons. Repository logs will log "Duplicate or invalid root certificates are not allowed".
name of the certificate does not matter

You can see yourself in the mmc console what value you would need to identify the certificate as root, service or client

Unfortunately, I couldn't find any "how-to" on how other customers generated theirs, but if you generate your certificates with the above extensions, you should be able to replace the default ones.