> ## Documentation Index > Fetch the complete documentation index at: https://doc.lucidworks.com/llms.txt > Use this file to discover all available pages before exploring further. # Security export const LwTemplate = ({title = "Key questions to get you started", icon = "sparkles", cta = "Powered by Agent Studio", linkHref = "https://lucidworks.com/demo/?utm_source=docs&utm_medium=referral&utm_campaign=docs_cta_ai"}) => { const [isLoaded, setIsLoaded] = useState(false); useEffect(() => { const timer = setTimeout(() => { setIsLoaded(true); }, 500); return () => clearTimeout(timer); }, []); return
{isLoaded && ` }} />} Powered by Lucidworks Agent Studio
; }; [localhost link]: http://localhost:3000/docs/4/fusion-server/concepts/security/overview [mintlify link]: https://doc.lucidworks.com/docs/4/fusion-server/concepts/security/overview [old doc.lw link]: https://doc.lucidworks.com/fusion/5.9/122 **Important** Lucidworks recommends *not* virus scanning the `fusion/data` folder. Virus scanning can cause slow performance, and it can cause downtime if it quarantines an index file identified as a possible virus. Fusion uses a number of security measures: * **Authenticating UI users** – Fusion authenticates users when they log in. Logging in creates a new Fusion session. Fusion also authenticates users when the [Sessions](/docs/4/fusion-server/reference/api/authentication-and-authorization-apis/sessions-api) REST API creates a session. * **Authorizing UI users** – Fusion authorizes users to use specific parts of the Fusion UI. UI users must also be authorized to make API requests, because the UI makes API requests. * **Audit trail (log) with USERID generated for all successful and failed login attempts.** Audit logs are sent to a Solr collection [system logs](https://solr.apache.org/guide/solr/latest/deployment-guide/configuring-logging.html). These logs are distinguished from other system logs in the collection by the following attribute: * `logger_class_s:"com.lucidworks.cloud.gateway.audit"` * **Authenticating and authorizing users who make API requests** * **Password Encryption**- Fusion uses 128-bit AES keys to encrypt passwords and "AES/CBC/PKCS7Padding" for the cipher. The ciphertext is also signed. * **Using session cookies** * **Using an external authentication provider** (optional) - A security realm can specify use of an external authentication provider, such as LDAP, JWT, or SAML. * **Using SSL/TLS to ensure that data in flight between your application and Fusion is not observable** (optional) - See **SSL Security (Unix)** or **SSL Security (Windows)**. * **Constraining the documents that are indexed** (optional) * **Trimming the documents that are returned by queries based on authorization** (optional) Fusion’s UI (which is accessed through the Fusion Proxy service) can run over SSL for secure communication with any HTTP client, using the [Java Secure Socket Extension (JSSE)](http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html) framework. You configure Fusion for SSL by configuring Fusion’s Proxy and UI services. Fusion 4.0.2 or later is required to enable SSL security. Version 4.0.2 fixed a bug in the authentication proxy that incorrectly redirected some requests when SSL is enabled. ## Required software {/* // tag::ssl-software-reqs[] */} Configuring Fusion for SSL requires the following software: * **Java Development Kit.** To store certificates, you can use the Java [keytool Key and Certificate Management utility](https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html) which is a part of the JDK. The JDK is also [a requirement for Fusion Server](/docs/4/fusion-server/reference/system-requirements). * [**OpenSSL**](https://www.openssl.org/). You might need the `openssl` command line tool: * If you have the certificate chain and private key as separate files, then you can use the `openssl` command line tool to create a PKCS #12 file. * If you have an intermediate CA certificate, then you can use it and `openssl` to generate the certificate chain and private key files. {/* // end::ssl-software-reqs[] */} ## Load an SSL certificate into a Fusion keystore The SSL protocol is based on public-key cryptography where encryption keys come in public key/private key pairs. An SSL certificate is used to verify the authenticity of a particular server. It contains the web site name, contact email address, company information and the public key used to encrypt the communication which is shared with the entities that communicate with the owner of the public/private key pair. The server has a locally-protected private key that is accessible via a [JSEE keystore](http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#SSLOverview). The keystore maintains both the server certificate and the private key, so that when a server authenticates itself to the client, it uses the private key from its keystore for the initial SSL handshake. Load the certificate into a Fusion keystore. Perform the tasks in the appropriate section: * [**Self-signed certificate.**](#alternative-1-self-signed-certificate) If Fusion is behind a firewall, you can use a self-signed certificate for SSL communication with other hosts in your internal network. Create a keystore for the Fusion Proxy service and load the keystore with the self-signed PKCS #12 certificate. * [**Certificate signed by a certificate authority.**](#alternative-2-ca-signed-certificate) In a production environment, SSL certificates typically originate with certificate signing requests (CSRs) and are signed by a trusted third-party [Certificate Authority (CA)](http://en.wikipedia.org/wiki/Certificate_authority). Create a keystore for the Fusion Proxy service and load the keystore with the PKCS #12 certificate from a CA. ### Alternative 1: Self-signed certificate If you are using a CSR-originated certificate from a trusted certificate authority, proceed to [Alternative 2: CA-signed certificate](#alternative-2-ca-signed-certificate). If Fusion is behind a firewall, you can use a self-signed certificate for SSL communication with other hosts in your internal network. Create a keystore for the Fusion Proxy service and load the keystore with the self-signed PKCS #12 certificate. To store certificates, you can use the Java [keytool](https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html) Key and Certificate Management utility which is a part of the JDK. **How to create a keystore and load a self-signed certificate** 1. Set environment variables: ```bash theme={"dark"} export JAVA_HOME=JavaHomeDirectory export FUSION_HOME=FusionHomeDirectory ``` For example, in Fusion 4.1: ```bash theme={"dark"} export JAVA_HOME=/usr/java/jdk1.8.0_171 export FUSION_HOME=/opt/lucidworks/fusion/4.1.2 ``` In Fusion 4.0.x: ```bash theme={"dark"} export JAVA_HOME=/usr/java/jdk1.8.0_171 export FUSION_HOME=/opt/lucidworks/fusion/4.0.2 ``` 2. Create the Fusion Proxy service keystore, generate the key pair and self-signed certificate, and load them into the keystore: ```bash theme={"dark"} "$JAVA_HOME/bin/keytool" -genkeypair -keystore "$FUSION_HOME/apps/jetty/proxy/etc/keystore" -dname "CN=CommonName, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown" -keypass KeyPassword -storepass KeystorePassword -keyalg RSA -alias selfsigned -deststoretype pkcs12 -ext SAN=dns:ServerFqdn,ip:ServerIpAddress ``` You must include the qualified domain name and/or the IP address of the Fusion server in the `-ext SAN` part of the command. Failure to do so results in SSL validation errors. Example command: ```bash theme={"dark"} "$JAVA_HOME/bin/keytool" -genkeypair -keystore "$FUSION_HOME/apps/jetty/proxy/etc/keystore" -dname "CN=search.mycorp, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown" -keypass 59Winter.Is.Long45 -storepass 46I.Prefer.Vanilla24 -keyalg RSA -alias selfsigned -deststoretype pkcs12 -ext SAN=dns:search.mycorp,ip:192.168.1.40,dns:localhost ``` {/* // tag::ssl-hosts[] */} The resulting certificate enables validated SSL transport to these hosts: ```bash theme={"dark"} https://search.mycorp:ProxyPort https://192.168.1.40:ProxyPort https://localhost:ProxyPort ``` Where `ProxyPort` is the Fusion Proxy port. {/* // end::ssl-hosts[] */} ### Alternative 2: CA-signed certificate If Fusion is behind a firewall and you are using a self-signed certificate, skip this section. Perform the tasks in [Alternative 1: Self-signed certificate](#alternative-1-self-signed-certificate). In a production environment, SSL certificates typically originate with certificate signing requests (CSRs) and are signed by a trusted third-party [Certificate Authority (CA)](http://en.wikipedia.org/wiki/Certificate_authority). The steps here assume that you are the person who will be obtaining the SSL certificate chain and private key files. If you are not that person, contact your system administrator. #### Preliminary steps 1. Obtain a domain from a domain registrar. 2. Change the A record of your domain to the public IP address of your web server instance. #### Generate SSL certificate files Use an SSL certificate provider to generate the certificate chain and private key files, or a PKCS #12 certificate, from a trusted CA: * **Certificate chain and private key files.** In this case, you will need to convert these files into a single certificate file in PKCS #12 format. * **A PKCS #12 certificate.** This must contain both the certificate chain and private key. In this case, no conversion is necessary. **How to obtain certificate files** 1. In most cases, you will need to temporarily open ports 80 and 443 in your firewall configuration. The SSL certificate provider must be able to make successful HTTP and HTTPS requests to your server through the Domain Name System (DNS). 2. Use an SSL certificate provider to generate the certificate chain (`fullchain.pem`) and private key (`privkey.pem`) files, or the PKCS #12 certificate, from a trusted CA. Steps will vary based on the certificate provider. Contact your certificate provider for details. 3. Close ports 80 and 443 in your firewall configuration. 4. Change the A record of your domain to the public domain-name address of your web server instance. Proceed to the next sections as follows: * If you have certificate chain and private key files, perform the steps in [Convert the certificate chain and private key files to a PKCS #12 certificate](#convert-the-certificate-chain-and-private-key-files-to-a-pkcsand-160-12-certificate) and [Import the PKCS #12 certificate into the Fusion Proxy service keystore](#create-the-fusion-proxy-service-keystore-and-import-the-pkcsand-160-12-certificate). * If you have a PKCS #12 certificate, perform the steps in [Import the PKCS #12 certificate into the Fusion Proxy service keystore](#create-the-fusion-proxy-service-keystore-and-import-the-pkcsand-160-12-certificate). #### Convert the certificate chain and private key files to a PKCS #12 certificate If you have a PKCS #12 certificate, skip this section and proceed to the section [Import the PKCS #12 certificate into the Fusion Proxy service keystore](#create-the-fusion-proxy-service-keystore-and-import-the-pkcsand-160-12-certificate). With the certificate chain and private key as separate files, use the `openssl` command line tool in [OpenSSL](https://www.openssl.org/) to create a PKCS #12 certificate. ```bash theme={"dark"} openssl pkcs12 -export -out /path/to/keystore.p12 -in /path/to/fullchain.pem -inkey /path/to/privkey.pem ``` Do not enter a blank password. #### Create the Fusion Proxy service keystore and import the PKCS #12 certificate Use the Java [keytool](https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html) Key and Certificate Management utility to create a keystore for the Fusion Proxy service (`$FUSION_HOME/apps/jetty/proxy/etc/keystore`) and import the PKCS #12 certificate file. Fusion uses this certificate to perform SSL. 1. To create the keystore and import the PKCS #12 certificate: 2. Use the keytool `import` command to create a JSSE keystore. ```bash theme={"dark"} keytool -importkeystore -srckeystore /path/to/keystore.p12 -srcstoretype PKCS12 -destkeystore "$FUSION_HOME/apps/jetty/proxy/etc/keystore" -deststoretype PKCS12 ``` 3. (Optional) If desired, delete the PKCS #12 certificate file that resides outside of the Fusion Proxy service keystore (the one you created from the certificate chain and private key files, or obtained from a trusted CA. ```bash theme={"dark"} rm /path/to/keystore.p12 ``` ## Enable HTTPS in the Fusion Proxy service Before beginning these steps, [load an SSL certificate into a Fusion keystore](#alternative-1-self-signed-certificate). **How to enable HTTPS in the Fusion Proxy service:** 1. (*Only for Fusion Server 4.0.x and 4.1.0*) Prevent the `start.jar` program from downloading a default keystore file, which is not needed. Edit `$FUSION_HOME/apps/jetty/home/modules/ssl.mod`. Comment out the indicated line using `#`. Change: ```bash theme={"dark"} [files] https://raw.githubusercontent.com/eclipse/jetty.project/master/jetty-server/src/test/config/etc/keystore?id=${jetty.tag.version}|etc/keystore ``` To: ```bash theme={"dark"} [files] # https://raw.githubusercontent.com/eclipse/jetty.project/master/jetty-server/src/test/config/etc/keystore?id=${jetty.tag.version}|etc/keystore ``` 2. Set environment variables: ```bash theme={"dark"} export JAVA_HOME=JavaHomeDirectory export FUSION_HOME=FusionHomeDirectory ``` For example, in Fusion 4.1: ```bash theme={"dark"} export JAVA_HOME=/usr/java/jdk1.8.0_171 export FUSION_HOME=/opt/lucidworks/fusion/4.1.2 ``` In Fusion 4.0: ```bash theme={"dark"} export JAVA_HOME=/usr/java/jdk1.8.0_171 export FUSION_HOME=/opt/lucidworks/fusion/4.0.2 ``` 3. Add HTTPS protocol support to the Jetty TLS (SSL) connector: ```bash theme={"dark"} cd "$FUSION_HOME/apps/jetty/proxy/" java -jar "$FUSION_HOME/apps/jetty/home/start.jar" --add-to-start=https ``` Example output: ```bash theme={"dark"} INFO: ssl initialized (transitively) in ${jetty.base}/start.ini INFO: https initialized in ${jetty.base}/start.ini INFO: Base directory was modified ``` 4. Get the obfuscated version of your keystore password: ```bash theme={"dark"} java -cp "$FUSION_HOME/apps/jetty/home/lib/*" org.eclipse.jetty.util.security.Password PASSWORD ``` Replace `PASSWORD` with the password you used for the keystore. If the password contains special characters, [URL encode them](https://www.w3schools.com/tags/ref_urlencode.asp). Example output: ```bash theme={"dark"} 2018-05-15 12:32:48.988:INFO::main: Logging initialized @133ms password345XYZ OBF:1vn21ugu1saj1v9i1v941sar1ugw1vo0 MD5:b91cd1a54781790beaa2baf741fa6789 ``` 5. Edit the file `$FUSION_HOME/apps/jetty/proxy/start.ini`: 1. Include obfuscated passwords by adding these properties to the end of the file: ```bash theme={"dark"} * `jetty.sslContext.keyStorePassword` * `jetty.sslContext.keyManagerPassword` * `jetty.sslContext.trustStorePassword` ``` 2. Use the OBF-encrypted password from step 4 (including the `OBF:` string) as the value for all three of the properties.\ For example: ```bash theme={"dark"} ## Keystore password jetty.sslContext.keyStorePassword=OBF:2uha1vgt1jg01a4b1a4j1jda1vg11ugg ... ## KeyManager password jetty.sslContext.keyManagerPassword=OBF:2uha1vgt1jg01a4b1a4j1jda1vg11ugg ## Truststore password jetty.sslContext.trustStorePassword=OBF:2uha1vgt1jg01a4b1a4j1jda1vg11ugg ``` 3. Set the local SSL port by adding the `jetty.ssl.port` property to the end of the file, and providing the port number. For example: ```bash theme={"dark"} ## Connector port to listen on jetty.ssl.port=8443 ``` 4. Save the file `$FUSION_HOME/apps/jetty/proxy/start.ini`. ## Restart Fusion and test access through HTTPS 1. Restart all Fusion services: ```bash theme={"dark"} ./bin/fusion restart ``` HTTPS should now be enabled in the Fusion Proxy service. 2. Sign in to the Fusion UI. Specify the HTTPS URL scheme and SSL port, for example, `https://search.mycorp:8443`. ## Disable HTTP access to the Fusion Proxy service Disable HTTP access. You have a choice. Perform the tasks in the appropriate section: * [**Disable HTTP access on the firewall or load balancer**](#alternative-1-disable-http-access-on-the-firewall-or-load-balancer) - *This is the preferred approach.* * [**Disable listening for HTTP requests in the Fusion Proxy service**](#disable-http-access-to-the-fusion-proxy-service) ### Alternative 1: Disable HTTP access on the firewall or load balancer Disable HTTP access to the Fusion Proxy service on the firewall or load balancer: 1. Disallow all requests for port 8764 from the outside world. Only `localhost` should be able to communicate with Fusion on the non-SSL port 8764. Block all other requestors. 2. If you are using a firewall or load balancer in front of Fusion, use it to redirect all HTTP requests to use HTTPS instead. For example, Apache would [redirect all incoming HTTP traffic to HTTPS](https://httpd.apache.org/docs/2.4/rewrite/avoid.html). ### Alternative 2: Disable listening for HTTP requests in the Fusion Proxy service Ideally, you should [disable HTTP access using the firewall or load balancer](#alternative-1-disable-http-access-on-the-firewall-or-load-balancer). Follow the steps in this section *only* if disabling HTTP access on the firewall or load balancer is not feasible. You can only use this alternative if your SSL certificate covers a hostname that can be accessed from the local host. For example, if your certificate only covers `https://fusion.com`, then your local machine must be able to access Fusion from that exact host. If necessary, change the `hosts` file so that this can work. **How to disable HTTP** 1. Edit `/opt/lucidworks/fusion/latest.x/apps/jetty/proxy/start.d/http.ini`. 1. Change this line: ```bash theme={"dark"} --module=http ``` To: ```bash theme={"dark"} #--module=http ``` 2. Save the file. 2. Edit the Fusion configuration file, `/opt/lucidworks/fusion/latest.x/conf/fusion.cors` (`fusion.properties` in Fusion 4.x). 1. Ensure that the Agent JVM uses the Fusion Proxy service’s keystore by adding this to the end of the file: ```bash theme={"dark"} agent.jvmOptions=-Djavax.net.ssl.trustStore="${FUSION_HOME}/apps/jetty/proxy/etc/keystore" -Djavax.net.ssl.trustStorePassword=PASSWORD -Djavax.net.ssl.keyStore="${FUSION_HOME}/apps/jetty/proxy/etc/keystore" -Djavax.net.ssl.keyStorePassword=PASSWORD ``` Replace `PASSWORD` with your Fusion keystore password. 2. Uncomment the `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, then the Fusion Proxy service will not start, because the agent’s liveness detector will not be able to access the HTTPS port to determine whether Fusion is running. If you self-signed the certificate, then the `default.address` must match the hostname you specified while signing the certificate. Failure to do this will result in the Fusion Proxy service not starting after you have disabled HTTP. For example, if your SSL certificate’s validated hostname is `search.mycorp`, then change: ```bash theme={"dark"} #default.address = 127.0.0.1 ``` To: ```bash theme={"dark"} default.address = search.mycorp ``` 3. Change the `proxy.port` to the SSL port you chose. 4. Uncomment `proxy.ssl` and change its value to `true`. Change: ```bash theme={"dark"} # proxy.ssl=false ``` To: ```bash theme={"dark"} proxy.ssl=true ``` Stopping and starting Fusion is needed for these changes to take effect. But there is a bit more to do concerning the Fusion Agent before restarting Fusion. ## References and tutorials * [Transport Layer Security](http://en.wikipedia.org/wiki/Transport_Layer_Security) (Wikipedia) * [Public Key Certificate](http://en.wikipedia.org/wiki/Public_key_certificate) (Wikipedia) * [OpenSSL Cookbook](https://www.feistyduck.com/library/openssl-cookbook/online/) (free ebook) * [OpenSSL Command Line Utilities](https://wiki.openssl.org/index.php/Command_Line_Utilities) (OpenSSL wiki) * [Java Tutorials: Generating and Verifying Certificates](https://docs.oracle.com/javase/tutorial/security/apisign/index.html) * [IBM developerWorks: What is the JSSE all about?](http://www.ibm.com/developerworks/websphere/techjournal/0502_benantar/0502_benantar.html) Fusion’s UI (which is accessed through the Fusion Proxy service) can run over SSL for secure communication with any HTTP client, using the [Java Secure Socket Extension (JSSE)](http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html) framework. You configure Fusion for SSL by configuring Fusion’s Proxy and UI services. Fusion 4.0.2 or later is required to enable SSL security. Version 4.0.2 fixed a bug in the authentication proxy that incorrectly redirected some requests when SSL is enabled. ## Required software Configuring Fusion for SSL requires the following software: * **Java Development Kit.** To store certificates, you can use the Java [keytool Key and Certificate Management utility](https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html) which is a part of the JDK. The JDK is also [a requirement for Fusion Server](/docs/4/fusion-server/reference/system-requirements). * [**OpenSSL**](https://www.openssl.org/). You might need the `openssl` command line tool: * If you have the certificate chain and private key as separate files, then you can use the `openssl` command line tool to create a PKCS #12 file. * If you have an intermediate CA certificate, then you can use it and `openssl` to generate the certificate chain and private key files. ## Overview of procedure **How to configure Fusion for SSL:** 1. [Load an SSL certificate into a Fusion keystore](#alternative-1-self-signed-certificate). 2. [Enable SSL in the Fusion Proxy service](#generate-ssl-certificate-files). 3. [Restart Fusion and test access through HTTPS](#restart-fusion-and-test-access-through-https). 4. [Disable HTTP access to the Fusion Proxy service](#disable-http-access-to-the-fusion-proxy-service). ## Load an SSL certificate into a Fusion keystore The SSL protocol is based on public-key cryptography where encryption keys come in public key/private key pairs. An SSL certificate is used to verify the authenticity of a particular server. It contains the web site name, contact email address, company information and the public key used to encrypt the communication which is shared with the entities that communicate with the owner of the public/private key pair. The server has a locally-protected private key that is accessible via a [JSEE keystore](http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#SSLOverview). The keystore maintains both the server certificate and the private key, so that when a server authenticates itself to the client, it uses the private key from its keystore for the initial SSL handshake. Load the certificate into a Fusion keystore. Perform the tasks in the appropriate section: * [**Self-signed certificate.**](#alternative-1-self-signed-certificate) If Fusion is behind a firewall, you can use a self-signed certificate for SSL communication with other hosts in your internal network. Create a keystore for the Fusion Proxy service and load the keystore with the self-signed PKCS #12 certificate. * [**Certificate signed by a certificate authority.**](#alternative-2-ca-signed-certificate) In a production environment, SSL certificates typically originate with certificate signing requests (CSRs) and are signed by a trusted third-party [Certificate Authority (CA)](http://en.wikipedia.org/wiki/Certificate_authority). Create a keystore for the Fusion Proxy service and load the keystore with the PKCS #12 certificate from a CA. ### Alternative 1: Self-signed certificate If you are using a CSR-originated certificate from a trusted certificate authority, proceed to [Alternative 2: CA-signed certificate](#alternative-2-ca-signed-certificate). If Fusion is behind a firewall, you can use a self-signed certificate for SSL communication with other hosts in your internal network. Create a keystore for the Fusion Proxy service and load the keystore with the self-signed PKCS #12 certificate. To store certificates, you can use the Java [keytool](https://docs.oracle.com/javase/8/docs/technotes/tools/windows/keytool.html) Key and Certificate Management utility which is a part of the JDK. **How to create a keystore and load a self-signed certificate** 1. Set environment variables: ```bash theme={"dark"} set JAVA_HOME=JavaHomeDirectory set FUSION_HOME=FusionHomeDirectory ``` 2. Create the Fusion Proxy service keystore, generate the key pair and self-signed certificate, and load them into the keystore: ```bash theme={"dark"} "%JAVA_HOME%\bin\keytool.exe" -genkeypair -keystore "%FUSION_HOME%\apps\jetty\proxy\etc\keystore" -dname "CN=CommonName, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown" -keypass KeyPassword -storepass KeystorePassword -keyalg RSA -alias selfsigned -deststoretype pkcs12 -ext SAN=dns:ServerFqdn,ip:ServerIpAddress ``` You must include the qualified domain name and/or the IP address of the Fusion server in the `-ext SAN` part of the command. Failure to do so results in SSL validation errors. Example command: ```bash theme={"dark"} "%JAVA_HOME%\bin\keytool.exe" -genkeypair -keystore "%FUSION_HOME%\apps\jetty\proxy\etc\keystore" -dname "CN=CommonName, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown" -keypass 59Winter.Is.Long45 -storepass 46I.Prefer.Vanilla24 -keyalg RSA -alias selfsigned -deststoretype pkcs12 -ext SAN=dns:search.mycorp,ip:192.168.1.40,dns:localhost ``` The resulting certificate enables validated SSL transport to these hosts: ```bash theme={"dark"} https://search.mycorp:ProxyPort https://192.168.1.40:ProxyPort https://localhost:ProxyPort ``` Where `ProxyPort` is the Fusion Proxy port. ### Alternative 2: CA-signed certificate If Fusion is behind a firewall and you are using a self-signed certificate, skip this section. Perform the tasks in [Alternative 1: Self-signed certificate](#alternative-1-self-signed-certificate). In a production environment, SSL certificates typically originate with certificate signing requests (CSRs) and are signed by a trusted third-party [Certificate Authority (CA)](http://en.wikipedia.org/wiki/Certificate_authority). The steps here assume that you are the person who will be obtaining the SSL certificate chain and private key files. If you are not that person, contact your system administrator. #### Preliminary steps 1. Obtain a domain from a domain registrar. 2. Change the A record of your domain to the public IP address of your web server instance. #### Generate SSL certificate files Use an SSL certificate provider to generate the certificate chain and private key files, or a PKCS #12 certificate, from a trusted CA: * **Certificate chain and private key files.** In this case, you will need to convert these files into a single certificate file in PKCS #12 format. * **A PKCS #12 certificate that contains both the certificate chain and private key.** In this case, no conversion is necessary. **How to obtain certificate files** 1. In most cases, you will need to temporarily open ports 80 and 443 in your firewall configuration. The SSL certificate provider must be able to make successful HTTP and HTTPS requests to your server through the Domain Name System (DNS). 2. Use an SSL certificate provider to generate the certificate chain (`fullchain.pem`) and private key (`privkey.pem`) files, or the PKCS #12 certificate, from a trusted CA. Steps will vary based on the certificate provider. Contact your certificate provider for details. 3. Close ports 80 and 443 in your firewall configuration. 4. Change the A record of your domain to the public domain-name address of your web server instance. Proceed to the next sections as follows: * If you have certificate chain and private key files, perform the steps in [Convert the certificate chain and private key files to a PKCS #12 certificate](#convert-the-certificate-chain-and-private-key-files-to-a-pkcsand-160-12-certificate) and [Import the PKCS #12 certificate into the Fusion Proxy service keystore](#create-the-fusion-proxy-service-keystore-and-import-the-pkcsand-160-12-certificate). * If you have a PKCS #12 certificate, perform the steps in [Import the PKCS #12 certificate into the Fusion Proxy service keystore](#create-the-fusion-proxy-service-keystore-and-import-the-pkcsand-160-12-certificate). #### Convert the certificate chain and private key files to a PKCS #12 certificate If you have a PKCS #12 certificate, skip this section and proceed to the section [Import the PKCS #12 certificate into the Fusion Proxy service keystore](#create-the-fusion-proxy-service-keystore-and-import-the-pkcsand-160-12-certificate). **How to create a PKCS #12 certificate** With the certificate chain and private key as separate files, use the `openssl` command line tool in [OpenSSL](https://www.openssl.org/) to create a PKCS #12 certificate. ```bash theme={"dark"} openssl pkcs12 -export -out \path\to\keystore.p12 -in \path\to\fullchain.pem -inkey \path\to\privkey.pem ``` Do not enter a blank password. #### Create the Fusion Proxy service keystore and import the PKCS #12 certificate Use the Java [keytool](https://docs.oracle.com/javase/8/docs/technotes/tools/windows/keytool.html) Key and Certificate Management utility to create a keystore for the Fusion Proxy service (`%FUSION_HOME%\apps\jetty\proxy\etc\keystore`) and import the PKCS #12 certificate file. Fusion uses this certificate to perform SSL. If you are starting with a certificate file in PFX format (file extension `.pfx`), that format is now identical to PKCS #12 format. 1. To create the keystore and import the PKCS #12 certificate: ```bash theme={"dark"} "%JAVA_HOME%\bin\keytool.exe" -genkeypair -alias mykeystore -keyalg RSA -keysize 2048 -keystore keystore.jks "%JAVA_HOME%\bin\keytool.exe" -importkeystore -srckeystore mycertificate.p12 -srcstoretype PKCS12 -destkeystore keystore.jks ``` 2. Use the keytool `import` command to create a JSSE keystore. ```bash theme={"dark"} keytool -importkeystore -srckeystore \path\to\keystore.p12 -srcstoretype PKCS12 -destkeystore "%FUSION_HOME%\apps\jetty\proxy\etc\keystore" -deststoretype PKCS12 ``` 3. (Optional) If desired, delete the PKCS #12 certificate file that resides outside of the Fusion Proxy service keystore (the one you created from the certificate chain and private key files, or obtained from a trusted CA. ```bash theme={"dark"} del \path\to\keystore.p12 ``` ## Enable HTTPS in the Fusion Proxy service Before beginning these steps, [load an SSL certificate into a Fusion keystore](#alternative-1-self-signed-certificate). **How to enable HTTPS in the Fusion Proxy service:** 1. Set environment variables: ```bash theme={"dark"} set JAVA_HOME=JavaHomeDirectory set FUSION_HOME=FusionHomeDirectory ``` 2. Add HTTPS protocol support to the Jetty TLS (SSL) connector: ```bash theme={"dark"} cd "%FUSION_HOME%\apps\jetty\proxy\" java -jar "%FUSION_HOME%\apps\jetty\home\start.jar" --add-to-start=https ``` Example output: ```log theme={"dark"} INFO: ssl initialized (transitively) in ${jetty.base}/start.ini INFO: https initialized in ${jetty.base}/start.ini INFO: Base directory was modified ``` 3. Get the obfuscated version of your keystore password: ```bash theme={"dark"} java -cp "$FUSION_HOME/apps/jetty/home/lib/*" org.eclipse.jetty.util.security.Password PASSWORD ``` Replace `PASSWORD` with the password you used for the keystore. If the password contains special characters, [URL encode them](https://www.w3schools.com/tags/ref_urlencode.asp). Example output: ```log theme={"dark"} 2018-05-15 12:32:48.988:INFO::main: Logging initialized @133ms password345XYZ OBF:1vn21ugu1saj1v9i1v941sar1ugw1vo0 MD5:b91cd1a54781790beaa2baf741fa6789 ``` 4. Edit the file `%FUSION_HOME%\apps\jetty\proxy\start.ini`: 1. Include obfuscated passwords by adding these properties to the end of the file: * `jetty.sslContext.keyStorePassword` * `jetty.sslContext.keyManagerPassword` * `jetty.sslContext.trustStorePassword` 2. Use the OBF-encrypted password from step 4 (including the `OBF:` string) as the value for all three of the properties.\ For example: ```ini theme={"dark"} ## Keystore password jetty.sslContext.keyStorePassword=OBF:2uha1vgt1jg01a4b1a4j1jda1vg11ugg ... ## KeyManager password jetty.sslContext.keyManagerPassword=OBF:2uha1vgt1jg01a4b1a4j1jda1vg11ugg ## Truststore password jetty.sslContext.trustStorePassword=OBF:2uha1vgt1jg01a4b1a4j1jda1vg11ugg ``` 3. Set the local SSL port by adding the `jetty.ssl.port` property to the end of the file, and providing the port number. For example: ```ini theme={"dark"} ## Connector port to listen on jetty.ssl.port=8443 ``` 4. Save the file `%FUSION_HOME%\apps\jetty\proxy\start.ini`. ## Restart Fusion and test access through HTTPS 1. Restart all Fusion services: ```bash theme={"dark"} bin\fusion.cmd restart ``` HTTPS should now be enabled in the Fusion Proxy service. 2. Sign in to the Fusion UI. Specify the HTTPS URL scheme and SSL port, for example, `https://search.mycorp:8443`. ## Disable HTTP access to the Fusion Proxy service Disable HTTP access. You have a choice. Perform the tasks in the appropriate section: * [**Disable HTTP access on the firewall or load balancer**](#alternative-1-disable-http-access-on-the-firewall-or-load-balancer) - *This is the preferred approach.* * [**Disable listening for HTTP requests in the Fusion Proxy service**](#disable-http-access-to-the-fusion-proxy-service) ### Alternative 1: Disable HTTP access on the firewall or load balancer Disable HTTP access to the Fusion Proxy service on the firewall or load balancer: 1. Disallow all requests for port 8764 from the outside world. Only `localhost` should be able to communicate with Fusion on the non-SSL port 8764. Block all other requestors. 2. If you are using a firewall or load balancer in front of Fusion, use it to redirect all HTTP requests to use HTTPS instead. For example, Apache would [redirect all incoming HTTP traffic to HTTPS](https://httpd.apache.org/docs/2.4/rewrite/avoid.html). ### Alternative 2: Disable listening for HTTP requests in the Fusion Proxy service Ideally, you should [disable HTTP access using the firewall or load balancer](#alternative-1-disable-http-access-on-the-firewall-or-load-balancer). Follow the steps in this section *only* if disabling HTTP access on the firewall or load balancer is not feasible. You can only use this alternative if your SSL certificate covers a hostname that can be accessed from the local host. For example, if your certificate only covers `https://fusion.com`, then your local machine must be able to access Fusion from that exact host. If necessary, change the `hosts` file so that this can work. **How to disable HTTP** 1. Edit `\lucidworks\fusion{backslash}latest.x\apps\jetty\proxy\start.d\http.ini`. 1. Change this line: ``` --module=http ``` To: ``` #--module=http ``` 2. Save the file. 2. Edit the Fusion configuration file, `\lucidworks\fusion{backslash}latest.x\conf\fusion.cors` (`fusion.properties` in Fusion 4.x). 1. Ensure that the Agent JVM uses the Fusion Proxy service’s keystore by adding this to the end of the file: ```properties theme={"dark"} agent.jvmOptions=-Djavax.net.ssl.trustStore="%{FUSION_HOME}%\\apps\\jetty\\proxy\\etc\\keystore" -Djavax.net.ssl.trustStorePassword=PASSWORD -Djavax.net.ssl.keyStore="%{FUSION_HOME}%\\apps\\jetty\\proxy\\etc\\keystore" -Djavax.net.ssl.keyStorePassword=PASSWORD ``` Replace `PASSWORD` with your Fusion keystore password. 2. Uncomment the `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, then the Fusion Proxy service will not start, because the agent’s liveness detector will not be able to access the HTTPS port to determine whether Fusion is running. If you self-signed the certificate, then the `default.address` must match the hostname you specified while signing the certificate. Failure to do this will result in the Fusion Proxy service not starting after you have disabled HTTP. For example, if your SSL certificate’s validated hostname is `search.mycorp`, then change: ``` #default.address = 127.0.0.1 ``` To: ``` default.address = search.mycorp ``` 3. Change the `proxy.port` to the SSL port you chose. For example, change: ``` proxy.port = 8764 ``` To: ``` proxy.port = 8443 ``` 4. Uncomment `proxy.ssl` and change its value to `true`. Change: ``` # proxy.ssl=false ``` To: ``` proxy.ssl=true ``` Stop and start Fusion for these changes to take effect. ## References and tutorials * [Transport Layer Security](http://en.wikipedia.org/wiki/Transport_Layer_Security) (Wikipedia) * [Public Key Certificate](http://en.wikipedia.org/wiki/Public_key_certificate) (Wikipedia) * [OpenSSL Cookbook](https://www.feistyduck.com/library/openssl-cookbook/online/) (free ebook) * [OpenSSL Command Line Utilities](https://wiki.openssl.org/index.php/Command_Line_Utilities) (OpenSSL wiki) * [Java Tutorials: Generating and Verifying Certificates](https://docs.oracle.com/javase/tutorial/security/apisign/index.html) * [IBM developerWorks: What is the JSSE all about?](http://www.ibm.com/developerworks/websphere/techjournal/0502_benantar/0502_benantar.html) ## Fusion user login When logging into the Fusion UI, a user provides a username and password, as well as their assigned security realm. An administrator must specify these in Fusion (using the native security realm) or configure Fusion to use an external authentication provider (for example, LDAP or SAML). See [Access control](/docs/4/fusion-server/concepts/security/access-control/overview). Fusion uses [roles](/docs/4/fusion-server/concepts/security/access-control/roles) defined by [permissions](/docs/4/fusion-server/concepts/security/access-control/permissions) to authorize Fusion UI access and perform tasks in Fusion, including searching. The recommended method to delegate permissions is as follows: * Assign each user to a role and create custom roles as needed. * Assign permissions on a per-app basis. ## Manage users with security realms Fusion uses [security realms](/docs/4/fusion-server/concepts/security/access-control/security-realms) to authenticate users of the Fusion UI. Each user has an assigned security realm, which the user must select when logging in. If the user selects a different realm, authentication fails. A security realm also provides a list of roles as follows: * The list always includes the role(s) that are specified in the security realm. * (Optional) If an external directory service (such as LDAP) is used for authentication, the list can also contain roles that are mapped from the names of the directory-service groups. That is, you can configure a security realm to return group information for users from *that same* directory service. * (Optional) The security realm can reference one or more Fusion roles or, when using an external directory service provider, use group membership information from the provider to determine roles for users. Fusion maps the group names to role names and adds these roles to the user’s list of roles. Fusion does not use permissions from LDAP to authorize UI access or API requests. It only obtains group names (optionally), which are used as role names or are mapped to role names. If an [Active Directory Security Query Trimming Stage](/docs/4/fusion-server/reference/pipeline-stages/query/active-directory-security-trimming-query-stage) is used, then directory-service permissions *are* used for trimming. If a connector supports security trimming, then connector permissions *are* used for trimming. ## Per-Request Authentication Requests to the Fusion REST API must specify a security realm for per-request authentication, unless a session cookie is used (which contains information about the security realm). Fusion authorizes requested operations based on API permissions specified for the user and for the user’s role(s). Fusion considers the role(s) specified in the user definition and in the security realm. Fusion creates a list of roles when a session is created, that is, when a user logs in or when the [Sessions](/docs/4/fusion-server/reference/api/authentication-and-authorization-apis/sessions-api) REST API creates a session. Authorization based on [permissions](/docs/4/fusion-server/concepts/security/access-control/permissions) and its layering is at request time. You can define multiple [security realms](/docs/4/fusion-server/concepts/security/access-control/security-realms) for a Fusion instance. A Fusion instance can manage multiple security realms, which allows users from different domains to have (different levels of) access to specific Fusion collections. ## Learn more Configure Fusion for a Security LDAP Realm that Connects to Active Directory 1. Log in as an admin to Fusion and go to **Security Realms**.\\ ad-ldap-1 2. Go to the Security Realms tab and click **Add Security Realm**.\\ ad-ldap-2 3. Give it a name and choose **type: ldap**. * If you want an AD user to be automatically created in Fusion when they are seen for the first time, leave “Auto-create users” checked. Typically, you will leave this checked. Otherwise, you have to preload Fusion with users prior to them logging in. * Specify what Roles you want users to have by default when logging in to this realm.\\ ad-ldap-3 4. Specify your AD server hostname. Choose port 389 for non-SSL, and 636 for SSL.\\ ad-ldap-4 5. For **Authentication Method: search**, choose **Search** from the 3 options. 1. In the **Search Based Login: Base DN** field, specify the DN of the lowest place in the AD tree where your users will need to be searched for. in my example, it is `cn=users,dc=sptest,dc=local`. 2. For the **Search Based Login: Filter Template**, use `(&(sAMAccountName={})(objectClass=person))`.\\ ad-ldap-5 6. For **Super User - Bind DN** enter the DN of a user with access to crawl and enter that user’s password.\ This says “Super User”, but the AD account does not need to be an Administrator. Your user only needs to be able to read group member attributes.\\ ad-ldap-6 7. Next is the **Group / Role Mapping**. 1. For **Group Search: Base DN**, similar to what you did for the user DN, enter the lowest level of the AD tree where applicable groups can be found. 2. For **Group Search: Name Attribute**, enter `sAMAccountName`. 3. For **Group Search: Filter Template**, enter `(&(member={})(objectClass=group))`. 4. For **Group Mapping**, enter a mapping of each Fusion role name to the DN of a group you want to be in that role.\ Example:\\ ad-ldap-7 ## Creating a Delegation of Control of the bind user The LDAP Realm needs to be able to get a user’s groups in order to do the Group Mapping. By default, Active Directory allows all Authenticated Users to list group memberships. So chances are, everything will work. But, if your security is tightened in your environment, the user you choose in **Super User** section may not have access to list group memberships. This will result in your users having no roles because the role lookup will not be able to connect your user’s AD groups with their Fusion roles. In this case, you may need to delegate control of this account to be able to Read the tree. 1. Go to Active Directory Users and Computers → Action → Delegate Control.\\ ad-ldap-8 2. Enter the user:\\ ad-ldap-9 3. Add the **Read all user information** checkbox.\\ ad-ldap-10 4. Finish.\\ ad-ldap-11 You can configure Active Directory Federation Services (AD FS) for SAML single sign-on (SSO) authentication in Fusion. This guide explains how to set up Spring Boot OAuth2 with AD FS. OAuth-based authentication against AD FS requires AD FS 3.0 or later which is available from Windows Server 2012 R2 onwards. ## Configure a Security Realm in Fusion In Fusion, create a Security Realm for AD FS. 1. In the Fusion workspace, navigate to **System** > **Access Control**. 2. Click **Security Realms**. 3. Click **Add Security Realm**. 4. Enter the following information for the new realm: * Enter a **Name**. The name must be unique and should be descriptive yet short. * Select **saml** from the **Type** pulldown menu. When you select a type, Fusion displays additional configuration options. * The default value for **Enabled** is true. This setting controls whether or not Fusion allows user logins for this security realm. * The default value for **Ephemeral Users** is false. When disabled, this setting prevents ephemeral users from being created in ZooKeeper during login. If enabled, this property negates **Auto Create Users**. * The default value for **Auto Create Users** is true. If enabled, a user account is created automatically upon initial authentication. If disabled, then a Fusion user with admin permissions must create Fusion users. Under **SAML Realm**, configure the following information: * Enter the **Identity Provider URL**. This URL is used by the SAML authority for single sign-on. For example: `https://www.example.com/APP-PATH/adfs/ls` * Enter the URL of the **IdP Issuer**. For example: `http://www.example.com/adfs/services/trust`. * **IdP Issuer** must match `` in the SAML payload. * Optional: Provide the **App Issuer**. This field is required if there is an `audienceRestriction` in the SAML assertion and must match `` in the SAML payload. * In the **Certificate Fingerprint**, paste the contents of the SAML authority certificate, *without the certificate header and footer*. * Optional: Enter the **User ID Attribute**. By default, the Fusion username is the same as the login name known to the Identity Provider. When another field or attribute in the user record stored by the IdP should be used as the Fusion username, that attribute name is the value of the User ID Attribute. * Optional: Provide a **Post Login Redirect URL**. If not set, the Fusion URL is used. * Optional: Provide a **Logout URL**. 1. Optional: Under **Groups Mapping**, specify the Group Name Attribute and add group mappings. 2. Click **Save**. ## Set up the application (relying party trust) in AD FS Create a relying party trust in the AD FS Management console. For more details, refer to the [Microsoft AD FS documentation](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn486828\(v=ws.11\)#to-create-a-relying-party-trust-manually). The following screenshots may differ from your setup depending on the version of AD FS you’re using. 1. Launch the Add Relying Party Trust Wizard, then select **Claims aware**. adfs-relying-party-2 2. Choose the option to enter the data manually. adfs-relying-party-1 3. Set a Display name. adfs-relying-party-3 4. Configure URL. Enable the option for SAML 2.0 WebSSO protocol. adfs-relying-party-5 5. Set the **Relying party trust identifier** to the URL of the Fusion application. adfs-relying-party-identifier 6. Edit the Claim Rules to pass through the User Principal Name as the `NameID` claim. adfs-principal-roles-claim-rule 7. In a terminal, create the OAuth AD FS `client` for the Fusion application: ```bash wrap theme={"dark"} Add-ADFSClient -Name "Fusion OAuth" -ClientId "1234567890-ABCDEF" -RedirectUri="http://localhost:8080/oauthLogin" ``` The `ClientId` should be a GUID and the `RedirectUri` must point to the Fusion application URL, with `/oauthLogin` appended. Here, `localhost` is used for testing a Fusion application running on the local development machine. ## Configure the OAuth module for the application setup in AD FS Create a new configuration file in `conf/security/oauth.conf`. ```yaml theme={"dark"} client-id: 168f3ee4-63fc-4723-a61a-6473f6cb515d adfs-url: https://your-adfs-server/adfs resource: http://localhost:8080 high-trust: false ``` Replace the `client-id`, `adfs-url` and `resource` parameters for your environment. * The `client-id` is the ID that was set up against AD FS using the `Add-ADFSClient` PowerShell command. * The `adfs-url` is the URL of the AD FS server with the `/adfs` context appended. * The `resource` is the relying party trust identifier set up in AD FS management. * The `high-trust` parameter is only required when integrating the AD FS and SharePoint modules. This article is only concerned with authentication against AD FS. ## Test the authentication When a user goes to the Fusion login page, they will be redirected to the AD FS OAuth login page. After the user logs in, the user will be returned to Fusion as an authenticated user. The Fusion user’s details will also be populated with any basic information available from the decoded OAuth token such as roles and the user principal name. ## Prerequisite Create or determine the fully qualified path for your Fusion directory, referred to as `{FUSION_HOME}` in this document. For example, `c:/fusion/4.2/`. ## Configure SSL for Solr embedded in Fusion 1. Navigate to the following directory: `{FUSION_HOME}/apps/jetty/solr/etc` 2. Create a self-signed certificate from an existing certificate in a production environment. Use the following example and enter information for your system: `keytool -genkeypair -alias localhost -keyalg RSA -keysize 2048 -keypass secret -storepass secret -validity 365 -keystore keystore -ext SAN=DNS:localhost,IP:127.0.0.1 -dname "CN=localhost, OU=org unit, O=org, L=loc, ST=st, C=country"` Only use a trusted Certificate Authority (CA) to generate certificates. 3. Navigate to the following directory: `{FUSION_HOME}/apps/jetty/solr` 4. Enter the following command to enable SSL on the Solr jetty instance: `java -jar {FUSION_HOME}/apps/jetty/home/start.jar --add-to-start=https` 5. Navigate to the following directory: `cd {FUSION_HOME}` 6. Enter the following to create the obfuscated (OBF) password: `java -cp ./apps/libs/jetty-util-9.3.8.v20160314.jar org.eclipse.jetty.util.security.Password secret` 7. Open the `{FUSION_HOME}/apps/jetty/solr/start.ini` file and set the following properties (using the designated OBF password): `jetty.sslContext.keyStorePassword jetty.sslContext.keyManagerPassword jetty.sslContext.trustStorePassword` 8. Enter the following to set the Solr SSL port: `jetty.ssl.port=` ## Disable HTTP for Solr HTTP *must* be disabled for services such as connectors to work correctly with Solr. Open the `fusion/4.2/apps/jetty/solr/start.d/http.ini` file and enter a `#` to comment out the `--module=http` entry: `#--module=http` ## Edit the fusion.properties file 1. Open the `fusion/4.2/conf/fusion.properties` file. 2. Enter the Solr keystore information in the Java Virtual Machine (JVM) for all services: ```java theme={"dark"} .jvmOptions=-Djavax.net.ssl.trustStore={FUSION_HOME}/apps/jetty/solr/etc/keystore -Djavax.net.ssl.trustStorePassword=secret -Djavax.net.ssl.keyStore={FUSION_HOME}/apps/jetty/solr/etc/keystore -Djavax.net.ssl.keyStorePassword=secret ``` 3. Uncomment the `default.address` field and enter the hostname of the server validated in the SSL certificate: `default.address=localhost` 4. Enter the value designated in `jetty.ssl.port=` in the `solr.port` field. 5. Append the `solr.ssl=true` entry to the file. 6. Save and close the file. ## Start Zookeeper and Solr 1. Enter the following command to start Zookeeper: `${FUSION_HOME}/bin/zookeeper start` 2. Enter the following command to start Solr: `${FUSION_HOME}/bin/solr start` ## Configure Solr cluster for https Enter the following command to use Zookeeper to configure the Solr cluster for `https` instead of `http`: `${FUSION_HOME}/apps/solr-dist/server/scripts/cloud-scripts/zkcli.sh -zkhost localhost:9983/lwfusion/${FUSION_VERSION}/solr -cmd clusterprop -name urlScheme -val https` ## Solr SSL shell script The `solr_ssl.sh` script contains all of the steps to configure SSL for Solr embedded in Fusion. To use the script, enter your system’s values and information in the file, and then execute the script: ```bash expandable theme={"dark"} # Update these variables as needed. FUSION_HOME="" VALIDATED_ADDRESS="localhost" SOLR_PORT="8493" FUSION_VERSION="4.2.6" keytool -genkeypair -keystore "${FUSION_HOME}/apps/jetty/solr/etc/keystore" -dname "CN=CommonName, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown" -keypass secret -storepass secret -keyalg RSA -alias selfsigned -deststoretype pkcs12 -ext SAN=dns:${VALIDATED_ADDRESS},ip:127.0.0.1 # enable ssl on solr cd "${FUSION_HOME}/apps/jetty/solr" java -jar "${FUSION_HOME}/apps/jetty/home/start.jar" --add-to-start=https KEYSTORE_ARG="-Djavax.net.ssl.trustStore=${FUSION_HOME}/apps/jetty/solr/etc/keystore -Djavax.net.ssl.trustStorePassword=secret -Djavax.net.ssl.keyStore=${FUSION_HOME}/apps/jetty/solr/etc/keystore -Djavax.net.ssl.keyStorePassword=secret" # add the solr properties echo "" >> ${FUSION_HOME}/apps/jetty/solr/start.ini echo "" >> ${FUSION_HOME}/apps/jetty/solr/start.ini echo "jetty.ssl.port=${SOLR_PORT}" >> ${FUSION_HOME}/apps/jetty/solr/start.ini echo "jetty.sslContext.keyStorePassword=OBF:1yta1t331v8w1v9q1t331ytc" >> ${FUSION_HOME}/apps/jetty/solr/start.ini echo "jetty.sslContext.keyManagerPassword=OBF:1yta1t331v8w1v9q1t331ytc" >> ${FUSION_HOME}/apps/jetty/solr/start.ini echo "jetty.sslContext.trustStorePassword=OBF:1yta1t331v8w1v9q1t331ytc" >> ${FUSION_HOME}/apps/jetty/solr/start.ini # set the keystore and truststore on solr jvm sed -i -e "s%solr.jvmOptions.*%solr.jvmOptions=-Xmx2g -Xss256k ${KEYSTORE_ARG}%g" ${FUSION_HOME}/conf/fusion.properties # set the truststore on other jvms sed -i -e "s%api.jvmOptions.*%api.jvmOptions=-Xmx1g -Xss256k -Dhttp.maxConnections=1000 ${KEYSTORE_ARG}%g" ${FUSION_HOME}/conf/fusion.properties sed -i -e "s%connectors-classic.jvmOptions.*%connectors-classic.jvmOptions=-Xmx1g -Xss256k ${KEYSTORE_ARG}%g" ${FUSION_HOME}/conf/fusion.properties sed -i -e "s%connectors-rpc.jvmOptions.*%connectors-rpc.jvmOptions=-Xmx1g -Xss256k -Xms512m ${KEYSTORE_ARG}%g" ${FUSION_HOME}/conf/fusion.properties sed -i -e "s%proxy.jvmOptions.*%proxy.jvmOptions=-Xmx512m ${KEYSTORE_ARG}%g" ${FUSION_HOME}/conf/fusion.properties # Change the solr port to the SSL port and enable SSL on the validated address sed -i -e "s%solr.port.*%solr.port=${SOLR_PORT}%g" ${FUSION_HOME}/conf/fusion.properties echo "" >> ${FUSION_HOME}/conf/fusion.properties echo "solr.ssl=true" >> ${FUSION_HOME}/conf/fusion.properties echo "default.address = ${VALIDATED_ADDRESS}" >> ${FUSION_HOME}/conf/fusion.properties # Disable HTTP echo "#--module=http" > ${FUSION_HOME}/apps/jetty/solr/start.d/http.ini # Start zookeeper ${FUSION_HOME}/bin/zookeeper start ${FUSION_HOME}/bin/solr start # Use zookeeper to configure the solr cluster to use HTTPS instead of HTTP ${FUSION_HOME}/apps/solr-dist/server/scripts/cloud-scripts/zkcli.sh -zkhost localhost:9983/lwfusion/${FUSION_VERSION}/solr -cmd clusterprop -name urlScheme -val https # Ready to go at this point. Restart Fusion! ${FUSION_HOME}/bin/fusion restart ```