HTTPS with a signed certificate

Configure HTTPS with a signed certificate in Cortex XSOAR 8.10 On-prem.

By default, the tenant uses a self-signed certificate for a secure HTTP connection. TLS versions 1.2 and 1.3 are supported.

Certificate requirements

If you apply a custom TLS certificate, it must cover all three tenant hostnames (the cluster, API, and external addresses) either in the Common Name (CN) or, preferably as Subject Alternative Names (SANs). Using a wildcard certificate (such as *.mycompany.com) is the simplest option.

Important

The installer does not verify if these hostnames are included in your certificate. If any address is missing, installation may complete successfully, but your engines, brokers, and APIs will fail to connect later with TLS host name verification errors.

For more information, see the prerequisites for the Install Cortex XSOAR on your VM task for your deployment type.

Certificate storage and auditing

HTTPS certificates and private keys are securely stored in Cortex XSOAR as Kubernetes secrets. During a certificate update, the old secret is automatically deleted and the certificate is not exposed externally. For better at-rest security, it is recommended to add drive encryption on your host machine.

Cortex XSOAR does not maintain an internal audit trail for certificate changes or private key access. These actions are performed and managed only by the customer using the provided certificate change script.

Create a self-signed certificate

Note

For command line prompt access, you need to open an SSH session to the Cortex XSOAR tenant with the 'viewer' user.

The 'viewer' user password is the same as the 'admin' user password. Ensure you are using the latest valid password (either from the initial installation or the last reset).

We recommend using a self-signed certificate only for development environments. Follow these steps to create a self-signed certificate.

Task 1. Create the certificate

1. Open an SSH session to the Cortex XSOAR tenant.

   ssh viewer@<host IP address>
2. Generate the private key and the certificate. For example:

   openssl req -newkey rsa:4096 -x509 -sha256 -days 3650 -nodes -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.
   -nodes	Do not encrypt private keys.
   -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.

Task 2. Apply the certificate

Important

If the custom certificate has a password, it will cause an error. To resolve this, remove the password from the key file using the following command:

openssl rsa -in original.key -out noPwd.key

1. Open an SSH session to the Cortex XSOAR tenant.

   ssh viewer@<host IP address>
2. Apply the key and certificate files that should be used as the HTTPS certificate for the tenant.

   sudo ./sbin/set_ssl_certificate --key noPwd.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.

Task 1. Create a private key and a Certificate Signing Request (CSR)

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.

1. Open an SSH session to the Cortex XSOAR tenant.

   ssh viewer@<host IP address>
2. 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 -nodes -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.
   -nodes	Do not encrypt private keys.
   -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.

3. Save the cert.key file.
4. 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 the DEK-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 use des3 or whichever encryption method you prefer.

   After you run this command, view the .key file and verify that the DEK-Info header is similar to the example above. This should allow the .key file to be read.
5. 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:

     1. SSL certificate
     2. Intermediate certificate
     3. CA certificate
   • If you are not using an intermediate certificate, the order is:

     1. SSL Certificate
     2. CA Certificate
   • Only the certificate itself is needed, for example the text between and including "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----".

Task 2. Apply the certificate to Cortex XSOAR

Replace the default internal certificate with a private key and a certificate from a CA.

Important

If the custom certificate has a password, it will cause an error. To resolve this, remove the password from the key file using the following command:

openssl rsa -in original.key -out noPwd.key

1. Open an SSH session to the Cortex XSOAR tenant.

   ssh viewer@<host IP address>
2. 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/noPwd.key --cert /path/to/example.crt

Troubleshoot creating a private key and CSR

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.

Example

Export External Dynamic Lists (EDLs) to a firewall

An EDL is a text file that you or another source hosts on an external web server so that a firewall can import objects (IP addresses, URLs, and domains) to enforce policy on the entries in the list. As the list is updated, the firewall dynamically imports the list at a configured interval and enforces policy without making a configuration change or a commit on the firewall.

To export a secure EDL to your firewall, you need to replace the out-of-the-box certification and set up the certification for the firewall to be able to access the EDL. For more information on setting up a PAN-OS firewall, see Configure the Firewall to Access an External Dynamic List. For more information on importing a certificate to a PAN-OS firewall, see Import a Certificate and Private Key.