Skip to content

High Availability Installation🔗



  • RHEL 8 VMs for AQtive Guard processes (web and worker).
    • Optional: Certificate and private key for internal TLS.
  • Load balancer to distribute traffic across AQtive Guard web VMs.
    • URLs of AQtive Guard web VMs.
    • Optional: CA certificate to authenticate the AQtive Guard Analyzer Platform web VMs with TLS.
  • Redis 5+
    • URL (containing credentials) to connect to the service.
  • PostgreSQL 12+
    • URL (containing credentials) to connect to the database.
    • Optional: CA certificate to authenticate the server with TLS.
  • Object Storage (S3-compatible)
    • URL to connect to the object storage service.
    • Bucket name.
    • Credentials (Access key ID and secret access key).
    • Optional: CA certificate to authenticate the server with TLS.
    • Known compatible implementations: AWS S3, MinIO, NetApp StorageGRID.

Object Storage CORS setup🔗

In order to upload traces using the AQtive Guard web interface, the Object Storage needs to be configured to allow CORS requests from the AQtive Guard hostname.

In addition, all the potential client IPs (browsers, API clients…), as well as all the machines on which AQtive Guard will run, need to be allowed to make POST requests (or PUT if STORAGE_USE_PUT is enabled) to upload to the configured bucket.

For example, for AWS S3, the configuration would be the following:

    "AllowedHeaders": ["*"],
    "AllowedMethods": ["POST"],
    "AllowedOrigins": [""],
    "ExposeHeaders": []

Software packages🔗

The following files are needed (where <version> is your version of AQtive Guard, which must be the same for all packages to be installed):

  • analyzer.cs-license (if you need to install or renew the license)
  • cryptosense-analyzer-web-<version>.rpm
  • cryptosense-analyzer-worker-<version>.rpm

Installation or upgrade🔗

  • If necessary, make a backup of the database and object storage service.
  • Disable HTTP access to the AQtive Guard web processes (e.g. maintenance mode) and wait for worker processes to be idle.
  • Install the AQtive Guard web and AQtive Guard worker packages on every VM:
    • For web VMs: yum install cryptosense-analyzer-web-<version>.rpm
    • For worker VMs: yum install cryptosense-analyzer-worker-<version>.rpm
  • If necessary, create or update the configuration files (see next section).
    • Important: if you intend to use a custom schema name, it needs to be configured ahead of the first startup of AQtive Guard! See the configuration section for the exact keys to set.
  • Choose any of the VMs that were just setup and connect to it.
    • If this is a new installation of AQtive Guard, run cs database init
    • Otherwise, run cs database migrate
  • Restart all AQtive Guard workers and web clients by running cs restart on each VM.
  • Re-enable access HTTP access to AQtive Guard web processes.


On each AQtive Guard VM, the configuration is stored at /etc/cryptosense-analyzer/config.

Each AQtive Guard VM must have the same configuration, with the following parameters:

  • REDIS_URL: URL of the Redis service. Use rediss://<hostname> if the Redis connection is secured by TLS, or redis://<hostname> otherwise. Currently, no custom server certificate path can be specified.
  • DATABASE_URL: URL of the database, including credentials. See dedicated section for further details.
  • DATABASE_SCHEMA: (optional) Set to name of the postgres schema to be used.
  • S3_ENDPOINT: URL of the object storage service.
  • S3_TRACE_AWS_ACCESS_KEY_ID: Access key ID used by AQtive Guard. Note: this doesn’t have to refer to a key in AWS, other providers are supported.
  • S3_TRACE_AWS_SECRET_ACCESS_KEY: Secret access key used by AQtive Guard. Note: this doesn’t have to refer to a key in AWS, other providers are supported.
  • S3_TRACE_BUCKET: Name of the bucket for AQtive Guard to use.
  • SECRET_KEY: Secret key used to sign and authenticate session cookies.
    • Suggestion: generate 32 bytes and use their hex-encoding as the key (with Python 3, you could use python -c 'import secrets; print(secrets.token_hex(nbytes=32)) to get a new key).
    • Key rotation: overwrite the configured key and restart web processes on all VMs (cs restart). This will invalidate all current sessions.

A full reference of AQtive Guard configuration keys can be found here.

Configure Database Connection🔗

The database connection is configured using a single URL containing all the different parameters required for a secure connection. The format should be the following:


Adding parameters is optional. The following parameters are supported:

  • sslmode : Define the level of SSL verification. The following values are supported:
    • disable : No SSL
    • prefer : Try to establish a SSL connection, but if it fails, fall back to unsecured connections (default).
    • require : Require SSL, but don’t verify certificates.
    • verify-ca : Require SSL and verify the certificate.
  • sslcert : Path to the client certificate.
  • sslkey : Path to the file containing the key used with the client certificate.
  • sslrootcert : Path to the file containing the Certificate Authority used by the server.

By default, the public schema will be used. If a custom schema should be used instead, set the DATABASE_SCHEMA key (see previous section).

For more extensive option documentation, refer to the official JDBC postgres documentation.

License activation🔗

  • Upload the provided analyzer.cs-license file to /etc/cryptosense-analyzer/analyzer.cs-license on one of the AQtive Guard VMs.
  • Run cs license synchronize on that VM.

If no error was reported, your new license is now in effect. You can confirm that in the AQtive Guard web interface by checking the date on the trace upload page of any project you have access to.

For instructions on sending us logs for troubleshooting, refer to Sending error logs.