Configure Settings on Exalead CloudView

This section describes how to enable HTTPS on Exalead CloudView.

This task shows you how to:

Generate Your Own Certificate and Private Key
Add Certificates to the Keystore
Enable HTTPS for Exalead CloudView APIs

Generate Your Own Certificate and Private Key

At installation time, the Exalead CloudView installer generates a self-signed certificate. However, for production, it is better to generate your own certificate signed by a trusted certificate authority.

Stop the Exalead CloudView server.
Verify your certificate format using the following command:
```
openssl x509 -in <infile.cert> -text -inform <format>
```
The certificate must follow these requirements:
- DER format to facilitate the integration with Java tools (certification import/export in trust stores, etc.), or PEM depending on your needs.
- Generated key length must be: 2048 bits.
- Modulus must be: 2048 bits.
- Exalead CloudView also supports SHA-2 certificates.
Encrypted PEM files usually store Private keys. Convert them to a nonencrypted file.
You can use openssl on the command line:
```
openssl pkcs8 -topk8 -in <key> -out <hostname>-<instance>.key -nocrypt
```
The Private key must follow these requirements:
- Standard not encrypted PEM file format.
- Generated key length must be 2048 bits.
- It must have the following headers and footers:
```
-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----
```
Verify that Exalead CloudView stores the certificate correctly, using UNIX LF end of line characters:
- On Windows, you can use the following tool: http://www.thefreecountry.com/tofrodos/index.shtml.
- On UNIX, you can use dos2unix.
On each product instance, overwrite the key and certificate files generated at installation time in DATADIR/security:
- The public certificate: DATADIR/security/<hostname>-<instance>.cert
- The Private key: DATADIR/security/<hostname>-<instance>.key
Note: If you are using an alias, the Private key name must use the alias and not the default <hostname>-<instance>.
Add the server certificate to the truststore of every product instance. See Add Certificates to the Keystore.

Add Certificates to the Keystore

Stop Exalead CloudView main and secondary processes.
Import all secondary server <DATADIR>/security/*.cert files to the main server <DATADIR>/security/trusted.servers.ks keystore using the following command:
```
keytool -import -file <cloudviewServer.cert file (DER)> -alias <jetty> -keystore /…../trusted.servers.ks -storepass exalead
```
Import all main server <DATADIR>/security/*.cert files to the secondary server <DATADIR>/security/trusted.servers.ks keystore using the following command:
```
keytool -import -file <cloudviewServer.cert file (DER)> -alias <jetty> -keystore /…../trusted.servers.ks -storepass exalead
```
Note: Exalead CloudView may generate two .cert files under <DATADIR>/security. Make sure to import both .cert files in the trusted.servers.ks keystore.
When prompted for password, enter: exalead (case sensitive).
To verify that the trusted.servers.ks store type is JKS, run the following command:
```
keytool -list -keystore  /…./trusted.servers.ks
```
The command returns:
```
Keystore type: JKS
Keystore provider: SUN
```
Start the main and secondary servers.
Run <DATADIR>/bin/buildgct on the main server.

Enable HTTPS for Exalead CloudView APIs

This section describes how to enable HTTPS for the Exalead CloudView APIs.

Configure the Main Server

Stop Exalead CloudView main and secondary processes.
On the main server, edit the <DATADIR>/config/ProductSecurity.xml file.

Add the following lines above <IdentityProviderConfig>:

<master:SearchAPISecurity serverCertificate="my_certificate" useHttps="true" />
<master:MAMISecurity serverCertificate="my_certificate" useHttps="true" />
<master:PushAPISecurity serverCertificate="my_certificate" useHttps="true" />

Where my_certificate is the name of the main server .key file deployed in <DATADIR>/security.

Run <DATADIR>/bin/buildgct on the main server.
Start the main server.

Configure the Secondary Servers

For each secondary server, add all the .cert files from the main and secondary servers to the secondary server keystore:
1. Make sure that the secondary server is stopped.
2. Using keytool, import ${secondary_install}/<DATADIR>/security/*.cert files into ${secondary_install}/<DATADIR>/security/trusted.servers.ks
3. Using keytool, import ${main_install}/<DATADIR>/security/*.cert files into ${secondary_install}/<DATADIR>/security/trusted.servers.ks

Copy the main server's ProductSecurity.xml file manually to the secondary servers: ${install_dir/${OS}/<DATADIR>/gct/latest/master;

Important: This is required after you have:

Changed the main server ProductSecurity.xml file manually.
Run <DATADIR>/bin/buildgct.
And restarted the main server as described in Configure the Main Server.

… as the main server pushes the new configuration file to the secondary servers automatically.

For all secondary servers, in <DATADIR>/security, rename all .key and .cert files (that have the secondary server name) using the main server name.

For example,


Rename	to
`secondary-cvdefault.key`	`main-cvdefault.key`
`secondary-cvdefault.cert`	`main-cvdefault.cert`
`secondary.dsone.3ds.com-cvdefault.key`	`main.dsone.3ds.com-cvdefault.key`
`secondary.dsone.3ds.com-cvdefault.cert`	`main.dsone.3ds.com-cvdefault.cert`

Make sure that secondary servers can find the files after reading the serverCertificate value from the ProductSecurity.xml file.
For example, if you have the following entries in the secondary server's ProductSecurity.xml file (synced from the main server):
```
<SearchAPISecurity serverCertificate="main-cvdefault" useHttps="true" />
<MAMISecurity serverCertificate="main-cvdefault" useHttps="true" />
<PushAPISecurity serverCertificate="main-cvdefault" useHttps="true" />
```
Then in the secondary server's <DATADIR>/security folder, you get files called main-cvdefault.key and main-cvdefault.cert.
Restart the secondary servers.
All three APIs are now HTTPS secured.