PKI and encryption

In the PKI and encryption section, SAFEQ Cloud server provides several advanced options to configure public key infrastructure and data encryption at rest.

Public key infrastructure settings

For internal communication (the one used to send messages between servers and SAFEQ Cloud clients), SAFEQ Cloud uses either the built-in certificates or the customer-provided certificates.

Customer-provided trusted CA certificates are currently supported only by on-premise primary server installations.

If the built-in certificates (default) are used, you must authorize each server or SAFEQ Cloud client connection from the corresponding SAFEQ Cloud Web UI section. You can temporarily disable the authorization by selecting the Automatically trust new clients/servers option.

If the trusted CA certificates option is selected, you must configure the account for custom PKI. We assume that you are familiar with the PKI infrastructure, and it is deployed and provisioned on end-user workstations:

Secondary servers/gateways must be installed in unattended mode with a custom keychain configured in the configuration file (see Installing SAFEQ Cloud unattended/silently for details)
SAFEQ Cloud clients operating in local storage mode must be installed with the enabled option to use the system (Windows) certificate store.
Root and intermediate CA certificates for the custom PKI must be uploaded to this account via the Web UI under the CERTIFICATES / Trusted CA certificates section.

Optionally, you can enable OCSP revocation checks for the certificates and configure a custom OCSP URL if the provisioned certificates do not contain it.

You can configure the following settings:

Certificate policy for internal communication – This option defines which certificates will be used in the internal SAFEQ Cloud communication between servers and SAFEQ Cloud clients.
Automatically trust new clients/servers – Only applies to built-in certificate policy. When disabled, any new SAFEQ Cloud client/server connections will require manual authorization by the administrator.
Enable OCSP revocation check – Only visible when trusted CA certificates are used. Enables certificate revocation check via OCSP protocol.
Custom OCSP URL – Allows specifying custom URL for OCSP service if the provisioned certificates do not contain it.

Data encryption at rest

SAFEQ Cloud server provides a possibility to transparently encrypt stored documents. When encryption is enabled, the documents in the persistent storage will be encrypted with the randomly generated account key. This applies to primary server, gateways, and SAFEQ Cloud clients.
Keys are rotated automatically and are expired after the specified time. Rotation means that a new key is generated after each “key rotation period” (8 hours by default), which will be used to encrypt new documents. When a particular key is expired (key retention default is 168 hours), it is not possible to decrypt or recover the document which was encrypted with it. When the document is sent to the printer it will be decrypted automatically.

Encryption keys are stored in the central database and are exchanged via the internal secure channel between the trusted servers and/or SAFEQ Cloud clients. Encryption keys are account-specific, so the documents are encrypted per Vendor or Customer account. When the document is encrypted, the account encryption key is combined with the local key specific to a server or SAFEQ Cloud client. The document can only be decrypted on this particular server or client.

You can configure the following settings:

Enable data encryption at rest – enable data encryption for all servers/clients in this particular account. This will only apply to new documents. Existing ones will remain unencrypted.
Encryption key retention – the number of hours after which the key expires. The default is 168 (7 days).
Encryption key rotation – the number of hours after which the new key will be generated. The default is 8.

Token lifetime settings

Here you can set lifetimes for device and user access and refresh tokens respectively. Note that the lifetime for access tokens is measured in minutes, while for refresh tokens it is measured in days.