TLS Installation Types

Tenable Identity Exposure requires Transport Layer Security (TLS) to encrypt internal communications between Tenable Identity Exposure components (micro-services) .

Tenable Identity Exposure enables TLS on protocols by using HTTPS instead of HTTP, AMQPS (AMQP+TLS) instead of AMQP (Advanced Message Queuing Protocol), and TLS encryption for MS-SQL.

Note: This is not the same as the activation of HTTPS on the Tenable Identity Exposure web portal using an Internet Information Services (IIS) certificate.
Note: The TLS installations offered here concern TLS encryption between Tenable Identity Exposure components and are not related to SaaS-TLS deployments.

Tenable Identity Exposure offers four types of TLS setups during the installation, from the least to the most hardened:

Installation Option Recommended For Encryption Between Internal Communications and Tenable Identity Exposure Components Peer Verification
No TLS A trusted network of machines. An easy installation with little configuration. This option falls back to the "Default TLS" option. Not encrypted. Every component communicates in plain text, except for the Secure Relay that interacts with the Directory Listener. Disabled Tenable Identity Exposure does not check server certificates. This setup is not resistant to active MITM attacks.

 
 Default TLS
(no "Expert mode")

An organization without its own internal public key infrastructure (PKI) that requires protection against passive eavesdropping.

Encrypted using an internal PKI for Tenable Identity Exposure with its own certificates and private keys, which the installation automatically generates and stores on the disk of the first machine.
Default TLS ("Expert mode")
Note: The default TLS installations — one that uses the "Expert" mode and one that does not — are essentially the same.
Custom TLS Without Peer Verification An organization with its own internal PKI that requires protection against passive eavesdropping. Encrypted, using certificates from your internal PKI. Certificates must contain the IP address of the corresponding machine in the Subject Alternative Name (SAN) extension and a signature from the provided Certificate Authority (CA). Disabled

Tenable Identity Exposure does not check server certificates. This setup is not resistant to active MITM attacks.
Custom TLS With Peer Verification An organization with its own internal public key infrastructure (PKI) that requires protection against both passive eavesdropping and man-in-the-middle (MITM) attacks. Encrypted, using certificates from your internal PKI. Certificates must contain the IP address of the corresponding machine in the Subject Alternative Name (SAN) extension and have a signature from the provided Certificate Authority (CA). Enabled

Tenable Identity Exposure checks server certificates. This setup is resistant to active MITM attacks.

It is possible to update the TLS certificate either during an upgrade of Tenable Identity Exposure or if you need to renew an expired certificate, as follows:

  1. Update the certificate (CRT) and KEY files in the default folder Tenable\Tenable.ad\Certificates.

    Note: If your new certificate is in Personal Information Exchange (PFX) format, you can use the installed openssl.exe command line to extract the CRT and KEY.

  2. Restart Services.