Tenable Nessus Agents: Deploying Trusted Certificate for Nessus Manager on Virtual Appliance

If you want to deploy Nessus Agents in an OnPremise Nessus Manager Setup you have to make sure Nessus Manager has a Certificate which is trusted by the Clients OS and that Nessus Manager trusts the Clients Computer certificates.

With the default self-signed Certificate Linking of Agents will not work. You might have found this out during Agent Linking and seen some kind of ssl error like this:

[07/Apr/2017:11:57:47 +0100] [error] [msscan] Connection to manager for 'jobs?distro=es6-x86-64&platform=LINUX&sleep_time=10&ui_version=6.9.3' failed with code 0 [Connection to shared-nessusmanager:7021 failed with an ssl error] -- Last connection was Mon, 20 Feb 2017 18:51:18 GMT

Source: https://community.tenable.com/s/article/Connection-issues-with-a-new-Nessus-Agent-install

Nearly every environment i encounter has similar parameters:

  • A Windows Domain
  • Mainly Windows Clients and Servers
  • A Windows Certificate Authority (CA)
  • Nessus Manager Running on Linux or Tenable Virtual Appliance which is Based on Linux

If you want to deploy Agents in a similar environment and are not Certificate Savy the following guide to deploy a Trusted Certificate on your Nessus Manager might help you!

Create a PrivateKey and CSR for your Nessus Manager

First we need a PrivateKey for the Webserver. If you do not know why read up on PKI!

The easiest way to do this, especially if you want to chose a custom Hostname for the certificate is with openssl on a Linux or macOS host! It will be possible on a Windows  host as well (google it) and there are also Websites out there that provide this as a service but you should always think about whom you trust to share your private keys with!

openssl genrsa -out hostname.key 2048

Note: the Name of the output file is arbitrary! But it makes sense to call it like the hostname to not mix stuff up!

Important: Do net send out this private Key ever! Just like a private key for SSH a private key for a Webserver Certificate should never be made public!

Important2: RSA is coming under criticism lately – there are newer and better encryption systems than RSA. This discussion is not part of this blogpost but feel free to reasearch alternatives to RSA private Keys!  Also you have to decide if 2048 bits are Strong enough for your environment. Best you read up on your companies Security Guidelines regarding Certificates!

Now that you have a private key you can create the CSR (Certificate Signing Request) that you can then send on to the CA Administrator of the Windows Domain:

openssl req -new -sha256 -key hostname.key -out hostname.csr

You will be asked a couple of questions on what Data should be present in the Certificate with the most important one being the Hostname.

Note: This will create a CSR without an AltSubjectName which is nowadays required by Chrome. So if you want a Certificate that is trusted in Google Chrome (the Nessus Agents wont care!) you have to awkwardly pass on the SubjectAlternateName via a config file as for example described here.

Again: Never send out the Private Key alongside the CSR! Only the CSR itself!

If you ever want to check the content of a CSR, for example to check if the SubjectAlternateName was included properly you can use the following command:

openssl req -text -noout -verify -in hostname.csr

Request a Signed Certificate Chain from the Windows Domain CA Administrator

A lot of companies are running Windows CA’s. Send the generated .csr (not the key!) to the CA Admin and request specifically that they create:

  • A p7b Certificate Chain in base64 Encoded format!

The default under Windows is often Binary encoded which will not be compatible with the next steps. In the end if you are an OpenSSL/Certificate expert you can convert nearly any format to any other format, however if you are an expert you probably would not read this article, so make sure you get a base64 encoded p7b Chain!

Convert the p7b Chain in individual separate Certificates

The p7b file will contain the entire chain in a Single file which will look / start like this:

$ head hostname.p7b


To feed this chain to the Tenable Virtual Appliance and a lot of Linux Setups you have to split this chain up in individual certificate files with the following command:

openssl pkcs7 -print_certs -in hostname.p7b -out hostname-chain.cer

The resulting .cer file will include 2-3 (possibly even more) separate Certificates depending on how long the Chain is (how many subCAs there are in between the RootCA and the Server Cert).

This will look like this:




Split this Textfile in 3 separate textfiles each time after —-END CERTIFICATE—–. The Subject and Issuer lines above the Certificate and the Commands (Begin/End) can stay in the files to make it easier to identify the content of the file for a human.

Save the three textfiles as:

  • hostname.cer (the server certificate)
  • subca.cer (if a subca was present)
  • rootca.cer (always has to be present – it has signed the cert!)

Note that you actually have a fourth file: hostname.key which is the matching private key for the server certificate.

Install the Certificate

Now that you have all the required files you can go ahead and install the Server Certificate:

On The legacy tenable Virtual Appliance

See:  https://docs.tenable.com/appliance/4_8/Content/4.8_GuideTopics/CertificateManagement.htm?Highlight=certificate 

Navigate to Applications -> Nessus -> and Scroll Down to the Certificate Settings:


Now provide the four files (Intermediate Certificates = SubCA Certificates).

Note: If there is more than one SubCA/IntermediateCA dont split the SubCA Chain, leave all SubCA certificates in one file to be uploaded here!

After providing the four files and clicking Install Server Certificates you will see a green Success Message at the top of the screen, and this Dialoge will show the newly installed certificates information.

Important: Note down the “Not Valid After” Date somewhere, best you set a reminder in you calendar, als your entire Agent Setup will stop to work if you let the Certificate expire! Best will be you keep the four files save and 4 weeks before the expiration date you create a new Set of files / server certificate and replace the old one. If you make a mistake you can always quickly roll back to the old files and troubleshoot what you did wrong.

You still have to do one last step! The Nessus Manager will also verify the Clients Computer Certificate which is also signed by the Windows CA. However you have to specify the RootCA as trusted for this separately in the lower section of the above already shown dialogue:


Here you only have to provide the RootCA Certificate which is the same one from the four files you created above!

Note: This is basically just the public Certificate of the RootCA which can be found publicly everywhere on the Domain! It will help Nessus Manager to validate the trust for the Clients Computer Certificate.

On The new tenable Core Virtual Appliance

See: https://docs.tenable.com/tenablecore/Nessus/Content/TenableCore/ServerCertificate.htm

The Steps are basically the same why I will not post another set of screenshots here. Just follow the guide above and upload the four files and also the trusted CA again:


Important: Make sure to notice that the Core Appliance also keeps two different sets of Certificates (one for the Core Appliances Webinterface on Port 8000 and one for Nessus Manager on Port 8834). Make sure to upload it at least to the Nessus Manager Configuration but feel free to also deploy it to the Core Appliance Webinterface.

Thats it!

If this helped at least one person struggling out there im happy! Feel free to ask questions in the comments below if you encounter an issue with this guide and I will be happy to advance it where necessary!


About SebastianB

read it in my blog
This entry was posted in tenable and tagged , , , , , . Bookmark the permalink.