Use HTTPS with a signed certificate in Cortex XSOAR. Concatenate the certificate chain.
By default, the tenant uses a self-signed certificate for a secure HTTP connection. TLS versions 1.2 and 1.3 are supported.
Create a self-signed certificate
We recommend using a self-signed certificate only for development environments. Follow these steps to create a self-signed certificate.
Open an SSH session to the Cortex XSOAR tenant.
ssh viewer@<host IP address>
Generate the private key and the certificate. For example:
openssl req -newkey rsa:4096 -x509 -sha256 -days 3650 -out example.crt -keyout example.key
Note
While the example is generic, you might need to create your certificates and keys with different parameters according to your internal company policies or compliance with regulations.
If you prefer to create a key without a passphrase, add the
-nodes
flag
Flag
Description
-newkey rsa:4096
Generates a 4096-bit RSA new private key. The default RSA key is 2048 bits.
-x509
Creates an X.509 certificate.
-sha256
Uses 265-bit SHA (Secure Hash Algorithm).
-days 3650
The number of days for which to certify the certificate. 3650 is ten years. You can use any positive integer.
-out example.csr
Specifies the file name for the newly created certificate signing request. You can specify any file name.
-keyout example.key
Specifies the file name for the newly created private key. You can specify any file name.
Open an SSH session to the Cortex XSOAR tenant.
ssh viewer@<host IP address>
Apply the key and certificate files that should be used as the HTTPS certificate for the tenant.
sudo ./sbin/set_ssl_certificate --key example.key --cert example.crt
Install or renew a custom certificate from a Certificate Authority
If you want to use your own certificate (X.509 certificates), you can install or renew a custom certificate. For security reasons, the default certificate for a production environment must be replaced with your private key and a certificate from a Certificate Authority (CA). For development environments, you either use a self-signed certificate or a certificate from a CA.
The following example is one way to create a private key and a CSR on a Linux-based system.
Note
While this example is generic, you might need to create your certificates and keys with different parameters according to your internal company policies or compliance with regulations.
Open an SSH session to the Cortex XSOAR tenant.
ssh viewer@<host IP address>
Generate the certificate signing request and the private key. The certificate signing request is for the URL that will be publicly available for everyone and also includes all public-facing aliases.
openssl req -newkey rsa:4096 -x509 -keyout example.key -out example.csr
Note
The FQDN must be provided as the Common Name (CN) when generating the CSR and private key.
To create a key without a passphrase, add the
-nodes
flag.
Flag
Description
-newkey rsa:4096
Creates a new certificate request and a 4096 bit RSA key. The default RSA key is 2048 bits.
-sha256
Uses 265-bit SHA (Secure Hash Algorithm).
-out example.csr
Specifies the file name for the newly created certificate signing request. You can specify any file name.
-keyout example.key
Specifies the file name for the newly created private key. You can specify any file name.
-addext
Adds desired DNS aliases to the certificate.
Save the
cert.key
file.Send the CSR to the Certificate Authority (CA). The CA should send the certificate by email in multiple formats. For example, example.crt.
Caution
Cortex XSOAR tenant does not support
PKCS#8
encrypted PEM files. To validate that the file is in a format that is supported, view the encrypted .key file (you can use one of the following commands - vi / less / cat) and check that theDEK-Info
header exists.A certificate with the
DEK-Info
header begins with the following:-----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTEDVcNSY7T... DEK-Info: AES-256-CBC,B94C43E0E49D267EB3AA84DC19EB41ED VcNSY7T...
If the
DEK-Info
header is not similar to the example above, the file is likely in the wrong format (PKCS#8
).You can convert the .key file to the proper format by running the following command:
openssl rsa -in oldcert.key -out cert.key -aes256
You don't have to use
aes256
, you can usedes3
or whichever encryption method you prefer.After you run this command, view the
.key
file and verify that theDEK-Info
header is similar to the example above. This should allow the.key
file to be read.For the certificate
PEM
file, you must concatenate the certificate chain one after the other in the file.Note
If you are using an intermediate certificate, the order is:
SSL certificate
Intermediate certificate
CA certificate
If you are not using an intermediate certificate, the order is:
SSL Certificate
CA Certificate
Only the certificate itself is needed, for example the text between and including
"-----BEGIN CERTIFICATE-----"
and"-----END CERTIFICATE-----"
.
To replace the default internal certificate with a private key and a certificate from a CA:
Open an SSH session to the Cortex XSOAR tenant.
ssh viewer@<host IP address>
Apply the key and certificate files that should be used as the HTTPS certificate for the server.
sudo ./sbin/set_ssl_certificate --key /path/to/example.key --cert /path/to/example.crt
If the browser does not show the new certificate, after the newly generated certificate key pair is applied, do one or more of the following:
Check whether the FQDN of the Cortex XSOAR tenant is the same as the CN field of the certificate, or any of the DNS fields in the
Certificate Subject Alternative NAME (SAN)
.On your browser on which you are trying to load Cortex XSOAR, clear cookies and other data. For example, in Chrome, go to Settings → Advanced → Clear Browsing data → Clear data.
If the Cortex XSOAR tenant is behind a load balancer, reupload the certificate on the load balancer. For example, if the Cortex XSOAR tenant is behind ELB (Elastic Load Balancing), re-import the certificate on ELB on the Amazon Certificate Manager AWS console.