Overview of Tenable Nessus SSL Certificates and Keys

Nessus supports authentication protocols based on the OpenSSL toolkit (for more information about the toolkit, see http://www.openssl.org/). This provides cryptographic protection and secure authentication.

In the example described in this document, there are three key system components: the certificate authority, the Nessus server and the Nessus client (Tenable Security Center). It is necessary to generate the keys required for the SSL communication and copy them to the appropriate directories.

Certificate Authority

The certificate authority (CA) ensures that the certificate holder is authentic and not an impersonator. The CA holds a copy of the certificates for registered users to certify that the certificate is genuine. When the CA receives a certificate signing request (CSR), it validates and signs the certificate.

In the example provided in this document, the CA resides on the Nessus server (which is not the recommended method for a production environment). In a proper PKI deployment, the CA would be a separate system or entity, such as Thawte or Verisign.

Nessus Server

In the example described in this document, the Nessus server is the same physical system that holds the CA, but this will not likely be the case in a production environment. The Nessus server is the target of the secure communication and its keys must be generated locally and copied to the systems that will need to communicate with it using the SSL protocol. The Nessus server has users defined that authenticate to it either by simple login and password or via SSL. These users will also have keys associated with them.

Nessus Client (Tenable Security Center)

The Nessus client, Tenable Security Center, communicates with the Nessus server via SSL. It uses keys generated for a Nessus client and stores these keys and the certificate for the CA in the /opt/sc/daemons directory. These keys must be owned by the “tns” userid.