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. All authentication and authorization technologies supported by SEP require configuring TLS as the foundation.
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. The load balancer or proxy server accepts TLS connections and forwards them to the Presto coordinator, which runs with default HTTP configuration on the default port, 8080.
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=220.127.116.11
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 obtain and install a TLS 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 #12) 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. First, use the
command to view this plain text file. It should contain sections for a PRIVATE
KEY and at least one CERTIFICATE:
-----BEGIN PRIVATE KEY----- MIIEowIBAAKCAQEAwJL8CLeDFAHhZe3QOOF1vWt4Vuk9vyO38Y1y9SgBfB02b2jW .... -----END PRIVATE KEY----- -----BEGIN CERTIFICATE----- MIIDujCCAqICAQEwDQYJKoZIhvcNAQEFBQAwgaIxCzAJBgNVBAYTAlVTMRYwFAYD .... -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIDwjCCAqoCCQCxyqwZ9GK50jANBgkqhkiG9w0BAQsFADCBojELMAkGA1UEBhMC .... -----END CERTIFICATE-----
If your PEM or key file reports
BEGIN ENCRYPTED PRIVATE KEY, you must use a
password when invoking that key.
If you received separate PEM files, one for the server’s key and another for its certificate, concatenate the files into one, in order from key to cert.
cat key.pem cert.pem > server.pem
This page presumes your system uses OpenSSL 1.1 or later.
Test the key’s validity with the following command:
openssl rsa -in server.pem -check -noout
Look for the following confirmation message:
RSA key ok
For the cert file, analyze it with a different
openssl x509 -in server.pem -text -noout
If your cert was generated with a password,
openssl prompts for it.
In the output of the
openssl command, look for the following
Modern browsers now enforce 398 days as the maximum validity period for a cert. Look for
Not Afterdates in the
Validitysection of the output, and make sure the time span does not exceed 398 days.
If you received an x509 version 3 certificate, it may have a Subject Alternative Name field. If present, 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 a good visual aid to distinguish certs. Example:
If your cert does not pass validation, or does not show the expected information upon 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 yourKeystore.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. It is easiest to make sure these passwords are the same. If the
JKS key inside the keystore has a different password, you must specify it with
keymanager.password configuration property described
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 for instructions.
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
files. However, this location might require you to keep track of the cert file
and move it to a new
etc directory if you upgrade your Presto version.
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/prestoExampleCom.pem
Possible 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.
If the JKS key itself inside the keystore has an independent password, specify that with the following property:
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, or a chain of CAs going back to a globally recognized CA. Thus, there is no need to identify a local truststore when using a signed PEM certificate.
JKS keystores normally rely on the default location of the system truststore as installed with your Java installation.
However, you may need to temporarily use a local CA to validate a self-signed cert. Do not use a local CA in a production enviroment, but you might need one during development of your cluster configuration while waiting for your self-signed cert to return signed by a recognized CA. In this case, identify the location of the local CA file with configuration properties like the following: