TLS Certificates Discovery

TLS (Transport Layer Security) is a type of cryptographic protocol that uses certificates to provide authentication and data encryption between servers, devices, and applications operating over the network. An everyday use of TLS is to secure connections from a web server to a user browser. Discovery collects information about the used certificates and represents them as Certificate nodes.

Note: Since TKU May 2025 certificates are modeled using its own Certificate node, not Detail node, as it was in earlier TKU versions. All the attributes stay the same.

An example of the Certificate node modeling:

Supported node types

Software instances

Before you begin
Make sure that the following is available: SSL sockets information is available. (listen_ssl_tcp_sockets attribute populated)

TLS Certificates can be modeled for the following Software Instances:

Apache Tomcat Application Server
Oracle GlassFish Server Domain Administration Server
Oracle GlassFish Server
Oracle WebLogic Server
BEA WebLogic Application Server
HP OpenView Operations Agent
HP Operations Agent
IBM WebSphere Application Server
Red Hat JBoss Application Server
WildFly
Apache NiFi
Cloudera NiFi
Apache NiFi Registry
Cloudera NiFi Registry
Control-M/Server
Control-M/Agent Listener
IBM Sterling B2B Integrator
Software AG webMethods Integration Server

Expected attributes	TLS Certificate view	SI node view
start_date expiry_date sha_256_fingerprint issuer subject_alternative_name organization organization_unit serial subject self_signed common_name key name short_name type = "TLS Certificate" Optional attributes: public_key_size ca authority_key_id public_key_algorithm subject_key_id signature_algorithm

Webserver Software Instances

Before you begin
Make sure that the following is available: Website Software Component is modeled for such SI. Website Software Component has SSL sockets information available. (listen_ssl_tcp_sockets attribute populated)

TLS Certificates can be modeled for the following Software Instances:

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
Microsoft IIS Webserver
Nginx Webserver

Expected attributes	TLS Certificate view	Webserver Software Instance view
start_date expiry_date sha_256_fingerprint issuer subject_alternative_name organization organization_unit serial subject self_signed common_name key name short_name type = "TLS Certificate" Optional attributes: public_key_size ca authority_key_id public_key_algorithm subject_key_id signature_algorithm

Load balancer services

Before you begin
Make sure that the following is available: SNMP credentials enabled for F5 LB. For more information, see TLS Certificate Discovery for F5. SSL sockets information or .pem file location is obtained for each LB Service for HAProxy LB.

TLS Certificates can be modeled for the following Load Balancer Services:

F5 Load Balancer Service
HAProxy Load Balancer Service

Expected attributes	TLS Certificate view	Load Balancer service view
start_date expiry_date sha_256_fingerprint issuer subject_alternative_name organization organization_unit serial subject self_signed common_name key name short_name type = "TLS Certificate" Optional attributes: public_key_size ca authority_key_id public_key_algorithm subject_key_id signature_algorithm

Hosts

Windows Hosts

Before you begin
Make sure that the following is available: Windows-like operating system. Host should have Discovery Access. i.e. Not applicable for ADE or API discovered host nodes. Approach valid only for Certificates located in \LocalMachine\My store. These are Local Machine certificates. i.e. Storage location : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\My\Certificates. Via Certmgr.msc navigate to Personal folder of the Local Computer.

Before you begin

Make sure that the following is available:

Windows-like operating system.
Host should have Discovery Access. i.e. Not applicable for ADE or API discovered host nodes.
Approach valid only for Certificates located in \LocalMachine\My store. These are Local Machine certificates. i.e.

Storage location : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\My\Certificates.
Via Certmgr.msc navigate to Personal folder of the Local Computer.

Windows Certificates can be modeled for the following Hosts:

Windows Hosts

Expected attributes	Windows certificate view	Host node view
key name common_name short_name type = "Windows Certificate" start_date expiry_date thumbprint issuer subject_alternative_names organization organization_unit serial subject self_signed friendly_name has_private_key = True/False Extensions: subject_key_id key_usage certificate_template_information application_policies etc.

Linux Hosts

Before you begin
Make sure that the following is available: Linux based operating system. Host should have Discovery Access. i.e. Not applicable for ADE or API discovered host nodes. Approach valid only for IPsec Certificates.

IPsec Certificates can be modeled for the following Hosts:

Linux Hosts

Expected attributes	IPsec certificate view	Host node view
key name common_name short_name type = "IPsec Certificate" start_date expiry_date sha_256_fingerprint fingerpirnt issuer subject_alternative_names organization organization_unit serial subject public_key_algorithm signature_algorithm public_key_size ca authority_key_id subject_key_id

Management Controllers

Before you begin
Make sure that the following is available: HP iLO Web API credentials enabled. SNMP credentials for Dell iDRAC.

ManagementController Certificates can be modeled for the following Hosts:

For ADDM versions prior to 22.1: only HP iLO devices are supported (TLS certificates are discovered using the Redfish API).
Newer ADDM versions support any ManagementController device with an HTTPS interface (TLS certificates are discovered using getCertificate function).

Expected attributes	TLS Certificate view	ManagementController node view
key name common_name short_name type = "TLS Certificate" start_date expiry_date fingerprint issuer organization organization_unit serial subject

Extended certificates discovery

In TKU May 2025, extended TLS Certificates discovery has been released. It does not introduce new Discovery methods, just the approach of relying not on the discovered software, but on discovered listening connections.

The pattern will iterate over a list of ports from the extended TLS discovery configuration and will try to get TLS certificate if there an associated listening TLS sockets. The pattern will try to avoid extracting TLS certificates for TLS sockets that are already related to Software Instances or websites.

