The certificates inventory

As the runZero Explorer scans your network, it collects encryption certificates that it encounters. These are stored in the certificates inventory, which you can access from the Inventory menu, Certificates sub-menu.

The primary source of certificates on most networks will be TLS certificates on web servers. However, the Explorer will also collect certificates from other services, such as SMTP, RDP and DNS-SD.

Certificates have a validity period. In the inventory view, the Valid from and Valid until values are color coded to show if the certificate is not valid yet, has expired, or is soon to expire.

A certificate has an issuer, the authority which signed the certificate. The issuer may be the same as the subject, in which case the certificate will be marked as self-signed certificate.

Certificates rely on two kinds of algorithms:

• The public key algorithm, used for decryption and verification.
• The signature algorithm, used to produce a content hash that is signed using the public key algorithm.

The security of a public key algorithm depends on the key size. This is shown in bits. How large a key is considered secure will depend on the algorithm. For example, for RSA a key size should be 2048 bits or larger to be considered secure; whereas for ed25519, all keys are 256 bits, and that’s considered secure.

The certificate inventory view has a button for each certificate to hide it from the inventory. This can be useful for embedded devices that have certificates you can’t change, that you don’t want to see in the inventory. If you later decide you want to see which certificates you’ve hidden, you can use the search query hidden:true.

TLS certificates

TLS certificates have three sets of names for their hosts:

• The Subject, an X.509 distinguished name (DN) made up of one or more attributes, each with a value.
• The Subject Alternative Name lists. These provide the values web browsers check against when connecting to a server. SANs are stored in a certificate in separate fields by type (DNS, IP, email or URI).
• The Common Name, which was once used by web browsers but is now ignored by them. It is typically in X.509 format.

The Names shown in runZero for a TLS certificate are assembled from the four different kinds of SANs, plus the Subject DN.

Each TLS certificate has a subject key ID used to identify the subject of the certificate, and an authority key ID used to identify the signing authority. These are used to link certificates together in a chain — the authority key ID of each certificate is the subject key ID of the next certificate in the chain.

The issuer for a TLS certificate is included as a DN in the certificate.

TLS certificates have a flag to say if they are intended for use as a certificate authority or (CA). The flag doesn’t mean that they are a CA, or that they are trusted; just that the certificate has that flag set. CA certificates are usually self-signed.

The values shown to identify TLS certificate algorithms are mostly taken from RFC 5280, and should correspond closely to the values used by OpenSSL.

The self-signed value indicates whether a certificate appears to be self-signed, based on its issuer, subject, and (if present) their IDs. A certificate may be flagged as apparently self-signed but not have a valid signature according to some software, as different software may implement more or less strict checks.

The certificate details page has a button to download the certificate in PEM format. You can also download the entire chain of certificates known to runZero as a single PEM file.