Understanding Notification Emails

The discovery and monitoring notification emails that are delivered at the conclusion of discovery and monitoring scans both include information about the status of the endpoints scanned, but they present this information slightly differently. The discovery email breaks down what happened when the job attempted to find a certificate at each of the endpoints it attempted to communicate with. The monitoring email, on the other hand, focuses on monitoring the status of the certificate that is expected to be at the endpoint An endpoint is a URL that enables the API to gain access to resources on a server.. Although the monitoring email can be used for identifying certificates that are coming up for expiration, other solutions, such as expiration alerts (see Expiration Alerts), may be more useful for this. What the expiration alerts can’t do for you, however, and the monitoring email can, is identify servers that may have gone offline or whose certificate may have disappeared. In other words, expiration alerts monitor certificate status and monitoring alerts monitor endpoint status. See the example in Figure 269: SSL Monitoring Email. This shows three servers that previously had been discovered to have a certificate now being unresponsive. In some cases, the servers or certificates may still be there and the requests for them have just timed out due to slow network connections or other issues, but this provides you with an opportunity to investigate these servers to determine what the problem might be.

The various numbers that are reported in the Discovery and Monitoring emails are described below:

• The number in the subject: The total number of endpoints that have expired/expiring certificates + the total number of endpoints that did not return a certificate.
• Expired/Expiring certificates number: The total number of certificates that are expired or will expire within the next X number of days. The value of X is a configurable setting in Keyfactor Command and is set in the network definition for each network (see the Expiration Alert setting in SSL Network Operations).
• Number of endpoints that did not return a certificate: The total number of endpoints that did not return a certificate.
• Number of rows in each grid: A configurable setting in Keyfactor Command (see the SSL Maximum Email Results application setting in Application Settings: Agents Tab). The number of rows in the grids is not reflected in the total counts.

Table 17: SSL Email Notification Values Defined

Value	Meaning
Timed out while connecting	A timeout occurred when attempting to establish a TCP connection. The timeout interval is defined on the Advanced tab of the SSL network definition page, see SSL Network Operations. The shorter the timeout, the faster the scan goes, but the higher chance that if there is actually something listening at the port, a connection won't be established causing a timeout. If the orchestrator Keyfactor orchestrators perform a variety of functions, including managing certificate stores and SSH key stores. is overloaded (too many parallel tasks), it can add to the time needed to make a connection and increase the chance of a timeout. Network transit time affects timeouts as does the load and speed of the target system in the ability to establish a TCP handshake.
Timed out while downloading	A TCP connection was made and a TLS TLS (Transport Layer Security) and its predecessor SSL (Secure Sockets Layer) are protocols for establishing authenticated and encrypted links between networked computers. connection was started, but it took too long to actually receive the certificate. This is a rare condition. This is a parameter A parameter or argument is a value that is passed into a function in an application. that is locally configurable on the orchestrator and defaults to 15 seconds. This value is displayed in the debug trace.
Connection refused	The target IP and Port are listening, but the TCP connection was actively refused.
Not SSL	A TCP connection was established, but when the first packet of the TLS handshake was sent, it did not get a TLS response, implying that some protocol other than TLS is listening on the target.
Bad SSL handshake	A TCP connection was established and a proper response to the first TLS packet was returned, but something failed in the rest of the TLS handshake. Several of the internal reasons for why a TLS handshake may have failed have been combined along with other counters in the email response.
Certificate found	A TCP connection and a TLS handshake were completed and the TLS handshake returned a certificate (all within the connection and download timeout periods)

Figure 270: SSL Email Notification Values Defined