How Certificate Trusts Work and Why They Are Causing Trouble

If you ask most people who work in our industry to describe the difference between HTTP and HTTPS, they might say the latter is the secure version. They may even go further and explain that HTTPS uses an SSL certificate to secure the connection between the user’s web-browser and the web-server hosting the web-page.

But surprisingly, many do not know the details of how an SSL certificate works; the reliance on third-party trust, and why we will soon be facing a wave of problems with root certificates expiring.

What is HTTPS?

For anyone who believes HTTPS is more secure than HTTP; and that it relies on SSL certificates to secure communications, they are correct.

We won’t focus on the intricacies of HTTPS in this blog, but the basic idea behind SSL secured communication is the use of a private key to encrypt a message, which is then sent to a recipient who decrypts it using a public key. In HTTPS this public key & some other critical parameters are provided via an SSL certificate.

This is great for securing communications, but implicitly trusting any SSL certificate could result in a Man-in-the-Middle (MiTM) attack. Whereby someone or something sits between a SSL secured communication channel presenting its own certificate in order to decrypt traffic, snoop or modify the content and re-encrypt it.

This is a highly dangerous prospect which has sought to be cured by chains of trust and certificate signing.

You may also be interested to read How to Secure Your Remote Access from the Changing Threat Landscape

What is Certificate Signing?

The process of certificate signing, seeks to prove an SSL certificate is correct and presented by the correct party. It does this by having the SSL certificate signed by a third-party authority which is trusted by all.

A real-world example of this would be something akin to notarising – when we get a document signed by a lawyer or Public Authority to prove its is genuine and correct. In the world of SSL certificate signing, we perform this verification using certificate signing authorities. Some of the more famous and recognisable authorities include DigiCert, GeoTrust and Comodo.

When we create an SSL certificate, we submit it to a signing authority, who then verifies the certificate holder is who they say they are; and signs the certificate using a root certificate.

…and this is the crucial part. All devices which support SSL communication, hold copies of the worlds root certificates. So, when presented with an SSL certificate which purports to be signed by a particular root certificate, the device can check that against its own repository of root certificates.

I hope I haven’t lost you there! If I haven’t, you should be asking “so where is the problem?”

Well, what happens with the root certificate expires?

Expiration of Root Certificates

Now comes the problem.

Most, if not all, root certificates have a validity of twenty-five years; and as we pass twenty years since SSL based communications really started being used widely, we are entering a period where some root certificates may expire.

What this means is that when an SSL certificate which has been signed by an expired certificate is verified by a connecting computer, it will be rejected. The signatory will no longer be trusted.

In-fact, we had our first taste of this exact scenario on the 30th of May 2020 when an AddTrust root certificate expired, rendering all certificates it has signed invalid. This resulted in some Roku streaming services being interrupted as well as disruption of payment providers Stripe and Spreedly.

For PCs, Laptops and Servers, this is not necessarily a huge issue. IT teams should be updating their SSL certs to be signed by more modern and up-to-date root certificates. Operating system vendors such as Apple, Microsoft and Google all issue updates to update the root certificates on their devices.

However, in an age of smart devices, those updates are not always happening. It was noted recently in an article on The Register, that the BBC had updated their SSL certificate but many smart TVs which run their iPlayer app was still attempting to verify their SSL certificate using an outdated root certificate from 2012. This means that there is a huge problem brewing for smart devices that are either never updated by their owners or even worse, no longer updated by their manufacturers.

The same can be said for devices in secure environments which typically do not receive updates because they are not connected to the internet.

You may also be interested to read Five Considerations for a COVID-19 Ready Remote Workforce

How to Avert Problems

The issue is really two-fold.

There is no way to estimate how many devices are to be affected by any one root certificate expiring. Each signature is recorded, but how many of those certificates are still in use over a twenty-five-year period is anyone’s guess.

The other issue is that this is quite a complex and abstract issue that most consumers of smart devices are unlikely to grasp. In-fact, unless an IT worker has had significant experience with SSL, it is likely to baffle them too.

The best advice to minimise disruption is to ensure SSL certificates and root stores are updated.

For SSL certificate hosts, it is important to note the validity of your signing root certificate. SSL certificates are issued for between one and three years, but if your signing root certificate has less validity than your SSL certificate, you should be looking to get this changed.

For root certificate stores, it is important to install updates which contain updates to the root certificate stores. For smart devices where vendor updates are weak, if there is no planned update, sadly you may have to resign the device to the bin, once the time comes.

Its certainly the most interesting reason to need to buy a new gadget!