Table of Contents

• Overview
• Understanding Certificates, general X.509 info, format and structure
• PEM decoding
• Nessus and Tenable Certificate installations
• Command Line Utilities
• Resources
• Troubleshooting

Overview:

The Tenable / Nessus OVA products provide applications that are built on top of an appliance operating system.  The access to the operating systems web UI as well as the application web UI run on separate web instances.  Securing communications with these instances protects the login password and configuration information passed to the service and OS thus protecting from password harvesting and TCP session hijacking.  This document is meant as a guide to assist systems and services administrators in the installation of Rice public key certificates for that purpose.

The Tenable/Nessus products can leverage a single X.509 publicly rooted certificate with authentication and web usage definitions to accomplish securing TLS authentication and web session traffic if it is set up correctly.  

NOTE: The CERTIFICATE FOR A CHILD NODE MUST BE SET UP BEFORE LINKING TO THE PARENT

Understanding Certificates, general X.509 info, format and structure:

Certificates are text blocks that reference a chain of the asymmetric keys generated to encrypt hashes of the text blocks.  This is accomplished by submitting a block of specifically formatted text called a Certificate Signing Request (CSR) to a Certificate Authority (CA) for signature.  The CA is a private or commercial entity that conforms to a rigorous process for generating and storing asymmetric keys related to their signing chain.  The keys are a mathematically generated pair of numbers that when used together form an encryption process that is extremely difficult to defeat.  The CSR process generates a key pair for the cert locally and submits the public key to the CA along with the text and a hash of the text encrypted with the requesting parties private key. The CA then uses its private key to encrypt a hash of the CSR and adds that encrypted hash and a public key of the server and its public key.  This is called the Chain of Trust and each level is called a trust anchor that can be multiple levels deep.  Rice certificates generally have 3-4 level trust anchors that are provided back to us in the form of Base 64 encoded files per the spec, one for each signed trust anchor.  

PEM decoding

Privacy Enhanced Mail is a base 64 encoded text format where each line is a maximum of 64 characters.  The contents of each encoded block of data start with " -----BEGIN <CERTIFICATE | PRIVATE KEY>-----" followed by varying numbers of lines of at least 64 charters and ending with the line "-----END <CERTIFICATE | PRIVATE KEY>-----. This standardizes the data in the certificate to make it universally usable which was why it was chosen for use in the X.500 protocols.  When you have a file in this format it is not readable until it is decoded.  There are online tools that can be found by searching the web for "PEM decoders".  If you are familiar with the CLI tools for openssl you can use "openssl x509 -in <your PEM file path and name> -text -noout" to produce the decoded information to help identify which certs belong to which files.  You will need to be able to decode the Base 64 encoded files to verify that your file represents a CA, an Intermediate, a Private Key, or a server Certificate.

Example Base 64 encoded private key file

-----BEGIN PRIVATE KEY-----
MIIJQwIBADANBgkqhkiG3w0BAQEFAASCCS0wyykpAgEAAoICAQDd3K+o+X7TK0E/
dRLAEx5kfimaIp+gNaepuZBggvPsNWusX6k+HFzqaMuWPGayiYhs1eL4+SmCTivyL

.....

-----END PRIVATE KEY-----

Nessus and Tenable Certificate installations

The Tenable/Nessus products can leverage a single X.509 publicly rooted certificate with authentication and web usage definitions to accomplish securing TLS authentication and web session traffic if it is set up correctly.  This installation reduces the workload and management of the products.  To install the certificate you will need the following.  The Server Certificate and Key will be provided as part of the CSR process.  The Key file is the private key for the certificate and should be stored in a secure escrow like Box/ITSO/Keys/Escrow.  All files used in the process should be in (Privacy Enhanced Mail) .PEM or (Certificate File Format).CRT with the appropriate file extension.

• A file containing the Certificate Key (private key) created during the Certificate Signing Request
• A file containing the CA-signed server certificate The certificate will be signed by Internet2 - InCommon and returned by the CA after signing 
  • Common Name: agent-sso-n2.rice.edu (generally the hostname of the system)
    • Issued By: Internet2
    • Issuing Certificate: InCommon RSA Server CA
• A file containing the Intermediate Certificates generally
  • InCommon
    • Common Name: InCommon RSA Server CA
    • Issued By: The USERTRUST Network
    • Issuing Certificate: USERTrust RSA Certification Authority
  • USERTrust
    
    • Common Name: USERTrust RSA Certification Authority
    • Issued By: Comodo CA Limited
    • Issuing Certificate: AAA Certificate Services
