Certificates

runZero collects TLS certificates automatically during active scans and passive network monitoring. It stores them in the Certificates Inventory, which you can open from the Inventory menu, Certificates sub-menu. Most TLS certificates come from web servers, but runZero also collects them from SMTP, RDP, and other TLS-aware services.

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

A certificate has an issuer, the authority that signed it. When the issuer is the same as the subject, runZero marks the certificate as self-signed.

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 its key size, shown in bits, and how large a secure key must be varies by algorithm. An RSA key should be 2048 bits or larger to count as secure, while every ed25519 key is 256 bits, and that is considered secure.

Each certificate in the inventory view has a button to hide it from the inventory, which can be useful for embedded devices whose certificates you can’t change and don’t want to see. To see which certificates you’ve hidden, search for hidden:true. The certificate inventory keywords cover the other ways to search and filter certificates.

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, which hold the values web browsers check when connecting to a server. A certificate stores SANs in separate fields by type (DNS, IP, email, or URI).
• The Common Name, which web browsers once used but now ignore. It is typically in X.509 format.

The Names runZero shows for a TLS certificate combine the four kinds of SANs plus the Subject DN.

Each TLS certificate has a subject key ID that identifies the certificate’s subject and an authority key ID that identifies the signing authority. These IDs link certificates into a chain: the authority key ID of each certificate is the subject key ID of the next certificate in the chain.

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

TLS certificates have a flag that says whether they are intended for use as a certificate authority or (CA). The flag doesn’t mean the certificate is a CA or that it is trusted, only that the flag is set. CA certificates are usually self-signed.

The values runZero shows for TLS certificate algorithms mostly come from RFC 5280 and should correspond closely to the values OpenSSL uses.

The self-signed value shows whether a certificate appears to be self-signed, based on its issuer, subject, and (if present) their IDs. A certificate flagged as apparently self-signed may still fail signature validation in some software, because different software applies stricter or looser 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.