Clients can issue queries to SciDB instances over an HTTP (insecure) or HTTPS (secure) connection. This interface replaces the functionality originally provided by the Shim plugin. The Shim plugin will continue to work with any SciDB server, and it may be required to support some legacy applications, but it is no longer needed if the only applications running are ones that support the new interface (such as R applications using SciDBR 4.0 and later).

If the SciDB cluster has security mode enabled (either security=password or security=pam), only HTTPS connections are allowed, and the cluster must be configured with an X.509 certificate. If the SciDB cluster is configured with security=trust, the instances can be configured to accept either HTTP or HTTPS; using HTTPS requires an X.509 certificate.

If a cluster has security mode enabled but doesn’t have a certificate configured, the instances will not accept any HTTPS connections, but the older client API used by the Shim plugin will still work.

The default HTTP/HTTPS port for the first instance in a cluster is 8239 (similar to the default port of 1239 on the older client API); each subsequent instance gets the next number in sequence. To change the starting port number, set http-base-port in the SciDB configuration file. The configured port uses HTTPS if the SciDB server has security mode enabled or has an X.509 certificate; it uses HTTP only if security=trust and there is no certificate configured.

HTTPS Configuration

To enable secure HTTPS connections, you need to install an X.509 certificate and private key on all servers; set https-cert and https-key to the correct paths in every SciDB instance’s configuration file; and restart the SciDB cluster. If you don’t install a certificate, you can still use the Shim plugin to access the SciDB cluster, but the SciDB cluster won’t accept any direct HTTPS connections from clients.

If you are upgrading an existing SciDB cluster that has previously been running Shim, the best thing to do is reuse the existing X.509 certificate used by Shim. If the existing certificate is already signed by a Certificate Authority, this lets you avoid the process of getting a new certificate signed, and prevents clients from receiving warnings that the certificate doesn’t match the one they last found on the same server.

If you don’t have an existing Shim installation to copy a certificate from, you can create a self-signed certificate from the command prompt. This is the recommended approach for getting a new SciDB cluster running as quickly as possible, but it may lead to some clients issuing warnings that the server’s identity can’t be verified. Later, if needed, you can contact your company’s IT department for help with getting a certificate signed by your company’s Certificate Authority or by a global Certificate Authority.

Migrating an X.509 certificate from Shim

The Shim’s X.509 certificate is typically located at /var/lib/shim/ssl_cert.pem. This certificate usually contains both a public cert and a private key.

It’s best to keep the existing certificate where it is, and make a copy in a new location so SciDB can access it. The copy must have its permissions modified using chmod/chown so that only the scidb user can access it. Here’s one way this can be done, assuming that Shim and SciDB reside on the same server (and that there’s only one SciDB server in the cluster):

Then edit the SciDB configuration file and add these lines (replacing 23.2 with the current SciDB version number):

Finally, restart the SciDB cluster.

If there are any problems with reading the certificate, the server won’t start. Look in the configured scidb.log to see the errors.

Creating a self-signed certificate

Follow these directions only if you aren’t migrating an existing X.509 certificate from Shim.

SciDB provides a script that creates a basic self-signed certificate using some generic default settings. If you don’t care about the contents of the certificate, you can run it and accept all of the defaults:

This will create two files: a private key file called ssl_key.pem, and a public certificate file called ssl_cert.pem. The private key file should already have its permissions restricted so that only the SciDB user (and the superuser) can read it.

Now edit the SciDB configuration file and add these lines (replacing 23.2 with the current SciDB version number):

Finally, restart the SciDB cluster.

If there are any problems with reading the certificate, the server won’t start. Look in the configured scidb.log to see the errors.

Firewall configuration

You must make sure that the ports configured for HTTP/HTTPS aren’t blocked by the server’s software firewall.

Port numbers are issued to each instance in sequence, starting with the http-base-port (8239 by default). If you don’t know what ports are configured or how many there are, you can check the port configurations for all instances by running iquery -otsv -aq "project(list('instances'), instance_url)". The output will show a URL for each instance, which includes the instance’s port number.

Once you know the first and last port number, you should configure your software firewall to allow public TCP access to all ports in the range.

To do this on CentOS 7 and related systems:

1. Create a temporary command line variable FIRST_PORT with the first port number, and LAST_PORT with the last port number.

2. Run these commands:

Testing HTTPS access

To confirm that HTTPS is working, you can use the built-in curl command to issue some HTTP requests:

If these tests succeed, you can try connecting your application to SciDB. Remember to change the application’s configuration to use the new port number (8239) instead of the Shim port number (8083). If your application uses SciDBR version 4.0 or greater, it should be able to detect which interface is being hosted on the given port, and adapt to it automatically.