Share This:

You may have noticed that with TKU 2020-08 we have started to implement a new feature: SSL certificate Discovery:

 

Certificate.png

 

where, for Webservers of types:

"Apache Webserver"

"IBM HTTP Server"

"Oracle HTTP Server"

"HP Apache-based Web Server"

"HP HP-UX Apache-based Web Server"

"Red Hat JBoss Enterprise Web Server"

"Apache HTTPD-based Webserver"

"JBoss Core Services Apache HTTP Server"

"Nginx Webserver"

 

or:

"Apache Tomcat Application Server"

 

we try and connect to connect to TLS port via an openssl command on the target, and thus create a Detail node of type "TLS Certificate". Except, rather embarassingly, for the TKU on 12.0 where we misspell "TLS" as "TSL". Oh dear. I logged defect DRDC1-15692 to address that. The TKU on 11.3 doesn't have this problem.

 

It should also be noted, although not yet in the official docs (logged DRDC1-15728), that this is applicable only for instances running on a Unix-like OS.

 

Query to find near expiry dates

 

You may use a query such as this to show cetificates whose end date is less than 30 days away:

 

search Detail where type matches 'Certificate' and expiry_date < (currentTime() + 30*24*3600*10000000) show start_date, expiry_date, common_name, #Detail:Detail:ElementWithDetail:SoftwareInstance.name as 'Software Instance Name', #Detail:Detail:ElementWithDetail:SoftwareInstance.#RunningSoftware:HostedSoftware:Host:Host.name as 'Host Name'

 

Note that I have used the "type matches 'Certificate'" instead of the more efficient "type = 'TLS Certificate'" until the defect mentioned above is corrected.

 

Assessing Coverage

 

When depending on this information, it is important to know the prerequisites and coverage you are getting.

 

For Apache HTTPDs, we need to have created a "Website" SoftwareComponent off the main SoftwareInstance, and recorded encrypted sockets. This query lists those that have that, but no certificates:

 

search SoftwareInstance where type in ["Apache Webserver", "IBM HTTP Server", "Oracle HTTP Server", "HP Apache-based Web Server", "HP HP-UX Apache-based Web Server", "Red Hat JBoss Enterprise Web Server", "Apache HTTPD-based Webserver", "JBoss Core Services Apache HTTP Server", "Nginx Webserver"] and nodecount(traverse SoftwareContainer:SoftwareContainment:ContainedSoftware:SoftwareComponent where type matches "Website" and listen_ssl_tcp_sockets) and not nodecount(traverse ElementWithDetail:Detail:Detail:Detail where type matches 'Certificate')

 

This set would be good candidates for investigation, perhaps for failing openssl commands.

 

Now, to find Apache HTTPDs where we don't have any Website SoftwareComponents, use:

 

search SoftwareInstance where type in ["Apache Webserver", "IBM HTTP Server", "Oracle HTTP Server", "HP Apache-based Web Server", "HP HP-UX Apache-based Web Server", "Red Hat JBoss Enterprise Web Server", "Apache HTTPD-based Webserver", "JBoss Core Services Apache HTTP Server", "Nginx Webserver"] and not nodecount(traverse SoftwareContainer:SoftwareContainment:ContainedSoftware:SoftwareComponent where type matches "Website")

 

I found my own Fedora webserver is not getting detected; I will report back when I know more.

 

For Apache Tomcat, we need to have recorded some secure sockets. So, we can find all Tomcat instances where we do have these, but no certificates:

 

search SoftwareInstance where type = 'Apache Tomcat Application Server' and listen_ssl_tcp_sockets and not nodecount(traverse ElementWithDetail:Detail:Detail:Detail where type matches 'Certificate')

 

This set would be good candidates for investigation, perhaps for failing openssl commands.

 

This should be only the start of the Certificate Discovery work. While I can't guarentee anything, work is underway to look at other products' certificates, and to map these Detail nodes into the CMDB using the BMC_Document class.

 

But in the meantime, I encourage you to see what coverage you are getting and provide us feedback on what we can improve.