> For the complete documentation index, see [llms.txt](https://docs.collibra.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.collibra.com/data-quality-self-hosted/security-configuration/setting-up-ssl-https.md).

# Setting up SSL (HTTPS)

By default, Collibra DQ has plain HTTP enabled for testing. When you are ready to enable SSL for the web application, you can set the following environment variables in the **owl-env.sh** file for Standalone deployments or the **Web ConfigMap** for Cloud Native to enable HTTPS.

{% hint style="info" %}
The URL you are using must include a fully qualified domain name.
{% endhint %}

The settings listed at the bottom of this page enable secure HTTPS and allow you to point to your certificate keystore and credentials. A restart of the web application is required.

{% hint style="warning" %}
You must restart the web application from the bin directory: `./owlmanage.sh restart=owlweb` (Standalone) or Web Pod (Cloud Native).
{% endhint %}

## Supported keystore formats

Data Quality & Observability (self-hosted) supports the following keystore formats:

* Java KeyStore (JKS): The default keystore format for Java, which stores private keys and certificates in a proprietary format.
* PKCS12: A more universal keystore format that is widely supported across different systems and applications, and is often used for interoperability with non-Java applications.

## Create a Java KeyStore

Before starting the SSL setup, you need to generate a Java KeyStore. A Java KeyStore stores private keys and certificates.

You can use a `keytool` JDK utility to generate a keystore, which helps to manage private and public keys and associated certificates. With this utility, you can administer your own public or private key pairs and associated certificates. The keystore allows you to protect your private keys with a password.

All certificates within the keystore are associated with a unique alias that gets used as a pointer to perform keytool operations, such as import, export, delete, and/or change certificates and keys.

{% hint style="info" %}
Implementation is dependent upon your specific architecture.
{% endhint %}

The following example is a command that creates a keystore.

```
keytool -genkeypair -alias mykey -keyalg RSA -keysize 2048 -keystore mykeystore.jks -dname "CN=Your Name, OU=Your Org Unit, O=Your Org, L=Your City, ST=Your State, C=Your Country" -validity 365
```

The following table breaks down the various options in the above command.

<table><thead><tr><th width="152">Options</th><th>Description</th></tr></thead><tbody><tr><td><code>-alias</code></td><td>The alias name for the key entry.</td></tr><tr><td><code>-keyalg</code></td><td>The algorithm to use for the key pair. In this example, the algorithm in use is RSA.</td></tr><tr><td><code>-keysize</code></td><td>The key size in bits, usually 2048.</td></tr><tr><td><code>-keystore</code></td><td>The file name of the keystore. In this example, the command generates a keystore called <strong>mykestore.jks</strong> with a single, password-protected key entry.</td></tr><tr><td><code>-dname</code></td><td>The distinguished name for the certificate.</td></tr><tr><td><code>-validity</code></td><td>The validity period for the certificate in days.</td></tr></tbody></table>

## (Optional) Generate a Certificate Signing Request from the keystore

If you need to obtain a certificate signed by a Certificate Authority (CA), generate a Certificate Signing Request (CSR) using a command similar to the following example:

```
keytool -certreq -alias mykey -keystore mykeystore.jks -file myrequest.csr
```

{% hint style="info" %}
When prompted, enter the alias name and password.
{% endhint %}

You can send myrequest.csr to a CA to get it signed.

### Import a signed certificate

After a CA signs the certificate, you can import it into the keystore using a command like the following:

```
keytool -importcert -alias mykey -keystore mykeystore.jks -file mycert.cer
```

For more information on importing certificates in cloud native deployments, go to [Add CA certificates to the java keystore](/data-quality-self-hosted/installation/installing-data-quality-observability-self-hosted-on-self-hosted-kubernetes/deploy-on-self-hosted-kubernetes/add-ca-certificates-to-the-java-keystore.md).

### Verify the keystore

After you import the signed certificates, you can verify the contents of the keystore with the following command:

```
keytool -list -v -keystore mykeystore.jks
```

This command shows all the certificates and key pairs within the keystore.

## Using a keystore or truststore

Keystores and truststores can be the same file, but they serve different purposes in Java's security infrastructure.

### Purpose of a truststore

When an application (client or server) establishes a secure connection, it needs to verify the identity of the other party. This is done by checking the certificate of the other party against a list of trusted certificates stored in the truststore. If the CA-signed certificate is trusted and present in the truststore, the connection is considered secure.

### Purpose of a keystore

When a server hosts a secure service, for example, HTTPS, it uses a keystore to house its private key and the associated public certificate. This certificate is presented to clients during the SSL/TLS handshake to prove the server's identity. In some cases, such as mutual auth, clients also need to authenticate themselves to the server. A client-side keystore can store the client's private key and certificate for this purpose.

### Configure a keystore and truststore in Collibra DQ

In Data Quality & Observability (self-hosted), you typically specify the keystore and truststore with the environment variable `EXTRA_JVM_OPTIONS`:

```
-Djavax.net.ssl.keyStore=path/to/keystore.jks -Djavax.net.ssl.keyStorePassword=keystorepassword -Djavax.net.ssl.trustStore=path/to/truststore.jks -Djavax.net.ssl.trustStorePassword=truststorepassword
```

If you use the same file for both, set the following options:

```
-Djavax.net.ssl.keyStore=path/to/store.jks -Djavax.net.ssl.keyStorePassword=password -Djavax.net.ssl.trustStore=path/to/store.jks -Djavax.net.ssl.trustStorePassword=password
```

Depending on your deployment type, the location where this configuration is set differs. In Cloud Native deployments, this is set in the ConfigMap. In Standalone deployments, this is set in the owl-env.sh file.

## Generate a PCKS12 file using the public and private key from CA

You will receive a bundle from CA containing your public and private key, which you can then export by using a command such as the following.

```
export SERVER_SSL_KEY_STORE=<path to your keystore>
```

You can call Collibra DQ's built-in 256-bit encryption for the SERVER\_SSL\_KEY\_PASS value from the bin directory: `./owlmanage.sh encrypt=<sensitive plain text string>`. Use the response value instead of the plain text value to secure your password.

{% hint style="info" %}
Encrypting the SSL key pass is only required for Standalone deployments. However, you can optionally set the `SERVER_SSL_KEY_PASS` property as a Kubernetes Secret for Cloud Native deployments.
{% endhint %}

```
export SERVER_SSL_KEY_PASS=<secure result from dq encryption script>
```

## Define the SSL properties

{% tabs %}
{% tab title="Standalone" %}
Add the following values to the `owl-env.sh` file.

```
export SERVER_HTTP_ENABLED=false
export SERVER_HTTPS_ENABLED=true
export SERVER_REQUIRE_SSL=true
 
####START KEYSTORE SETTINGS####
export SERVER_SSL_KEY_TYPE=PKCS12
#SET PATH TO KEYSTORE
export SERVER_SSL_KEY_STORE=KeystorePathHere
export SERVER_SSL_KEY_PASS=*******
export SERVER_SSL_KEY_ALIAS=keystoreAliasNameHere
```

{% hint style="info" %}
The most common SSL types are JKS and PKCS12.
{% endhint %}
{% endtab %}

{% tab title="Cloud Native" %}
Add the following values to the Web ConfigMap.

```
SERVER_HTTP_ENABLED: false
SERVER_HTTPS_ENABLED: true
SERVER_REQUIRE_SSL: true
SERVER_SSL_KEY_TYPE: PKCS12
SERVER_SSL_KEY_STORE: KeystorePathHere
SERVER_SSL_KEY_PASS: *******
SERVER_SSL_KEY_ALIAS: keystoreAliasNameHere
```

{% endtab %}
{% endtabs %}

## Implementing SSL behind a proxy or load balancer

If your DQ application is running behind a proxy or a load balancer that implements SSL/TLS, the proxy should include `X-Forwarded-*` headers in the requests to enable downstream applications to recognize the client request details. Collibra DQ needs to be configured to recognize those headers.

{% tabs %}
{% tab title="Standalone" %}
Add the following command to owl-env.sh:

```
export SERVER_FORWARD_HEADERS_STRATEGY=NATIVE
```

{% endtab %}

{% tab title="Cloud Native" %}
Add the following command:

```
--set global.web.security.forwardHeaders.strategy=NATIVE
```

{% endtab %}
{% endtabs %}

For additional information, go to the Spring Boot documentation on [Embedded Web Servers](https://docs.spring.io/spring-boot/how-to/webserver.html#howto.webserver.use-behind-a-proxy-server).

## Helpful resources

[Add CA certificates to the java keystore](/data-quality-self-hosted/installation/installing-data-quality-observability-self-hosted-on-self-hosted-kubernetes/deploy-on-self-hosted-kubernetes/add-ca-certificates-to-the-java-keystore.md)