Configuring Fusion for SSL

Fusion uses the Java Secure Socket Extension (JSSE) framework to enable SSL configuration for secure communication between the Fusion UI and any HTTP client.

To configure Fusion for SSL you must install an SSL certificate and enable SSL in the Fusion UI.

Installing an SSL certificate

The server has a locally-protected private key that is accessible via a JSEE keystore. The keystore maintains both the server certificate and the private key.

In a production environment, SSL certificates must be signed by a trusted Certificate Authority (CA).

To store certificates, you can use the Java keytool, which is part of the JDK. When you have a signed certificate, then you create a JSSE keystore by using the keytool "import" command.

In the following example, we have a signed certificate, in pfx format, in a PKCS#12 file called fusion.keystore.p12. The following command creates a new JSSE keystore (JKS):

keytool -importkeystore -srckeystore /opt/lucidworks/fusion/apps/jetty/ui/etc/fusion.keystore.p12 \
 -srcstoretype pkcs12 -destkeystore /opt/lucidworks/fusion/jetty/ui/etc/keystore -deststoretype JKS

If you have the certificate and private key as separate files, then you need to use openssl to create a PKCS#12 file. For example:

openssl pkcs12 -export -out /home/admin/keys/keystore.pkcs12 -in /home/admin/keys/fullchain.pem -inkey /home/admin/keys/privkey.pem
When prompted for a password, do not enter a blank password.

Now use keytool to import the PKCS#12 file into Java keystore format and optionally delete the PKCS#12 file:

keytool -importkeystore -srckeystore /home/admin/keys/keystore.pkcs12 -srcstoretype PKCS12 -destkeystore {fusion_path}/apps/jetty/ui/etc/keystore
If your server certificate is signed by an intermediate CA rather than a root CA, you must add the intermediate certificate to the keystore before you add the server certificate.

Enabling SSL in the Fusion UI

  1. Run the following:

    cd {fusion_path}/apps/jetty/ui
    java -jar {fusion_path}/apps/jetty/home/start.jar --add-to-start=https
    This step requires an Internet connection. If no connection is available on the Fusion host, run the commands above on a separate host, then copy the resulting fusion/3.1.x/apps/jetty/ui/etc/keystore file to the Fusion host.
  2. Get the hashed version of your keystore password:

    cd {fusion_path}
    java -cp ./apps/libs/jetty-util-9.3.8.v20160314.jar <secret>

    Where <secret> is the password you used for the keystore or the -storepass value if you generated the self-signed certificate as per the guide provided here.

  3. Edit fusion/3.1.x/apps/jetty/ui/start.ini to uncomment and add the hashed password from the previous step to these properties:

    • jetty.sslContext.keyStorePassword

    • jetty.sslContext.keyManagerPassword

    • jetty.sslContext.trustStorePassword

    For example:

    ## Keystore password
    ## Keystore type and provider
    # jetty.sslContext.keyStoreType=JKS
    # jetty.sslContext.keyStoreProvider=
    ## KeyManager password
    ## Truststore password
  4. Set the local SSL port by editing the jetty.ssl.port property.

    For example:

    ## Connector port to listen on
  5. Configure ZooKeeper to use HTTPS:

    1. Start ZooKeeper if required.

    2. Run fusion/3.1.x/apps/solr-dist/server/scripts/cloud-scripts/ -zkhost <zkHost1>:<port1>,<zkHost2:port2>,.. -cmd put /clusterprops.json '{"urlScheme":"https"}'

  6. Restart Fusion with fusion/3.1.x/bin/fusion restart.

    HTTPS should now be enabled on port 8864.

Optional Steps to set up your firewall / load balancer:
  • Disallow all requests from 8764 from the outside world. Only localhost should be able to talk to Fusion on the non-SSL port 8764. Block all others.

  • If you are using a load balancer or web server in front of Fusion, use it to redirect all HTTP requests to use HTTPS instead.

Disabling HTTP

Only do this if blocking access to HTTP using the firewall is not feasible.

To entirely disable HTTP, remove the HTTP connector from the Jetty startup configuration:

You can only use this option if your SSL certificate covers a hostname that can be accessed from the local host. For example, if your SSL certificate only covers then your local machine must be able to access Fusion using this URL.
  1. Edit fusion/3.1.x/apps/jetty/ui/start.d/http.ini to change --module=http to #--module=http.

  2. Edit fusion/3.1.x/conf/

    1. Make sure the Agent JVM uses the UI’s keystore by adding the following to the end of the file:"fusion/3.1.x/apps/jetty/ui/etc/keystore"<password>"fusion/3.1.x/apps/jetty/ui/etc/keystore"<password>
    2. Uncomment default.address and change it to the hostname of the server that is validated by your SSL certificate.

      If the hostname saved in default.address is not validated by your ssl certificate, UI will not start because the Agent’s liveness detector will not be able to access HTTPS port to see if Fusion is running.
      If you self-signed the certificate, the default.address must match the hostname you specified while signing the certificate. For example if my SSL certificate’s validated hostname is localhost, change #default.address = to default.address = localhost
    3. Change ui.port to the SSL port you chose for jetty.ssl.port in UI’s start.ini file earlier.

    4. Set ui.ssl to true by changing # ui.ssl=false to ui.ssl=true

  3. Restart Fusion.

Configuring Fusion for SSL Solr/SolrCloud

To configure the Fusion HTTP client for a SSL-ed Solr or SolrCloud server, you must specify the system properties.

Step 1. Edit the configuration file

