Last updated at Thu, 20 Jul 2017 19:22:55 GMT

The Nexpose 5.12 release included many enhancements, which you can read about in Nexpose release notes -  January 2015. In this blog post I'll focus on the changes made to TLS/SSL scanning in particular.

Custom Root Certificate Authority Certificates

First I'd like to go over the new feature that allows you to import your internal root CA certificates to Nexpose. For internal scans where your systems are likely to use a corporate certificate authority, which would not be included in any public trust stores, Nexpose can now identify your internally signed certificates as trusted. In future updates, Nexpose will use the latest public root CA certificates as trusted by modern web browsers as well. If you can't wait and have some scans where valid certificates are not currently trusted by Nexpose, you can also import public root CA certificates.

Note that while intermediate CA certificates can be imported, they will not change scan results if the root CA certificate is not already trusted. In general your assets' TLS/SSL services should be configured to present the full certificate chain as instructed by your signing authority, and the root of that chain must be trusted by Nexpose.

To import a root CA certificate into Nexpose, navigate to Administration and select the manage link next to Root Certificates - at the bottom right of the Scan Options section. You can also use the keyboard shortcut by typing R and then M while on the Administration page. Note: The Configure Global Settings permission is required to add or remove certificates, however any user with access to the Administration page can view certificates.

Then click the Import Certificates button and paste one or more PEM format root CA certificates into the dialog. Click the Import button to complete the process.

Imported certificates will be used by local and remote scan engines automatically. Note: Remote scan engines must have product version 5.12 or later to use the imported certificates during a scan.

X.509 Certificate Subject Alternative Names and other details

Another enhancement in Nexpose 5.12 is support for the Subject Alternative Name extension in SSL/TLS certificates. This means that an asset with a host name, fully qualified domain name (FQDN), or IP address that does not match the certificate's Common Name (CN), but does match one of the Subject Alternative Names (SAN) will not be flagged as having a name mismatch on the certificate. Along with this change new information is being stored in the Service Configuration details for an asset's service:

  • Subject Alternative Name(s)
  • Certificate's SHA1 fingerprint
  • Certificate's X.509 certificate version (as of Nexpose 5.12.2)

The service configuration information is also available in the reporting data model, so you can query for all of this information with a SQL Query Export report. Here is what it looks like in the web interface for an HTTPS service:

Vulnerability Checks Affected

The following vulnerability checks were updated in the 5.12 release to take advantage of these enhancements:

  • Untrusted TLS/SSL server X.509 certificate (tls-untrusted-ca)
  • X.509 Certificate Subject CN Does Not Match the Entity Name (certificate-common-name-mismatch)

The proofs for these vulnerabilities have also changed. The Untrusted TLS/SSL server X.509 certificate proof no longer contains the list of trusted certificates now that this information is available from the root certificate management page. This reduces the amount of space taken up in the interface and reports for this vulnerability. The X.509 Certificate Subject CN Does Not Match the Entity Name proof will contain additional items if a certificate has Subject Alternative Names, but the asset's host name, FQDN, or IP address does not match any of them.