HTTPS and TLS#
Presto runs with no security configuration in its default installation. This allows you to connect to the server using URLs that specify the HTTP protocol with the Presto CLI, the Web UI, or other clients.
This guide describes how to configure Presto to use Transport Layer Security (TLS), and require the HTTPS protocol from client connections. This is a requirement to enable any supported authentication and authorization.
Transport Layer Security (TLS) is the successor to its now-deprecated predecessor, Secure Sockets Layer (SSL). This page uses the term TLS to refer to TLS and SSL.
To configure Presto with TLS support, there are two alternative paths to consider:
Use the load balancer or proxy at your site or cloud environment to terminate HTTPS/TLS. This approach is the simplest and strongly preferred solution.
Secure the Presto server directly. This requires you to obtain a valid certificate, and add it to the Presto coordinator’s configuration.
Use a load balancer to terminate HTTPS/TLS#
Your site or cloud environment may already have a load balancer or proxy server
configured and running with a valid TLS certificate. In this case, you can work
with your network administration group to set up your Presto server behind the
load balancer. It accepts TLS connections and forwards them to Presto running
with default HTTP configuration. This includes changing the port to the default
In this case, the Presto cluster is contained in a virtual private network. The load balancer adds request headers with the original client information:
X-Forwarded-Proto: https X-Forwarded-Host: presto.example.com Forwarded: for=10.0.16.42;proto=https;by=188.8.131.52
To enable processing of forwarded headers, the config properties file must include the following:
This completes any necessary configuration for using HTTPS with a load balancer. Client tools can access Presto with the URL exposed by the load balancer.
Secure Presto directly#
Instead of the preferred mechanism of using an external load balancer, you can secure the Presto coordinator itself. This requires you to use a certificate and configure Presto to use it for any client connections.
Add a TLS certificate#
Obtain a TLS certificate file (a cert) from one of the following sources:
Your site’s network administration group
Your cloud environment provider
A domain name registrar, such as Verisign or GoDaddy
A certificate vendor
A certificate generating command such as
Presto supports certificate files in PEM (PKCS #8 and PKCS #1) or JKS format. The PEM format is preferred, and is easier to use.
Make sure you obtain a certificate that is certified by a recognized certification authority (CA), or that you submit a self-generated certificate to a CA for validation.
Inspect PEM certificates#
When you receive your PEM format certificate, inspect it and verify that it
shows the correct information for your Presto server. Use this
command to inspect the cert:
openssl x509 -in your-cert-file -text -nout
If your PEM file was generated with a password,
openssl prompts for it.
The PEM file should contain server certificate and private key sections. For example:
-----BEGIN CERTIFICATE----- MIIFHjCCAwYCCQCmg7+WHUP8ADANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJV ... -----END CERTIFICATE----- -----BEGIN PRIVATE KEY----- MIIJQwIBADANBgkqhkiG9w0BAQEFAASCCS0wggkpAgEAAoICAQDTWPax1rfWIvK/ .... -----END PRIVATE KEY-----
If you received two separate files, one for each type, just concatenate the files into one, in the order shown above.
If your PEM reports
ENCRYPTED PRIVATE KEY, you must use a password when
invoking that key.
In your PEM file, look for the following characteristics:
Modern browsers now enforce 398 days as the maximum validity length. Look for
Not Afterdates in the
Validitysection of the output, and make sure the time between does not exceed 398 days.
If you received an x509 version 3 certificate, it has a Subject Alternative Name field. Make sure this shows the DNS name of your server, such as
The legacy common name (CN) field is ignored by modern browsers, but is good to have. Example:
Validate PEM certificates#
Validate your PEM cert with the following command:
openssl rsa -in your-cert-file -check -noout
If your PEM file was generated with a password,
openssl prompts for it. Look
for the following confirmation message:
RSA key ok
If your cert does not pass validation, or does not show the expected information after inspection, contact the group or vendor who provided it.
Inspect JKS keystores#
The Java KeyStore (JKS) system is provided by your Java installation. JKS keys are stored in a JKS keystore file.
Inspect the JKS keystore file to make sure it contains the correct information
for your Presto server. Use the
keytool command, which is installed as part
of Java, to retrieve information from your keystore container file:
keytool -list -v -keystore your-keystore.jks
Keystores always require a password. If not provided on the
keytool prompts for the password.
Independent of the keystore’s password, it is possible that the JKS key has its
own password. Make sure these passwords are the same, because
prompts for one password at a time.
In the output of the
keytool -list command, look for:
The keystore must contain a private key, such as
Entry type: PrivateKeyEntry
Depending on the origin of your keystore file, it may also contain a certificate. Example:
Entry type: trustedCertEntry
Confirm that the
Valid from ... untilentry shows no more than 398 days.
Verify that the subject alternative name, if present, matches your server’s DNS name. Example:
SubjectAlternativeName [ DNSName: presto.example.com ]
Import CA certificate into JKS keystore#
If you generated a self-signed JKS keystore, you must send that with a
Certificate Signing Request to a Certificate Authority. In return, you receive a
certificate keystore, possibly with
.cer extension. Depending on the CA, you
might receive a certificate self-signed only by the issuing CA, or one signed by
a chain of validating CAs.
To create a certified JKS keystore, you must import the certificate received
from the CA into the keystore, using the
keytool -import command. The
keytool command is complex and covers many cases. Please study the
Certificate Chains and Importing Certificates sections of the
keytool man page before proceeding.
The JKS system works in conjunction with JKS truststore files, described in Additional configuration for truststores.
Place the certificate file#
There are no location requirements for the PEM or JKS certificate file as long as the following applies:
The location is visible from the server’s configuration file location with a relative path reference from the server’s root directory, or with an absolute path reference.
The location is secure from copying or tampering by malicious actors.
You can place your PEM file or JKS keystore file in the Presto server’s
directory, which allows you to use a relative path reference in configuration
tar.gz style Presto installations, if you upgrade one Presto version to
another, remember to copy the cert file to the new installation’s
By contrast, an RPM installation generally uses the system
directory to hold server configuration files, which are re-used after a Presto
server version upgrade.
Configure the coordinator#
On the coordinator, add the following lines to the config properties file to enable HTTPS support for the server:
http-server.https.enabled=true http-server.https.port=8443 http-server.https.keystore.path=etc/presto-example-com.pem
Alternatives for the third line include:
Relative paths are relative to the Presto server’s root directory. In a
tar.gz installation, the root directory is one level above
JKS keystores always require a password, and PEM certs can optionally require one. For these cases, add the following line to specify the JKS or PEM password.
Restart the server and test connecting with a URL that begins with
using the Presto CLI.
Presto disables HTTP access to the Web UI when HTTPS is enabled for the coordinator. Although not recommended, you can enable it by setting:
When configured to provide HTTPS connections as shown above, the server continues to allow HTTP connections to all clients except the Web UI. When you are certain HTTPS connections are stable and reliable from the clients of interest, you can disable HTTP access:
However, there are configuration scenarios that require the server to respond to
HTTP requests for inter-node communication with worker nodes even with HTTPS
enabled for client access. In these cases, configure both server types as
Additional configuration for truststores#
The JKS truststore file is a list of Certificate Authorities trusted by Java to
validate private keys. The truststore file,
cacerts, is provided as part of
your Java installation.
A PEM format certificate usually contains a private key for your server plus a validating certificate that is recognized by at least one Certificate Authority. Thus, there is no need to identify a local truststore when using a signed PEM certificate.
When using JKS keys, it is possible to copy the system
cacerts file and use
the copy. In this case, identify the location of the copy with the following