Product release

Elastic Uptime Monitoring 7.8.0 released

We are pleased to announce the release of Elastic Uptime Monitoring 7.8.0 — available on Elasticsearch Service, or when you download the Elastic Stack. This release brings several TLS certificate monitoring and alerting features.

New certificate-focused capabilities in 7.8

One of the main use cases of Elastic Uptime and Heartbeat is managing large deployments of servers or containers. Heartbeat has automatically captured some information about TLS certificates for a while. And when I say automatic, I mean other than pointing Heartbeat at the URL or endpoint to be monitored, Uptime users didn’t have to do any additional configuration or work to automatically start monitoring the certificates. 

Several releases ago, Uptime added a small visual indicator within the details page for each monitor that showed how long it was before the certificate for that monitored URL would expire. This was really useful context, but it wasn’t the most efficient way of coming in to solve the problem of “What certificates do I have and when do I need to do something to renew them?” — especially for users with larger numbers of monitors.

To help solve this problem, we are very excited to announce that we’ve improved Heartbeat and also added four key areas of certificate-focused capability to the Uptime app in 7.8. 

  1. The first improvement is calling out the certificate expiration on the Monitors Overview page in a dedicated column — great for that “at-a-glance” view of your monitors and which ones may need attention. 
  2. The second thing we did was create a new “certificate focused” view within Uptime: a single source of truth for all of your certificates on monitored URLs and endpoints. Instead of a listing of monitors, we have created a listing of every single certificate, their status, which monitors it’s related to, who the issuing authority is, when it is valid to, and how old it is, as well as exposing the SHA1 and SHA256 fingerprints in a single view. 
  3. The third thing we built was the ability to specify your own expiration threshold. This determines how far away from expiration we highlight your certificate as being “about to expire.” As a bit of future proofing, we’ve also enabled setting an upper threshold for age as some browsers, like Safari and Mobile Safari, will begin to mark a certificate as invalid if it’s too old, even if it’s still technically valid. 
  4. And finally, to expand on the fantastic Kibana alerting capabilities that shipped in 7.7, we can alert you if you’ve got a certificate that’s about to expire. Uptime will automatically configure the alert based on that expiration threshold you have in settings. This way, if you get an alert and go into the Uptime portal, the conditions will match.

tls-monitoring.gif

Why does certificate monitoring matter?

Certificates, often interchangeably referred to as SSL certificates, TLS certificates, or more accurately, X.509 certificates, are small data files that cryptographically bind a domain, server, or hostname to an organizational identity or location. They are most commonly found securing encrypted communication from a web server to a browser. They also have a defined valid lifespan and must be renewed. If they are not renewed, an expired certificate can cause a series of cascading errors that will prevent services that require secure connections from working properly. Although expired certificates are a totally preventable problem, that doesn’t stop them from causing issues. 

As systems move from monolithic structures to microservice architecture, there’s an ever-increasing volume of certificates to manage. A 2019 survey of CIOs from the US, UK, France, Germany, and Australia found that 60% of their organizations had experienced a certificate-related outage that impacted critical business applications or services within the last year. 

A recent high-profile outage in February 2020 involved an expired certificate on an authentication server that Microsoft used to power their Teams app. It took over eight hours to fully restore the service. While this outage was inconvenient and probably cancelled a few meetings, sometimes these outages can be critical. In November 2018, an expired certificate in a key piece of network management software used by a major mobile phone carrier in the UK resulted in a cascading series of failures that took out all voice, data, and SMS service for nearly 24 hours. This impacted not only their customers but also those of every Mobile Virtual Network Operator (MVNO) that used the network. All told, over 32 million customers had no use of their mobile phones. As many people no longer have landlines, being unable to use a mobile phone as a lifeline in an emergency or as an outside connection in the middle of a global pandemic lockdown can have a potentially devastating impact.

When you look at this problem and the potential impact, it’s clear why we wanted to help our users know what certificates they have deployed, when they expire, and to proactively alert them to when this is about to occur.

Want to see it in action?

You can access the latest version of the Elastic Uptime application on Elasticsearch Service on Elastic Cloud by creating a new cluster, upgrading an existing cluster the day of release, or by downloading the Elastic Stack.

Related blogs