In the fusion/3.1.x/conf/ file, add the following properties to the options api.jvmOptions, connectors.jvmOptions, and ui.jvmOptions:"/path/to/solr-ssl.keystore.jks""/path/to/solr-ssl.keystore.jks"

Step 2. Register SolrCloud as a search cluster in Fusion

Send a request to the REST API 'searchCluster' endpoint:

curl -u admin:pass -H 'Content-type: application/json' -X POST 'http://localhost:8764/api/apollo/searchCluster' -d '
  "id" : "ssl",
  "connectString" : "localhost:2181",
  "cloud" : true

Step 3. Test: create collection, index data, query collection

Create collection in SolrCloud with configured SSL:

curl -u admin:pass -H 'Content-type: application/json' -X POST 'http://localhost:8764/api/apollo/collections' -d '
  "id" : "mycollection",
  "searchClusterId" : "ssl"

Index data using an existing pipeline:

curl -u admin:pass 'http://localhost:8764/api/apollo/index-pipelines/mycollection-default/collections/mycollection/index' -XPOST -H "Content-type: application/json" -d '{
  "id": "1",
  "foo_s": "bar",
  "spam_s": 42

Query the collection using the default query pipeline:

curl -u admin:pass 'http://localhost:8764/api/apollo/query-pipelines/mycollection-default/collections/mycollection/select?q=*:*'

Generating a self-signed certificate

If don’t have signed certificates from an external CA, then you can generate a set of self-signed certificates using the Java keytool utility to generate a public/private key pair and generate a self-signed certificate.

The keytool option "-genkeypair" generates a public/private key pair. It wraps the public key into an X.509 v3 self-signed certificate, which is stored as a single-element certificate chain. This certificate chain and the private key are stored in a new keystore entry identified by alias. The full set of arguments to this command are:

    {-alias alias}
    {-keyalg keyalg}
    {-keysize keysize}
    {-sigalg sigalg}
    [-dname dname]
    [-keypass keypass]
    {-startdate value}
    {-ext ext}*
    {-validity valDays}
    {-storetype storetype}
    {-keystore keystore}
    [-storepass storepass]
    {-providerClass provider_class_name {-providerArg provider_arg}}

Arguments of interest are:

  • keyalg specifies the algorithm to be used to generate the key pair. This must be RSA in order to talk to browser clients IE and Navigator.

  • keysize specifies the size of each key to be generated. Depends on keyalg. For RSA, this should be 2048.

  • dname specifies the X.500 Distinguished Name to be associated with the alias, and is used as the issuer and subject fields in the self-signed certificate. If no distinguished name is provided at the command line, the user will be prompted for one. An X.500 Distinguished name is a set of named fields, of these, the field named "CN", ("Common Name"), is the internet-facing fully qualified domain name of the server.

  • keypass is a password used to protect the private key of the generated key pair. If no password is provided, the user is prompted for it. If you press RETURN at the prompt, the key password is set to the same password as that used for the keystore. keypass must be at least 6 characters long.

  • ext is used to embed extensions into the certificate generated. For Fusion, the server certificate should include the "SAN" or SubjectAlternativeName extension which allows alternative URIs and IP addresses to be associated with this certificate.

Keystore files created by the keystore tool are in the JKS format, which is a proprietary file format capable of storing multiple key-pairs, certificates, and symmetric encryption keys, and with all entries indexed by the keypair alias.

To generate a self-signed certificate for the Fusion UI running as "localhost", we use the following arguments:

keytool -genkeypair \
 -alias localhost -keyalg RSA -keysize 2048 \
 -keypass secret -storepass secret \
 -validity 365 -keystore my.keystore.jks \
 -ext SAN=DNS:localhost,IP: \
 -dname "CN=localhost, OU=org unit, O=org, L=loc, ST=st, C=country"
The value for CN must match the hostname you will be using to access Fusion. For example, if will use the URL to access the UI then the CN should have the value

This keystore file can now be imported to the Fusion UI keystore. To check the generated keystore we use the openssl tool to pretty-print the signed certificate in the file my.keystore.jks. This is not strictly necessary; this should always be done before sending the certificate to a CA to get it signed properly in order to verify that the certificate information is complete and correct.

To get from the keystore JKS format to a human-readable printout, it must be converted to the text-based "PEM" format, which is ASCII (Base64) armored data prefixed with a -– BEGIN … line. This requires three steps.

First, we use the keytool to convert the proprietary JKS format to the PKCS #12 format:

keytool -importkeystore \
 -srckeystore my.keystore.jks -destkeystore my.keystore.p12 \
 -srcstoretype jks -deststoretype pkcs12

This command prompts for passwords - as before, the password is "secret".

Next, we use openssl to convert the PKCS format to PEM format:

openssl pkcs12 -in my.keystore.p12 -out my.keystore.pem

Finally, to pretty-print the certificate, we use the following openssl command:

openssl x509 -in my.keystore.pem -text -noout

This converts the PEM format to text format, and writes the output to the terminal. The output is:

        Version: 3 (0x2)
        Serial Number: 1442779707 (0x55ff123b)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=country, ST=st, L=loc, O=org, OU=org unit, CN=localhost
            Not Before: Apr  8 07:39:35 2015 GMT
            Not After : Apr  7 07:39:35 2016 GMT
        Subject: C=country, ST=st, L=loc, O=org, OU=org unit, CN=localhost
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                DNS:localhost, IP Address:
            X509v3 Subject Key Identifier:
    Signature Algorithm: sha256WithRSAEncryption