Facebook Google Plus Twitter LinkedIn YouTube RSS Menu Search Resource - BlogResource - WebinarResource - ReportResource - Eventicons_066 icons_067icons_068icons_069icons_070

Tenable Blog

Subscribe

SSL Certificate Authority Auditing with Nessus

Note: This blog was updated in March 2021 to include additional guidance on how customers can address custom certificate authorities.

Do you know where all of your organization’s SSL certificates are and if they are providing enough protection to you and your customers? Nessus can be used to identify all SSL certificates in use, test if they are expired and with the advent of plugin # 51192, test that they have been securely signed by a valid certificate authority. This blog entry will review Nessus’s SSL certificate auditing ability and describe how plugin #51192 can help monitor your network for untrustworthy SSL certificates.

A previous blog (see “Continuous SSL Certificate Monitoring - not just for HTTPS”) described Nessus’s many different SSL certificate discovery and auditing abilities. In summary, they were:

  • SSL/TLS detection (multiple checks)
  • Supported algorithms and key strengths (#10863, #21643)
  • The presence of insecure ciphers or hashes (#26928 and #35291)
  • Signature signing algorithms (#10863 and #31705)
  • SSL certificate validity and expiration (#15901, #42980 and #42981)
  • SSL certificate common name (#45410 and #45411)
  • Low entropy Debian keys (#32321)

A key principal of Nessus’s ability to audit and discover SSL certificates is port independence. It is common to think that “SSL” is synonymous with secure web browsing, port 443 and Internet shopping. However, SSL certificates are used in secure IMAP systems, on FTP servers, on secure web servers not running on port 443, on VPNs and many other places.

Auditing which services have trustworthy SSL certificates is another important security test performed by Nessus with plugin #51192.

Without a signed certificate, anyone could set up a fake web site and pretend to be a legitimate organization such as Walmart, Google or your bank. SSL certificate signing by a Certificate Authority prevents these types of attacks. The idea is to use cryptography to “sign” an SSL certificate from one or more trusted authorities. Public certificates from trusted sources are bundled into web browsers such as Internet Explorer, Chrome and Firefox. Following is a screen shot of some of the certificates trusted by my local Internet Explorer:



When organizations want to offer a secure service, such as email, web, file transfer, VPN or other type of information sharing protocols, they can purchase an SSL certificate that has been signed by a third party such as VeriSign, Microsoft, GoDaddy, Thawte and many others.

SSL certificates can also be generated for private secure communications. Many open source applications, vendor appliances and commercial software  will generate unsigned SSL certificates. These offer protection from malicious users eavesdropping on the communication, but no protection from impersonation or man-in-the-middle attacks.

As previously stated, Nessus has many checks for SSL certificates; however, plugin #51192 ensures that each discovered SSL certificate was signed by a trusted Certificate Authority. Organizations must decide if their secure services protected by SSL require a signed certificate or not. In some cases, such as with PCI-compliant e-commerce web sites, use of signed SSL certificates is mandated by compliance requirements. In other cases, it is just good security to guarantee the integrity of your communications.

Following is an example report of a Nessus audit of the Nessus web server I have running on port 8834:

The SSL certificate generated by Nessus is not signed by any of the common public certificate authorities. This isn’t really a big deal for me because I run my own Nessus scanner. It’s possible someone could spoof my scanner in the future, but I’ve already accepted the certificate from this Nessus scanner, which protects me from man-in-the-middle attacks.

Tenable realizes that many organizations generate their own SSL certificates and have their own certificate authorities. It is common practice for large enterprises to configure SSL certificates in their employee’s web browsers to ensure access to file sharing, VPN, email and web portals. If custom certificate authorities are needed as part of this audit, we recommend reaching out to your vendor to discuss how to configure these for your environment. You can also visit the Tenable Community to seek advice from other Tenable users who have set up this configuration.

A great way to learn more about this plugin is to make it part of your existing scans. On my own lab network, it was interesting to see unsigned SSL certificates on a variety of applications and devices including my VMware server, a bunch of file-sharing services, my Nessus scanners and more.

To learn more about SSL auditing, please read the “Continuous SSL Certificate Monitoring - not just for HTTPS” blog entry that describes many of the basic forms of SSL certificate discovery and security issues. SSL auditing can also be accomplished in real-time on any port through direct network traffic analysis with the Passive Vulnerability Scanner. We recently held a webinar that details how this can be accomplished and the recorded session is available here.

 

 

 

 

 

 

 

Related Articles

Cybersecurity News You Can Use

Enter your email and never miss timely alerts and security guidance from the experts at Tenable.