Installation guide

Appendix 3: Nessus SSL Configuration

Introduction

This section describes how to generate and exchange SSL certificates for the Nessus vulnerability scanner to use with

SecurityCenter. For this procedure, you will need to have administrative (root) access to the SecurityCenter system, as

well as all Nessus scanner systems.

Please note that users should be familiar with PKI deployments and it is not recommended that the Nessus

server be used as the site’s PKI system. The method described here is intended to assist in testing the

functionality of the certificate exchange to assist users in the incorporation of the certificates into their current

PKI system. In this method, the same key is shared between multiple servers. This may not be acceptable in

some installations.

Overview of SSL Certificates and Keys

Nessus supports authentication protocols based on the OpenSSL toolkit (please see http://www.openssl.org/ for more

details about the toolkit). This provides cryptographic protection and secure authentication. This section provides an

overview of the certificates and keys necessary for SSL communication with Nessus. In the example described in this

document, there are three key system components: the Certificate Authority, the Nessus Server and the Nessus client,

which in this case is SecurityCenter. 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 Certificate

Authority holds a copy of the certificates for registered users to certify that the certificate is genuine. When the Certificate

Authority receives a Certificate Signing Request (CSR), it validates and signs the certificate. In the example provided in

this document, the Certificate Authority resides on the Nessus server, but this is not the recommended method for a

production environment. In proper PKI deployments, the Certificate Authority 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 Certificate

Authority, 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

The Nessus client, which is SecurityCenter in this case, communicates with the Nessus server via SSL. It uses keys

generated for a Nessus client and stores these keys and the certificate for the Certificate Authority in the

/opt/sc4/daemons directory. These keys must be owned by the “tns” userid.

Nessus Configuration for Unix

Commands and Relevant Files

The following section describes the commands and relevant files involved in the Nessus SSL process on a Red Hat Linux

system.

Certificate Authority and Nessus Server Certificate

The /opt/nessus/sbin/nessus-mkcert command creates the Certificate Authority and generates the server

certificate. This command creates the following files: