PEM, keystore, and truststore files#

This guide describes the PEM and JKS certificate formats accepted by Presto for client access and for communication within the cluster.

PEM certificate#

PEM is a container format used to hold X.509 certificate information. Presto has direct support for PKCS #8 and PKCS #12 formats in PEM containers.

A single PEM file can contain both certificate and private key information. Because the certificate portion derives from a recognized Certificate Authority (CA), it does not need a separate trust store.

If you receive a PEM certificate from your network group or a vendor inspect and validate the PEM file to ensure its readiness to work with Presto. Then place the file and configure Presto to accept client connections using HTTPS.

Java keystore#

The Presto server recognizes PEM and JKS certificates for configuring access to the Presto server using HTTPS.


See PEM certificate above for information on the preferred certificate format.

The Java KeyStore (JKS) system is provided as part of your Java installation. Private keys for your server are stored in a JKS keystore file. The keystore file is always password-protected.

To be recognized as valid by the Presto CLI and modern browsers, the JKS key must be signed by a trusted Certificate Authority (CA). For JKS keys, this means either that the signing authority for a key must be listed in the current machine’s Java truststore files, or that the certificate received from a CA is chained all the way back to a recognized CA.

If you receive a JKS keystore file from your network group or from a vendor, inspect the keystore’s readiness to work with Presto. Then place the file and configure Presto to accept client connections using HTTPS.

Java truststore files#


JKS truststore files are not used if your server certificate is in PEM certificate format.

The JKS truststore file is a list of Certificate Authorities trusted by Java to validate private keys. The truststore file is provided as part of your Java installation.

Truststore files contain certificates of trusted TLS/SSL servers, or of Certificate Authorities trusted to identify servers. For securing access to the Presto coordinator through HTTPS, the clients can configure truststores. For the Presto CLI to trust the Presto coordinator, the coordinator’s certificate must be imported into the CLI’s truststore.

You can either import the certificate to a custom truststore, or to the system default truststore. However, the default truststore is likely to be overwritten by the next Java version update, so a custom truststore is recommended.

Use keytool to import the certificate to the truststore. For one example below, we import presto_certificate.cer to a custom truststore presto_trust.jks; you are prompted for whether or not the certificate can be trusted. Study the keytool man page for alternative commands.

keytool -import -v -trustcacerts -alias presto_trust -file presto_certificate.cer -keystore presto_trust.jks -keypass <truststore_pass>

Limitations of self-signed certificates#

You can generate a self-signed certificate with either the openssl or keytool commands. These are meant to be forwarded to a CA, which return a validating certificate to add to the local cert.

For a global CA to validate your Certificate Signing Request, you must generate the cert for use on a specific server that has an external DNS address that can be verified by the CA. This requirement prevents signed certs that are valid on one site from being copied and re-used on another site. Modern browsers detect cases of valid certs used on the wrong server, and block attempts to connect to them.

You cannot use a self-signed cert without validation from a Certificate Authority. Modern browsers detect servers running with such keys and either put up connection roadblocks or refuse outright to open such sites. Likewise, the Presto CLI detects a Presto server running with an unvalidated self-signed cert and either warns against connecting or blocks the connection entirely.

However, for development purposes, it is possible to create a local Certificate Authority root cert that vouches for your self-signed server certificate. This combination must never be used on a production server. Consult your network administrator group for assistance generating a self-signed certificate file.