Skip to main content

Service certificates

ON THIS PAGE

Service certificates

Certificates are used for secure communication between two entities, such as a proxy and a browser, or two internal services.

There are two types of certificates in Qlik Sense, server certificates and trust zone certificates:

  • Server certificates are used to protect the communication between the Qlik Sense Proxy Service and the Qlik Sense Client running in your browser.
  • Trust zone certificates are used to protect the communication between Qlik Sense internal services.
Note: The rest of this description will focus on the trust zone certificates and will not cover the server certificates in any further detail.

Qlik Sense trust zone certificates and keys used for TLS with mutual authentication

The Qlik Sense trust zone is based on Transport Layer Security (TLS) with mutual authentication between the internal services.

To establish TLS with mutual authentication every service needs three certificates and two private keys:

Root certificate

The root certificate is used for verifying the certificate sent by the service you want to talk to.

Windows certificate store location: Local Computer > Trusted Root Certification Authority.

Service certificate and service private key

The service certificate and service private key are used for server authentication when your service acts as a server, that is, when another service calls an API in your service.

Windows certificate store location: Local Computer > Personal > Certificates.

Client certificate and client private key

The client certificate and client private key are used for client authentication when your service acts as a client, that is, when your service calls an API in another service.

Windows certificate store location: Local service user > Personal Certificates.

For services implemented in node.js, copies of the certificates reside in the following folder: %ProgramData%\Qlik\Sense\...\ExportedCertificates. In the following example, the service acts as a server.

The Client Service connects to the Server Service through HTTPS GET/api/. Both contain a Trust zone Root Certificate, a Trust zone Client Certificate, and the Trust zone Client private key.

Example where the service acts as a server

The common name of the server certificates will carry the hostname of the server, and it is used by the client to validate that the domain name of the server matches the information in the certificate. In the following example, the client service negotiates TLS with the server server.domain.com.

Two client services pass a Trust zone Server Certificate (Subject CN = server.domain.com) back and forth, via HTTPS GET server.domain.com/api/ and TLS Server hello.

Example where the client service negotiates TLS with the server

The common name of the server certificate is entered by the administrator during the node registration process in the QMC.

QlikServiceCluster certificate

The QlikServiceCluster certificate is used for distributing apps from Qlik Sense Enterprise on Windows to multi-cloud deployments.

Windows certificate store location: Local Computer > Personal > Certificates.

Manual configuration

Manual configuration is required when upgrading multi-node sites that are using or will use app distribution.

If upgrading from June 2020 (or earlier) to September 2020 (or later), read more here: FAQ: QlikServiceCluster certificate for distributing apps from Qlik Sense Enterprise on Windows.

Manual configuration is not required in the following cases:

  • New deployments of single-node or multi-node sites.
  • Upgrade of single-node sites.
  • Upgrade of multi-node sites that will not use app distribution.

Qlik Sense trust zone key management

Where do all the keys and certificates come from? All node keys and certificates are created by the central node. The keys are randomly generated and the corresponding certificates are signed by the trust zone Root private key. The trust zone Root private key is a third private key used by Qlik Sense. But this key is only used to issue new certificates, it is not involved in establishing mutual TLS. When the central node has generated certificates and keys for a new node, it will encrypt them with a randomly generated password and send them to a REST endpoint in the new node.

An administrator will have to enter the password on the new node so that the keys and certificates can be decrypted and installed on the new node. The password is entered on a web page that is only served on localhost. In practice, all of this happens in the node registration work flow in the QMC.

The certificate and key distribution procedure is described in the following example.

The central node creates a Trust zone Root Certificate, as well as a Trust zone Root Certificate, Trust zone Server Certificate, Trust zone Client Certificate, Trust zone Server private key, and Turst zone Client private key that are encrypted by a user's password. With the password, these are sent via HTTP POST/setup/certificate distribution to a new node.

Certificate and key distribution procedure

You use a certificate extension to identify the certificates as Qlik certificates, and the value of this extension defines the role of the certificate as either "root", "service", or "client".

Database encryption

Some fields in the database are encrypted at the application layer by Qlik Sense. This is typically fields that contain credentials, such as passwords for connections. Database fields are encrypted with a symmetric key that must be available on all Qlik Sense nodes and you use the trust zone server certificate to carry the key.

The database encryption algorithm and key are stored in the trust zone server certificate as extensions. Every extension is identified by an object identifier (OID), which indicates the contents of the extension:

  • 1.3.6.1.5.5.7.13.1: The symmetrical database key
  • 1.3.6.1.5.5.7.13.2: The algorithm of the database key

Both these fields are encrypted with the public key of the trust zone server certificate. This means that it is only the service that can decrypt them since it is the only entity that has access to the trust zone server private key.