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 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
Forwarded:  for=;proto=https;by=

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 free certificate generator, such as or

  • A certificate generating command such as openssl or keytool

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 openssl 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:


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 Before and Not After dates in the Validity section 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 command line, 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 keytool only 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 ... until entry shows no more than 398 days.

  • Verify that the subject alternative name, if present, matches your server’s DNS name. Example:

    SubjectAlternativeName [

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 etc directory, which allows you to use a relative path reference in configuration files.

For tar.gz style Presto installations, if you upgrade one Presto version to another, remember to copy the cert file to the new installation’s etc directory.

By contrast, an RPM installation generally uses the system /etc/presto 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:


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 etc.

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 https:// 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 enabled=true:


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 configuration properties: