HTTPS with a signed certificate - Use HTTPS with a signed certificate in Cortex XSOAR. Concatenate the certificate chain. - Administrator Guide - 8.10 - Cortex XSOAR - Cortex

HTTPS with a signed certificate - Use HTTPS with a signed certificate in Cortex XSOAR. Concatenate the certificate chain. - Administrator Guide - 8.10 - Cortex XSOAR - Cortex - Security Operations

Cortex XSOAR On-prem Documentation

Product

Cortex XSOAR

Version

8.10

Creation date

2025-04-08

Last date published

2026-05-11

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.

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 -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.

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 -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.

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 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.
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-----".

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

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/noPwd.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.

Example 5.

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.

Create a self-signed certificate

Note

Note

Important

Install or renew a custom certificate from a Certificate Authority

Note

Note

Caution

Note

Important

Export External Dynamic Lists (EDLs) to a firewall