This approach allows you to get a Certificate when the standard TLS discovery did not work for some Software Instances or is not yet supported. All created certificates will be linked directly to the related Host.

By default, extended TLS discovery is enabled. The desired list of known TLS ports can be configured in the pattern configuration SSLDiscovery.Extended.TLSConfig by changing the parameter "default_tls_ports".

Extended TLS discovery can be completely disabled if needed by setting "enabled" to false in SSLDiscovery.Extended.TLSConfig pattern configuration.

Discovery methods

This paragraph describes methods used by Discovery to get Certificate information. Discovery runs an OpenSSL command to the open SSL socket, taken from the listen_tcp_ssl_sockets attribute of the SI or the Website Software Component. Also, the OpenSSL command may take the .pem file location (obtained from the configuration file) to get certificates. This approach is used for HAProxy LB Services.

Commands

In case SSL sockets information is available for Software Instance or Load Balancer Service node the following command is executed:

which openssl > /dev/null 2>&1 && echo | openssl s_client -connect %listen_ssl_tcp_socket% | openssl x509 -inform pem -noout -nameopt oneline -subject -startdate -enddate -issuer -fingerprint -sha256 -serial -text

If the . pem file path value is extracted for HAProxy Load Balancer Service, the following command will be executed to read the certificate file:

which openssl > /dev/null 2>&1 && echo | PRIV_RUNCMD openssl x509 -inform pem -noout -nameopt oneline -subject -startdate -enddate -issuer -fingerprint -sha256 -serial -text -in %esc_pem_file%

Please note that the second command doesn't reveal keys and will be executed with sudo. Hence Discovery users should be included in the sudoers file.

To avoid any unwanted insecure execution of the pem-file-command the following code may be added to your sudoers file:

Cmnd_Alias LSCERT=\
/usr/bin/openssl x509 -inform pem -noout -nameopt oneline -subject -startdate -enddate -issuer -fingerprint -sha256 -serial -text -in /*,\
!/usr/bin/openssl x509 -inform pem -noout -nameopt oneline -subject -startdate -enddate -issuer -fingerprint -sha256 -serial -text -in /* *,\
!/usr/bin/openssl x509 -inform pem -noout -nameopt oneline -subject -startdate -enddate -issuer -fingerprint -sha256 -serial -text -in /..

DiscoveryUser ALL=(root) NOPASSWD: LSCERT

For Windows Hosts the following PowerShell commands will be executed:

To get all Windows Certificates:

Get-ChildItem -Path Cert:\LocalMachine\My | ForEach-Object {'Thumbprint : {0}' -f $_.Thumbprint; 'Subject : {0}' -f $_.Subject; 'NotAfter : {0}' -f $_.NotAfter.ToString('yyyy-MM-dd HH:mm:ss'); 'NotBefore : {0}' -f $_.NotBefore.ToString('yyyy-MM-dd HH:mm:ss'); 'Issuer : {0}' -f $_.Issuer; 'HasPrivateKey : {0}' -f $_.HasPrivateKey; 'SerialNumber : {0}' -f $_.SerialNumber; 'FriendlyName : {0}' -f $_.FriendlyName; 'DnsNameList : {0}' -f ($_.DnsNameList -join ', '); 'SplitSection';}

2. To Get extensions for each Certificate:

Get-ChildItem -Path Cert:\LocalMachine\My | ForEach-Object {'Thumbprint: {0}' -f $_.Thumbprint; ($_.Extensions | ForEach-Object {'FieldsSplit'; 'Ext Field: {0}' -f $_.Oid.FriendlyName; 'Ext Value: {0}' -f $_.Format(1)}); 'SplitSection';}

To get a list of IPsec certificates and details on each certificate the following commands will be executed:

certutil -L -d sql:/etc/ipsec.d
certutil -L -d sql:/var/lib/ipsec/nss
certutil -L -d sql:/etc/ipsec.d -n '%cert_name%' -a | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -inform pem -noout -nameopt oneline -subject -serial -startdate -enddate -issuer -fingerprint -sha256 -text
certutil -L -d sql:/var/lib/ipsec/nss -n '%cert_name%' -a | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -inform pem -noout -nameopt oneline -subject -serial -startdate -enddate -issuer -fingerprint -sha256 -text

discovery.getCertificate

Important

This function works only if the TLS port of the Discovery target is accessible to BMC Discovery or BMC Outpost.

TLS Certificate information may be retrieved using the built-in discovery.getCertificate function. This function has been introduced for Discovery v12.4 (22.1).

New sha_256_fingeprint and used_ssl_version attributes have been introduced for Discovery v23.1.

A Discovered Certificate node stores information about a TLS certificate retrieved from a target. For more information, see discovery.getCertificate and Discovered Certificate node.

Modeling and CMDB sync

The certificate is modeled as a Certificate node and linked to a related Software Instance, Load Balancer Service, or Host node. Using a search, you may find the needed Certificate with detailed information.

Generic Search Query example

search Certificate
       show
       key,
       name,
       common_name,
       short_name,
       start_date,
       expiry_date,
       sha_256_fingerprint,
       issuer,
       subject_alternative_name,
       organization,
       organization_unit,
       serial,
       subject,
       self_signed,
#Certificate:Certificate:ElementWithCertificate:SoftwareInstance.name as "SI Name"

The Certificate node is synchronized to the CMDB OOB as a mapping attribute DocumentType "TLS Certificate" or "Windows Certificate". For more information, see BMC_Document.

An example of the dashboard view: