Skip to content

Configure SSL for the Cluster

The Okera cluster can be configured to use SSL. Okera strongly recommends that you use SSL for all Okera clusters, to avoid transmitting plain text credentials (such as usernames, passwords and tokens) over the network.

Notes: The Presto endpoint requires SSL.

In addition, if you enable SSL without specifying any other information, Okera will generate self-signed certificates.

Configuration Settings

The following Okera configuration settings are used to configure SSL:

  • SSL_CERTIFICATE_FILE
  • SSL_KEY_FILE
  • ENABLE_SSL

Defaults with okctl

If the ENABLE_SSL value is set to true in the configuration file and no other SSL configuration value is used, okctl generates a CA certificate and a certificate/key (with the IP of the local machine as the common name for the cert) in the current directory:

  • .auth/ca.pem - the CA certificate
  • .auth/cert.pem - the certificate (including it's full chain)
  • .auth/cert.key - the certificate private key

It then sets the following values automatically when updating the cluster configuration:

SSL_CERTIFICATE_FILE: file:///path/to/current/dir/.auth/cert.pem
SSL_KEY_FILE: file:///path/to/current/dir/.auth/cert.key

You can disable this behavior by removing the ENABLE_SSL setting or specifying your own values for these settings.

Certificate Requirements

Okera has two requirements for the certificate file:

  1. It must be in PEM format.
  2. It must contain the full certificate chain. Not including the full chain may cause some clients to reject this certificate.

Note: For Let's Encrypt certificates, the full chain of certificates is in the fullchain.pem file.

Configure the Certificate and Key

If you have a particular certificate and key file you would like to configure, put the following values in your configuration:

SSL_CERTIFICATE_FILE: file:///path/to/cert.pem
SSL_KEY_FILE: file:///path/to/cert.key

Validate the SSL Configuration

Once your cluster is updated with the certificate configuration, use the openssl CLI to verify it can be fully validated.

For example, if your Web UI is at https://okera.company.com:8083, you can run:

$ openssl s_client -connect okera.company.com:8083
CONNECTED(00000005)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = *.company.com
verify return:1
---
Certificate chain
0 s:/CN=*.okerademo.com
i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
...

If you see an error such as "unable to verify the first certificate", it may mean you do not have the full chain or the hostname/IP on which you are accessing the cluster does not match the Common Name (CN) in the certificate.