In order for a browser to authenticate a website, it presents itself as a valid certificate chain. A typical chain is shown above, it can have more than one intermediate certificate. The minimum number of certificates in a valid chain is three.
The root certificate is the heart of a certification authority. It is literally embedded in your OS or browser, it is physically present on your device. You can’t change it from the server side. You need to force update the OS or firmware on the device.
Security Specialist Scott Helme writesthat the main problems will arise at the Let’s Encrypt certification center, because today it is the most popular CA on the Internet, and its root certificate will soon go bad. Change root Let’s Encrypt scheduled for July 8, 2020.
Final and intermediate certificates of the certification authority (CA) are delivered to the client from the server, and the root certificate from the client has alreadytherefore, with this certificate collection you can chain and authenticate your website.
The problem is that each certificate has a validity period, after which it needs to be replaced. For example, from September 1, 2020, Safari plans to introduce a limit on the validity period of server TLS certificates maximum 398 days.
This means that all of us will have to replace server certificates at least every 12 months. This restriction applies only to server certificates, it not applies to root CA certificates.
CA certificates are governed by a different set of rules, so they have different expiration dates. Intermediate certificates with a validity period of 5 years and root certificates with a service life of even 25 years are very common!
There are usually no problems with intermediate certificates, because they are delivered to the client by a server, which itself often changes its own certificate, so it simply replaces the intermediate one during this procedure. It is fairly easy to replace with the server certificate, unlike the root CA certificate.
As we have already said, the root CA is embedded directly in the client device itself, in the OS, in the browser, or in other software. Changing the root CA website cannot be controlled. This requires an update on the client, whether it is updating the OS or software.
Some root CAs have existed for a very long time, we are talking about 20-25 years. Soon, some of the oldest root CAs will be nearing the end of their natural lives, their time is almost up. For most of us, this will not be a problem at all, because CA created new root certificates, and they have been distributed worldwide for many years in OS and browser updates. But if someone has not updated the OS or browser for a very long time, this is a kind of problem.
This situation arose on May 30, 2020 at 10:48:38 GMT. This is the exact time that the AddTrust root certificate from Comodo Certificate Authority (Sectigo) is rotten.
It was used for cross-signing to ensure compatibility with legacy devices that do not have a new USERTrust root certificate in their repository.
Unfortunately, problems arose not only in outdated browsers, but also in non-browser clients based on OpenSSL 1.0.x, LibreSSL and Gnutls. For example, in set-top boxes Rokuservice Heroku, in Fortinet, Chargify applications, on the .NET Core 2.0 platform for Linux, and many others.
It was assumed that the problem will affect only legacy systems (Android 2.3, Windows XP, Mac OS X 10.11, iOS 9, etc.), as modern browsers can use the second USERTRust root certificate. But in fact, crashes began in hundreds of web services that used the free OpenSSL 1.0.x and GnuTLS libraries. A secure connection has ceased to be established with a certificate obsolescence error.
Next – Let’s Encrypt
Another good example of an upcoming root CA change is Let’s Encrypt certification authority. Still in April 2019 they planned to move from the Identrust chain to their own ISRG Root chain, but this Did not happen.
“Due to concerns about the insufficient distribution of the ISRG root on Android devices, we decided to postpone the date of transition to our own root from July 8, 2019 to July 8, 2020,” Let’s Encrypt said in an official statement.
The date had to be postponed due to a problem called “root propagation”, or rather, the lack of root propagation when the root CA is not too widespread on all clients.
Now Let’s Encrypt uses a cross-signed intermediate certificate with a chain to the root of IdenTrust DST Root CA X3. This root certificate was issued back in September 2000 and expires on September 30, 2021. Until this time, Let’s Encrypt plans to switch to its own self-signed root ISRG Root X1.
ISRG root was released on June 4, 2015. After that, the process of its approval as a certification authority began, which ended August 6, 2018. From now on, the root CA was available to all clients through an update to the operating system or software. All that had to be done was to install the update.
But that is the problem.
If your mobile phone, TV, or other device has not been updated for two years, how will it know about the new ISRG Root X1 root certificate? And if it is not installed on the system, then all Let’s Encrypt server certificates will be invalidated by your device as soon as Let’s Encrypt switches to a new root. And the Android ecosystem has a lot of obsolete devices that have not been updated for a long time.
That’s why Let’s Encrypt has delayed the transition to its own ISRG root and is still using an intermediate link that goes down to the IdenTrust root. But the transition in any case will have to be done. And the date of the change of root is assigned July 8, 2020.
To verify that your device (TV, set-top box or other client) has the ISRG X1 root installed, open the test site https://valid-isrgrootx1.letsencrypt.org/. If a security warning does not appear, then usually everything is in order.
Let’s Encrypt is not the only one who has to solve the problem of switching to a new root. Cryptography on the Internet began to be used a little more than 20 years ago, so just now there comes a time when many root certificates expire.
Owners of smart TVs who have not updated Smart TV software for many years may face this problem. For example, the new GlobalSign root R5 root released in 2012, and after some old Smart TVs cannot build a chain to it, because they simply do not have this root CA. In particular, these clients could not establish a secure connection to bbc.co.uk. To solve the problem, the BBC admins had to trick: they built an alternative chain for these clients through additional intermediate certificates, using old roots R3 root and R1 rootthat are not rotten yet.
www.bbc.co.uk (Leaf) GlobalSign ECC OV SSL CA 2018 (Intermediate) GlobalSign Root CA - R5 (Intermediate) GlobalSign Root CA - R3 (Intermediate)
This is a temporary solution. The problem will not go anywhere if you do not update the client software. A smart TV is essentially a Linux-based computer with limited functionality. And without updates, its root certificates will inevitably become rotten.
This applies to all devices, not just televisions. If you have any device that is connected to the Internet and which was advertised as a “smart” device, then the problem with foul certificates almost certainly concerns it. If the device does not update, then the CA root repository will become obsolete over time, and eventually the problem will surface. How soon the problem occurs depends on the time of the last update of the root store. This may be several years before the date of actual release of the device.
By the way, this is the problem why some large media platforms cannot use modern automated certification authorities such as Let’s Encrypt, writes Scott Helme. They are not suitable for smart TVs, and the number of roots is too small to guarantee certificate support on legacy devices. Otherwise, TV simply will not be able to launch modern streaming services.
The latest AddTrust incident showed that even large IT companies are not prepared for the expiration of a root certificate.
There is only one solution to the problem – an update. Smart device developers must provide a mechanism for updating software and root certificates in advance. On the other hand, it is unprofitable for manufacturers to ensure the operation of their devices at the end of the warranty period.