Certificate Overview

All SSL clients establish a trust relationship with their server. This is performed with a certificate on the client side, which is a public key that is associated with a private key on the server. When establishing the trust relationship, the server’s certificate must either have been signed by a key trusted by the client, or be trusted explicitly by the client (a self-signed certificate). Most SSL clients contain a set of trusted Certificate Authorities (CAs), so that if a server has a certificate signed by one of those CAs, it automatically trusts the server. If the server is self-signed, that server’s certificate must be added to the client’s list of trusted servers.

In addition, the client checks the Common Name (CN) of the server’s certificate against the hostname of the server, to verify that the certificate is being used on the intended host. This means that all Servers require a certificate chained to the top-level certificate.

For Java clients, such as Java Drivers and Engines, the certs are kept in a trust keystore. The JRE is shipped with a default keystore called cacerts. To add a certificate, typically this file is copied, the certificate is imported, and the JVM is pointed to the new file.

Native clients that use the cURL library use a platform-dependent directory that contains CA certificates. GridServer Engine Daemons and C++ Drivers also look for a PEM-encoded certificate called ssl.pem in the current working directory.

.NET clients look in the Windows Trust Store local to that machine. Certificates can be added to that store by double-clicking on the file and importing using the wizard.

For demonstration purposes, GridServer is packaged with a demo self-signed key-pair and certificate. All clients have a local copy of the certificate added to their list of trusted servers. While this self-signed cert is useful to demonstrate how to set up SSL, a certificate for your organization must be used in a production environment.