Configuring SSL Socket Certificates

Before the 6.0.0 release, the mechanism to communicate notifications between backend processes and the app server was through plain sockets. Beginning with the 6.0.0 release, these communications are performed by the safer SSL sockets.

Before starting to transport data through the SSL tunnel, certificates are used to authenticate endpoints. Certificate verification is important, because “man-in-the-middle” attacks can happen when certificate verification is not enabled.

SSL certificate verification is performed in two directions: the client verifies the server’s certificate and the server verifies the client’s certificate.

By default, certificate verification is disabled in both directions in FortiSIEM. This section describes how to configure certificate verification in FortiSIEM

Running the SSL Configuration Script

The config-ssl-cert.sh shell script does the work to configure SSL certificates correctly. This script performs the following tasks:

• Provides values for the SSL configuration attributes in the GLOBAL section of the /opt/phoenix/config/phoenix_config.txt file.
• Generates files, such as the certificate chain file, trust store, and key store.
• Restarts backend processes to apply the configuration.

To run the config-ssl-cert.sh shell script, follow these steps:

1. Log in to the system as user root.
2. Run the config-ssl-cert.sh shell script with the appropriate options for your environment. See Script Options and Script Examples.

Note:

• When running the script, use the absolute path for all files and directories.
• The script will back-up the existing phoenix_config.txt file and cert_store, before modifying it. You can restore the previous version if you need to.

Script Options

The following table describes the options that can be used with the config-ssl-cert.sh shell script.

Option	Description
-h	Display the help message of script.
-v <0|1|2|3>	Set certificate verify model. This is a required option, with following possible values. 0: Disable certificate verify at both directions 1: Enable only the verifying server’s certificate. This means that the client will verify the certificate from server, but server will not require or verify the certificate from client. 2: Enable only the verifying client’s certificate. This means that the server will require and verify certificate from client, but client will not verify the certificate from server 3: Enable certificate verification in both directions. This means that the client will verify the certificate from server, and server will require and verify the certificate from client.
-p	This option indicates whether the provided certificate is public. Public certificates are signed by a well-known CA organization. It should not be signed by a private CA, or by itself. This option is useful, because it indicates whether you need a CA for the certificate. As you know, if the certificate is public, then the ROOT CA for that certificate is always installed in the system by default. You do not have to provide one. However, if the certificate is private, then a private CA is required.
-c <Certificate file> -k <Key file>	The -c and -k options are used together to specify the Certificate File and corresponding Key file.
-a <CA file> -d <CA dir>	The CA is used to verify the certificate. The -a and -d options are used together to specify the CA file and the directory where it is stored. If the provided certificate is private, then the CA is required. If the provided certificate is public, then the CA is optional (typically, it is not needed).
-i <Intermediate CA chain file>	If the certificate is not signed by the ROOT CA directly (this is typically the case for public certificates), then there is a trust chain: Certificate -> Intermediate CA1 -> Intermediate CA2 ->…-> Root CA Use this option to provide the intermediate CA (Intermediate CA) chain. If there is only one intermediate CA, then that intermediate CA certificate can act as the intermediate CA chain file directly. If there is more than one intermediate CA, then you must create a chain file for them by using the cat command, for example: cat IntermediateCA1 Intermediate CA2 … IntermediateCAn > IntermediateCAChain
-s <cert_store>	You might need to generate some useful files, such as the trust store file and key store file. Use this option to specify where you want to store those files. By default, they will be stored in the /opt/phoenix/config/cert_store directory.
-r	Typically, you must restart backend processes to apply the configuration changes. Use this option, to instruct the script to restart the processes automatically. NOTE: because you are configuring the notification communicating mechanism, it might fail if you try to restart the backend processes using tools such as phtools --stop all or monctl stop. If you want to restart the backend processes manually, use following commands: phstatus.py |grep ph |cut -d' ' -f1 |xargs killall -9 monctl start phtools --start all

Script Examples

• Disable Certificate Verification in Both Directions
• Enable Verification in Both Directions Using a Public Certificate
• Enable Verification in Both Directions with a Self-Signed Certificate

Disable Certificate Verification in Both Directions

This command disables verification in both directions:

config-ssl-cert.sh -v 0 –r

where:

• -v 0 - disables verification in both directions.
• -r - restarts backend processes to apply the changes.

Enable Verification in Both Directions Using a Public Certificate

This command enables verification in both directions using a public certificate.

config-ssl-cert.sh -v 3 -p -c /opt/star_qa_fortisiem_fortinet_com.crt -k /opt/star_qa_fortisiem_fortinet_com.key -i /opt/DigiCertCA.crt –r

where:

• -v 3 - enables verification in both directions. You can change to 1 to verify only the server’s certificate, or change to 2 to verify only the client’s certificate.
• -p - specifies that the -c and -k options identify the <certificate, key> pair of a public certificate.
• -i – specifies that there is an intermediate CA for the certificate. This means that there is a trust chain here: star_qa_fortisiem_fortinet_com.crt -> DigiCertCA.crt -> Root CA.

Because this is a public certificate, the CA (-a) option is not required.

Enable Verification in Both Directions with a Self-Signed Certificate

This command enables verification in both directions using a self-signed certificate.

config-ssl-cert.sh -v 3 -c /etc/pki/tls/certs/localhost.crt -k /etc/pki/tls/private/localhost.key -a /etc/pki/tls/certs/localhost.crt –r

where:

• The absence of the -p option indicates that the provided -c and -k options are specifying a private <certificate, key> pair.
• -a – specifies the CA file used to verify the certificate. This is the certificate itself, in the self-signed case.