Qlik Sense has its own PKI... this is bad.

[Anonymous]

I got called in to help troubleshoot our new installation of Qlik Sense (QS) and found that it has its own Root Certificate Authority (CA) on the central server. The private key is just sitting there. Any QS installation adds this Root CA to the Windows Certificates Store - Trusted Root CAs. This means that any Qlik server will trust a certificate issued by that Root CA for any purpose. The poor key protection means that anyone with admin rights can export the private key and setup a duplicate CA, and start signing whatever they want. Qlik servers will then trust connections issued from that rogue CA.

How did this happen? I appreciate that the application at least uses TLS; this is good, but this implementation is completely broken. Rather than securing QS, it actually introduces a man-in-the-middle vulnerability, not just to QS, but to any service that any QS server accesses using TLS.

You need to change QS to either use self-signed certificates or integrate with an organization's own PKI infrastructure. Obviously, PKI integration would be better, but even self-signed certificates would be better than this broken application-specific PKI implementation.

[Gysbert_Wassenaar]

The poor key protection means that anyone with admin rights can export the private key and setup a duplicate CA, and start signing whatever they want.

So, an admin with access to your master QRS server can create other Qlik Sense servers that can act as a mitm for your other Qlik Sense servers? Do you have any idea what an admin of the master QRS can do anyway to compromise your Qlik Sense environment? Abusing the private key sounds like a rather convoluted way to go about that. Besides that, what's stopping you from moving the private key to a 'secure' location once your Qlik Sense infrastructure has been set up? As long as no new certificates need to be generated the private key is not necessary on the system.

[Anonymous]

Of course QS admins can get to all the Qlik data. That's not the issue.

The issue is that all the Qlik servers trust that CA and its private key is stored online on the central server. If that server is compromised and the organization doesn't know it, all TLS applications on any Qlik servers (not just QS) can be monitored. Anything the OS does using TLS can be monitored if you have that private key, including communications with non-Qlik servers. All you would have to do is sign a certificate for the other server's name. While that may sound convoluted, it's exactly the kind of passive monitoring that a PKI is designed to prevent.

You could delete or move the key, but was you said, you won't be able to add any new servers, to say nothing of proper key management and hygiene for a PKI. I don't see any support article about that either, or the exact process used to create the node certificates. Would Qlik see that its CA was broken and just generate and distribute certificates for another PKI?