BigMemory 4.4.0 | Product Documentation | BigMemory Max Security Guide | Setting Up Server Security | Creating the Server Certificates
 
Creating the Server Certificates
Each Terracotta server must have a keystore file containing a digital certificate and the associated private key. This document assumes that you will use self-signed certificates.
IMPORTANT SECURITY CONSIDERATION! : Self-signed certificates might be less safe than CA-signed certificates because they lack third-party identity verification and do not carry a digital signature from an official CA. Your organization might already have policies and procedures in place regarding the generation and use of digital certificates and certificate chains, including the use of certificates signed by a Certificate Authority (CA). To follow your organization's policies and procedures regarding using digital certificates, you might need to adjust the procedures outlined in this document.
When used for a Terracotta server, the following conditions must be met for certificates and their keystores:
*The keystore must be a Java keystore (JKS) compatible with JDK 1.6 or higher.
*The certificate must be keyed with the alias named in the value of the <certificate> element of the server's configuration. See Configure Server Security for details.
*The Common Name (CN) field in the Distinguished Name must contain the hostname of the server, as configured in Configure Server Security.
*The password securing the certificate must match the keystore's main password. In other words, the store password and key passwords must be identical.
*When using a self-signed certificate (not one signed by a trusted CA), create a custom truststore for storing public keys. See the section Exporting and Importing Certificates for details.
Note:
When using a self-signed certificate (not one signed by a trusted CA), use the -k option for stopping the server or running server scripts.
If you have a keystore in place, but the server certificate is not already stored in the keystore, you must import it into the keystore. If the keystore does not already exist, you must create it.
Creating Self-Signed Certificates Using Java Keytool
For testing purposes, or if you intend to use self-signed certificates, use the Java keytool command to create the public-private key pair. You also use this command to create keystores and truststores, but note that keytool refers to truststores as "keystores" since there is only a logical difference.
Note:
Specifying a Custom Truststore - Note that if you are not using cacerts, the default Java truststore, the custom truststore must be specified with the javax.net.ssl.trustStore system property. In this case, you can choose to reset the custom truststore's default password with javax.net.ssl.trustStorePassword.
The following could be used to create both public-private keys (including a certificate) and a keystore file for the server called "server1" in the configuration example above:
keytool -genkey -keystore keystore-file.jks
-dname "CN=172.16.254.1, OU=Terracotta, O=SAG, L=San Francisco, S=California,
C=US" -alias server1alias -storepass server1pass -keypass server1pass
Note that the values passed to -storepass and -keypass match. Also, the field designating the Common Name (CN) must match the server's hostname, which matches the value entered in the server's configuration. This hostname can be an IP address or a resolvable domain name. If the -dname option is left out, a series of identity prompts (distinguished-name fields based on the X.500 standard) will appear before the server's entry is created in the keystore. The CN prompt appears as shown:
What is your first and last name?
[Unknown]:
There are a number of other keytool options to consider, including -keyalg (cryptographic algorithm; default is DSA) and -validity (number of days until the certificate expires; default is 90). These and other options are dependent on your environment and security requirements. For more information on using the keytool, see the JDK documentation.
Create a keystore and entry on each Terracotta server.
Exporting and Importing Certificates
Each server should have a copy of each other server's public-key certificate in its truststore.
The following could be used to export the certificate of the server called "server1" in the configuration example above.
keytool -export -alias server1alias -keystore keystore-file.jks \
-file server1SelfSignedCert.cert
This "cert" file can now be used to import server1's certificate into the truststore of every other server. For example, to create a truststore and import server1's certificate on server2, copy the cert file to the working directory on server2 and use the following command:
keytool -import -alias server1alias -file server1SelfSignedCert.cert \
-keystore truststore.jks
After the password prompt, information about the certificate appears, and you are prompted to trust it. You must repeat this process until every server has a truststore containing the public-key certificate of every other server in the cluster.
Tip:
Use a Single Truststore - Instead of recreating the truststore on every server, create a single truststore containing every server's public key, then copy that to every server. This same truststore can also be used for clients. See Using a Client Truststore.
When you use the keytool utility, you can maintain additional certificates for the chain of trust in a file cacerts. If you wish to use these additional certificates for the import, refer to the use of the option -trustcacerts in the documentation of the keytool utility.
Tip:
As an alternative to using the command line tool keytool, you might want to try the open source graphical tool KeyStore Explorer, available at http://www.keystore-explorer.org/index.html.