PEM, keystore, and truststore files#
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.
You can generate your own self-signed PEM to send to a Certificate Authority for signing, as described in Generate self-signed PEM.
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.
You can generate your own self-signed keystore to send to a Certificate Authority for signing, as described in Generate self-signed JKS keystore.
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 to 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 man page for
keytool 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
keytool commands. These are meant to be forwarded to a CA, which return a
certificate to add to the key.
You cannot use a self-signed key without certification. 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 a self-signed cert and either warns against connecting or blocks the connection entirely.
In order for a CA to validate your Signing Request, you must generate the key for use on a specific server that has a external DNS address that can be verified by the CA. This requirement prevents signed certs that are valid one 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.
Generate self-signed PEM#
Generate a self-signed PEM cert with the
openssl command with commands like
the following. This is one possible set of commands; consult
documentation for other options.
Generate your private key and public certificate. This command is following by a questionnaire that prompts for the components of your server’s Common Name.
openssl req -newkey rsa:2048 -nodes -keyout key.pem -x509 -days 365 -out cert.pem
Review the generated certificate:
openssl x509 -text -noout -in cert.pem
Combine your key and certificate into a PKCS#12 (P12) bundle:
openssl pkcs12 -inkey key.pem -in cert.pem -export -out cert.p12
Validate your P12 file:
openssl pkcs12 -in cert.p12 -noout -info
Generate self-signed JKS keystore#
Generate a self-signed JKS keystore with the
keytool command using a command
like the following. This is one possible command; consult
documentation for other options.
keytool -genkeypair -alias presto -keyalg RSA -keystore keystore.jks -validity 360 -keysize 2048
This command prompts you for a password to assign to the new keystore:
Enter keystore password: Re-enter new password:
Following next is a questionnaire that lets
keytool construct the Common
Name for your server. For example:
What is your first and last name? What is the name of your organizational unit? What is the name of your organization? What is the name of your City or Locality? What is the name of your State or Province? What is the two-letter country code for this unit? Is CN= ... correct? [no]: yes
Finally, the command prompts for a password to assign to the generated key, independent of the keystore’s password assigned above. To avoid complications, press RETURN to use the same password for both.
- Enter key password for <presto>
(RETURN if same as keystore password):
Verify the newly created keystore:
keytool -list -v -keystore keystore.jks
Next, generate a Certificate Signing Request to send to a Certificate Authority:
keytool -keystore keystore.jks -certreq -alias presto -keyalg rsa -file prestoserver.csr