When deploying through Kubernetes there are two options available, these are as follows:
... api-ssl: true api-cert: "<base64-encoded-certificate>" ssl: false ...
The above setup allows HTTPS connections to the socket without a certificate for the TCP connection to the cluster.
To enable TCP SSL you must provide a certificate for the TCP connection.
... api-ssl: true api-cert: "<base64-encoded-certificate>" ssl: true cert: "<base64-encoded-certificate>" hostname-validation: false ...
For a self-signed certificate setup, provide both certificates as base64-encoded values and
disable the hostname validation for the HTTPS protocol. hostname-validation
can be left on for certificates signed by a trusted authority.
To gather the certificates, you should use the getcert.pl tool.
The hostname-validation setting can be configured in three ways:
Per cluster in clusters.json using the hostname-validation field
Globally in DASHBOARD_HOSTNAME_VALIDATION environment variable.
Globally in config.json using the hostname-validation field
If none are specified, it defaults to true
Priority order:
Cluster-specific setting in clusters.json (highest priority)
DASHBOARD_HOSTNAME_VALIDATION environment variable.
Global setting in config.json
Default value of true (lowest priority)
When hostname validation is:
Enabled: The certificate's hostname must match the server's hostname.
Disabled: The certificate is still verified, but the hostname matching is skipped. This is mostly the scenario for self-signed certificates.
When hostname validation is disabled (either per cluster or globally), a certificate must be provided:
If hostname-validation=false is set for a specific cluster, that cluster must
include a cert field
If hostname-validation=false is set globally in config.json,
all SSL-enabled clusters must include a cert field
This requirement ensures secure connections even when hostname matching is skipped