ThousandEyes is part of Cisco   Learn More →
Service Assurance for the New Enterprise Reality


Don't Drop the Ball on TLS Certificates: Why and How Monitoring Helps

By Sumana Mannem
| April 28, 2020 | 10 min read


In this blog, we focus on SSL monitoring—a new capability introduced to detect and alert on common TLS certificate issues that can impact web performance.

Importance of TLS

As it turns out, consumers are an impatient lot. We are likely to abandon a website if a page takes more than 3 seconds to load. For online retailers, a 100-millisecond delay in website load time can hurt conversion rates by 7 percent! Website performance is often characterized by Response Time: how quickly a web server is able to respond back to a client’s request for a web resource while factoring in external dependencies like network latency, DNS resolution, CDN proxies and server load. As evidenced in our anatomy of an HTTP(s) request blog, performing an SSL handshake (SSL time), is a key component of the response time metric, also called the Time to First Byte (TTFB). In this blog post, we focus on SSL monitoring—a new capability introduced to detect and alert on common TLS certificate issues that can impact web performance.

Certificate Chain Basics

The SSL/TLS handshake between the client and server involves the exchange of the following: TLS version, cipher suites, certificate exchange to establish server identity and generating session keys for data encryption.

Components of HTTP Response Time
Figure 1: Components of HTTP Response Time

Web servers that provide content through HTTPS URLs must use an SSL server certificate in order to demonstrate to the client that the server is the legitimate provider of the content at the requested URL. SSL server certificates are issued by certification authorities (CAs) using the CA's own certificates, and they use a cryptographic technique called a digital signature. Each SSL server certificate is digitally signed by the CA.

Certificate Chain
Figure 2: Path from Root CA where the chain of trust begins to the Server certificate

SSL server certificates (also known as leaf certificates) are issued by public certification authorities (such as DigiCert, Comodo, or Let's Encrypt) and are typically signed by intermediate certificates, which may themselves be issued and signed by other intermediate certificates belonging to the CA. At the end of a chain of certificates is a root certificate (also called a root CA certificate). The root certificate is signed by the CA itself. The signatures of all certificates in the chain must be verified up to the Root CA Certificate.

Chrome Certificate Details
Figure 3: An example, taken from the Chrome's Certificate Viewer, displays the certificate chain hierarchy associated with the website

Importance of Monitoring for Certificate Expiration

Regardless of whether you own the critical applications that your customers or employees rely on, or you depend heavily on SaaS services for productivity, the network and corporate IT team is responsible for service availability and delivery at all times. This makes monitoring for certificate validity crucial. If you are an enterprise providing a web service, then being able to detect expiring certificates ahead of time and take the necessary action will help protect from service disruption and brand damage. This can be less straightforward when it comes to the SaaS services you rely on, however.

If your SaaS provider fails to renew a certificate, as we have seen in the past with a large collaboration provider, you will be glad that you are proactively monitoring and alerting for certificate expiry so that you can reach out to your providers ahead of time and get the issue resolved in a timely manner—significantly reducing war room times or avoiding it altogether.

As TLS versions have iterated over time, there has always been a question around whether you’re trading off security for performance. In the interest of security, many vendors have been proposing a shorter certificate validity period at the CA/Browser Forum for a few years now. The primary motivation is that renewing TLS certificates within a shorter period allows for rolling in security updates quickly while also ensuring the regeneration of keys frequently for more website security. On September 1, Apple’s Safari browser will no longer trust TLS leaf certs with validity periods longer than 398 days—and it is a matter of time before other browsers follow suit. This is expected to create the need for more frequent monitoring of TLS certificates.

What’s New?

As the market has evolved, we’ve continued to offer capabilities to meet our customers’ needs. ThousandEyes now offers improved TLS monitoring and troubleshooting features by enriching our HTTP dataset to be able to detect and alert on common TLS certificate issues.

Detecting and Alerting on Certificate Expiry

TLS certificates have typically been configured to be valid for a long period of time. As you can see in Figure 3 above, the root certificate is not set to expire until November 9, 2031. This often means that monitoring certificate expiry is not top of mind for the teams that are responsible for websites—so alerting is critical. We now allow you to receive alerts based on certificate expiry over any period of time.

Certificate Expiry Alert
Figure 4: Alerting on certificate expiry

Our HTTP monitoring view gives you details on expired certificates.

Display Certificate Alert
Figure 5: Expired certificate details

Detecting Missing Certificates in the Cert Chain

Using complete certificate chains in the deployment of a web server is a recommended best practice. The right configuration uses all the certificates (server cert and its intermediate certs) provided by the Certificate Authority in the same sequence. This is recommended because any missing certificates in the cert chain can result in browser errors that are difficult to diagnose. For example, running into a generic HTTP error that says “SSL certificate problem: unable to get local issuer certificate” is fairly common, but it’s not very useful for customers trying to understand the problem.

As a result, a vast majority of the folks who aren’t knowledgable about TLS are going to open a support ticket and will need to read articles like this to understand the problem better or find workarounds. Being able to detect missing certificates in the cert chain during the SSL handshake process helps to provide specificity to the SSL error displayed.

Missing Int Certificate Base
Figure 6: Missing intermediate certificate details

Detecting Weak Cipher Suites

Cipher suites are used to establish secure web communication in TLS sessions. A variety of ciphers are classified as weak: RC4, using ciphers less than 112 bits, RSA key exchange ciphers, etc. They may be needed for compatibility with older clients that do not support newer encryptions. Details around the cipher suite negotiated along with the TLS version are displayed in the HTTP table view.

Weak Cipher Suite Display
Figure 7: An example of a weak cipher suite

In addition to the details on the cipher suite, we also let you alert on the strength of a cipher suite used.

Weak Cipher Alert
Figure 8: Alerting on weak cipher suites

Monitoring for certificate expiry has never been more crucial for the consumption of web applications. As we see more browsers adopt certificates with shorter lifespans for greater security, we expect to see this come to the forefront of our customers’ monitoring strategy.

Start monitoring your business-critical web applications and their TLS certificates today with the ThousandEyes free trial.

Subscribe to the ThousandEyes Blog

Stay connected with blog updates and outage reports delivered while they're still fresh.

Upgrade your browser to view our website properly.

Please download the latest version of Chrome, Firefox or Microsoft Edge.

More detail