Clients using the S3 protocol can connect with the cluster over an HTTPS connection. The HTTPS connection uses TLS encryption.
The algorithms used to encrypt the connection use libraries that are currently being validated for FIPS 140-3.
In order to enable S3 clients to connect to the S3 service over HTTPS, a TLS certificate must be installed for the S3 service. The S3 server presents the installed certificate to clients during the TLS handshake that takes place to establish the HTTPS connection.
There is a pre-installed self-signed certificate. You may wish to install an authority-signed TLS certificate in its place.
Restricting TLS Version and Ciphers
VAST provides the capability to enforce a limitation on unsafe, deprecated protocol dialects and ciphers. This is done through the default minimum TLS version that is accepted by the cluster's TLS service, through the ability to set the minimum TLS version to a higher version. Additionally, it is possible to further restrict the list of ciphers supported on the cluster side.
Changing the Minimum TLS Version
By default, the minimum TLS version required by the cluster is TLS v1.2. You can optionally set the minimum TLS version to TLS v1.3.
To set the minimum TLS version to TLS v1.3, run the following VAST CLI command:
vcli: admin> vms modify --min-tls-version 1.3
Note
The change takes affect for S3 connections only after the TLS certificate for S3 is subsequently uploaded. If a certificate is already uploaded to the cluster, the upload needs to be done again in order to effect a change in cipher limits.
Cipher Limits with Minimum TLS Version 1.3
Changing the minimum TLS version to v1.3 restricts the ciphers to TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256.
Starting from VAST Cluster 5.2.2, when the minimum TLS version is v1.3, you can request to enable only TLS_AKE_WITH_AES_256_GCM_SHA384 ciphers.
Please contact the VAST Customer Success team for assistance enabling this restriction.
Cipher Limits with Minimum TLS Version 1.2
When the minimum TLS version is set to the default TLS v1.2, you can request limiting ciphers to one of the following for S3 connections:
AES:!AECDHAES256+EECDH:AES256+EDH:!aNULL:!SHA1:!SHA256:!SHA384ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:AES128-SHA256:!aNULL:!SHA1
Please contact the VAST Customer Success team for assistance enabling one of these restrictions.
Certificate Requirements
The certificate must be in the PEM file format. It can be a Certificate Authority (CA) authorized root certificate or chain or you can use a self signed certificate if you choose not to obtain a CA certificate.
How to Install the Certificate
Obtain the TLS server certificate in PEM format, consisting of two files: a certificate file and a key file.
From the left navigation menu of the VAST Web UI, select Settings and then Certificates.
From the Certificate for dropdown, select S3.
Paste the certificate file content in the Server Certificate field and the key file content into the Private Key field.
Click Update.
Your certificate is installed.
Client-Side Configuration
When you configure a client to connect to the S3 service, you need to make sure that certificate verification on the client side is configured in such a way that the HTTPS connection can be established successfully. These are some suggested configurations to do on the S3 client:
Configure the client to use a certificate trust store that contains the signer for the installed certificate, or verify that it does by default. For a self signed certificate, you might do this by pointing the client to a non default trust store path and storing the certificate itself at that path.
Alternatively, disable certificate verification on the client. This will enable the HTTPS connection to be established without the client's certificate trust store containing the certificate signer.
Either make sure that the hostname embedded in the certificate matches the service endpoint URL on the client or configure the client not to verify the certificate's hostname. This will prevent connection failure due to a mismatch between the service endpoint URL configured on the client and the hostname embedded in the certificate.