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
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 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 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 #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 cat command to view this plain text file. It should contain sections for a PRIVATE KEY and at least one 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

Validate key#

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

Validate certificate#

For the cert file, analyze it with a different openssl command:

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

  • Modern browsers now enforce 398 days as the maximum validity period for a cert. Look for Not Before and Not After dates in the Validity section 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:

Invalid certs#

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 command line, 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 the keymanager.password configuration property described below.

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


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


If the JKS key itself inside the keystore has an independent password, specify that with the following property:


Restart the server and test connecting to it with a URL that begins with https:// using the Presto CLI or Web UI.

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