Endpoint Security

Information about CGE's SSL encryption, certificates and key store.

The CGE server you provides two mechanisms for endpoint security:
  1. SSL encryption
  2. User authentication
Both of these features are off by default as they require additional user provided configuration.

SSL Encryption

When enabled, SSL provides encryption of communications between the client and the SPARQL server. Note that Communications between the SPARQL server and the database server are always encrypted regardless of whether this is enabled. By enabling this feature you gain complete end to end encryption from the client all the way to the database server.

SSL Certificates and the Key Store

In order to enable this feature you will need to provide a suitable SSL certificate. Obtaining an SSL certificate is covered elsewhere in the documentation and you should refer to that for more detail.

To use a certificate, import it into a Java key store, which can be done using the Java keytool utility:
$ keytool -import-v -trustcacerts -alias cge -file server.cer -keystore ~/.cge/keystore

In this example we import a certificate from the server.cer file to the key store located at ~/.cge/keystore.

Note that each certificate must have a unique alias within the key store. Key stores are protected by a password for which the user will be prompted. If the key store does not yet exist, the user will be prompted for a new password and a new file will be created.

In order for the server to pick up the correct certificate, the key store file should ideally contain only the certificate to be used for SSL. If it contains multiple certificates, the SSL may fail to function.

The cge-generate keystore command provides a simple wrapper around some common keytool commands. For example, the above could also be execute as:
$ cge-cli generate keystore --alias cge --importserver.cer --keystore ~/.cge/keystore

Locating the key store

For the server to access the key store, it must be provided with the location of the key store and the password to access it. The location can be provided explicitly using the --keystore option. if this is not specified, then it tries to locate a key store as follows:
  1. If the located configuration file contains a cge.cli.server.ssl.keystore property, use the file specified by that.
  2. Otherwise search for a file named keystore in any of the specified configuration directories. As with other configurations files only the first one found will be used.
    If the key store and/or the certificate itself require passwords then these must be provided in the configuration file using the following properties:
    Table 1. Key store Properties
    PropertyDescription
    cge.cli.server.ssl.passwordPassword for the key store
    cge.cli.server.ssl.key-passwordPassword for the certificate
    To avoid storing the password in plain text it may be stored in obfuscated form as supported by Jetty.

Enabling SSL

Assuming the appropriate certificate is in place in the key store, and the properties file is configured with any necessary passwords then, enable SSL using the --ssl option, as shown in the following example:
$ cge-cli fe --ssl
This will start the server configured for SSL Communications i.e. It will only respond to https:// URLs. Communication with the server will not be possible without an appropriate certificate.

Enabling Lax SSL

The default configurations for SSL only permits strong cipher suites and cryptographic protocols to be used. Some older tools may encounter difficulties when trying to communicate with the server if they do not support appropriate cipher suites and/or cryptographic protocols. In this case you may want to enable Lax SSL mode. For example: 
$ cge-cli fe --ssl --ssl-lax
CAUTION: In this mode, the server will permit the use of cipher suites and cryptographic protocols that have known flaws, are considered weak and/or may be susceptible to widely published and easily reproducible attacks. Therefore, we strongly recommend that you only use this mode when absolutely necessary.