• A file containing the Root Certificate Authority in PEM format
  • AAA Certificate Services 
    • Common Name: AAA Certificate Services
    • Issued By: Comodo CA Limited
    • Issuing Certificate: AAA Certificate Services

As you can see the chain of trust includes three trust anchors.  The root CA was Comodo AAA, who signed the UserTrust Intermediate, who signed the InCommon Intermediate signed the server certificate for Rice.

NOTE: For nessus agent installation it is CRITICAL that the agent installation includes the root CA so that trusted and encrypted communications can occur between the client's nessus agent and the Nessus Agent Manager server.  A root CA pem file will need to be distributed to the groups that install or deploy the agents.

At some point, you may need to verify that a specific private key is paired with the correct certificate.  These two openssl commands x509 and RSA can validate that a private key is associated with a specific certificate by generating the MD5 checksum for the modulus of each allowing you to compare the two.  If the output matches then the private key and the certificate are appropriately paired.  If they don't match, you have the wrong pairing of cert to a key or there is some other problem like an incomplete PEM file on one or the other.

openssl x509 -noout -modulus -in cert.pem  |openssl md5
(stdin)= e7cf2270bbeb6288c100a2e4345591c0

openssl rsa -noout -modulus -in key.pem  |openssl md5
(stdin)= e7cf2270bbeb6288c100a2e4345591c0

At the end of this process, you should have 4 separate files.  Each should be specifically named as shown

To implement this certificate stop the nessus service copy the files into the directory and restart the nessus service

These files exist for the web service on port 8834 and should exist in the directory /opt/nessus/com/nessus/CA/ 

1. servercert.pem = the PEM encoded certificate for the server.  The PEM block should only include the signed certificate for the server.
2. serverkey.pem = the PEM encoded public key for the server.  
3. cacert.pem = the PEM encoded Root CA or top-level anchor certificate (Comodo AAA Certificate)
4. serverchain.pem = the PEM encoded intermediate certificates (InCommon and UserTrust)  these are 2 PEM blocks in the same file

NOTE: The cacert.pem file can contain the entire root CA chain.  I found this to be the more efficient way to execute the certs.

Command Line Utilities

To install a certificate for the Nessus web applications the following CLI is provided.  Stop the Nessus service first.  Now that you have the files identified, separated, and available to the servers you can use the nessuscli command to install them for the application.  This command line will install a certificate and its private key along with the trusted root that it is anchored BUT NOT the Intermediate certs.  I found a reference buried as a comment in the docs that said to put the Intermediates in a file called serverchain.pem.  I also noticed that the command line would take the cacert with the full chain so did both.  The elements between the <.... path> are the file path and name of the key pem file, certificate pem file, and root CA pem file.

In linux use /opt/nessus/sbin/nessuscli import-certs --serverkey=<server key path> --servercert=<server certificate path> --cacert=<CA certificate path> 

Example:

/opt/nessus/sbin/nessuscli import-certs --serverkey=/home/admin/CERTS/agent-sso-mgr.rice.edu.key --servercert=/home/admin/CERTS/agent-sso-mgr_rice_edu_cert.cer --cacert=/home/admin/CERTS/agent-sso-mgr_rice_edu_interm.cer
Saving a copy of the old key and certs and importing the new ones.
Confirming imported key and certs.
Successfully imported key and certificates.

https://docs.tenable.com/nessus/Content/UploadACustomServerAndCACertificate.htm

For the system certificate copy the cacert.pem, serverkey.pem and servercert.pem to the /etc/pki/tenablecore and restart the cockpit service and start the nessus service. Then validate the changes by browsing to the servers on ports 8000 and 8834 as appropriate.

You can also use wget command line tools to verify the certificate is functional and that the certificate chain is appropriate

curl -k https://<hostname>:<8334 or 8000>/getcert

Resources

• https://community.tenable.com/s/article/Nessus-Manager-Clustering-General-Information
• https://docs.tenable.com/nessus/Content/UploadACustomServerAndCACertificate.htm
• https://www.sslshopper.com/certificate-decoder.html
• https://stackoverflow.com/questions/9507353/how-do-i-install-and-use-curl-on-windows
• https://docs.tenable.com/nessus/Content/GettingStarted.htm
• https://kb.rice.edu/internal/page.php?id=118292
• https://docs.tenable.com/nessus/Content/Certificates.htm