First of all, why do we need SSL certificates?
Technically speaking, they should be called TLS certificates because they bear a public key which is used in Transport Layer Security (TLS) protocol to authenticate the server.
But this is not a technical article, so we will stick to the concepts everyone can understand.
When you go to your favourite online shopping site, you want to be assured that the site is genuine (no one is trying to lure you on a fake copy of Amazon) and everything you send or receive (like your personal data and shopping choices) is secure.
So, how do the browsers know that the site is trustworthy and display that padlock near the address bar? The SSL certificate tells them so.
So, basically SSL certificate is a guy who tells you: “This site is ok”.
But why would you trust this guy you do not know? Let’s call this guy Sam. You do not trust Sam, but Mike trusts Sam, and Dennis trusts Mike. You trust Dennis; he is a friend of yours! This way you have a chain of trust, just like SSL certificates do.
Normally, people have a close circle of friends they trust. So do the browsers. They have a list of root certificates they trust without any reservations, and they would trust any certificate issued (signed) by a chain that leads to one of the trusted root certificates.
Some browsers (like Firefox) have their own trust store, other browsers rely on the trust store of the operating system they run on.
Now, imagine the following situation:
There is a guy called Peter who is trusted by Tom, who is trusted by Vito. Everyone trusts Vito because Vito is the head of a well-known and respected Family.
Then Vito decides to retire and announces that his son Michael will replace him as the head of the family, and whoever respects Vito must now respect Michael.
Tom pays his respect to Michael, and everything is good. But one day Vito dies…
Suddenly, it appears that a group of people respected Michael only because they respected Vito when he was alive and do not recognise Michael as the head of the respected family.
Things won’t end well for these people… So do the browsers or operating systems which do not regularly update their trust stores.
Back to Michael’s family drama…
The idea of Michael and Vito ruling the Family business together for some period of time sounds like a very good idea. For Michael, as the new official Head of the Family, it is a good opportunity to get some experience from his father, be introduced to different people etc., for Vito, as a retiring boss, it means that transition of power will be smooth, and the Family business will be in the good hands.
The same happens in the world of SSL certificates. Sometimes the new root certificates are signed by the older root certificates of the same Certificate Authorities. This is called cross-signing.
The older root certificates are more widely spread on various platforms and more likely to be trusted. The newer root certificates can take this advantage and be trusted by the systems, even while not being recognised as a root certificate on its own, just by the fact that they are cross-signed by the older (and trusted) root certificate.
However, the older root certificates have one critical defect – they expire sooner, and when it happens, the new root certificate is expected to have been disseminated well enough to be respected by the majority of the platforms.
Unfortunately, this is not as simple as it seems to be…
Imagine the following situation:
Knock, knock.
Who’s there?
It’s Peter
What Peter?
Tom sent me
Who is Tom?
He works for Michael, son of Vito
Come in…
Technically, this dialog is quite inefficient. Certainly, there is a room for improvement in this communication. Consider this:
Knock, knock.
Who’s there?
It’s Peter. Tom sent me. He works for Michael, son of Vito
Come in…
Now THAT is a much more efficient communication.
In the world of TLS/SSL security, this means a quicker turnaround for the initial SSL handshake. For this reason, the server sends not just one, but several SSL certificates which allow to validate the whole chain of trust up to the trusted root certificate without a need to download any intermediary certificates from Certificate Authorities.
Unfortunately, the following situation may occur:
Knock, knock.
Who’s there?
It’s Peter. Tom sent me. He works for Michael, son of Vito.
But Vito is dead.
Michael is now the boss.
I know, but… Vito is dead.
A mention of Vito obviously caused some sort of confusion here. It should not matter anymore that Vito was the Head of the Family.
Now Michael is the Head and everyone should recognize this fact for their own good. However, a mention of Vito creates two chains of trust, one leading to Michael and another one leading to Vito.
Now it is possible to explain what happened on 30 May when many system administrators around the world woke up early in the morning and discovered an avalanche of alerts from the monitoring systems and the angry customers:
“Your SSL certificate has expired! We can no longer access your API!!!11111”
To their relief and astonishment they realized that their site certificates are absolutely fine, and their websites are working in all major browsers without any issues. What would cause such a problem?
On May 30, one of COMODO (now Sectigo) root certificates expired after 20 years of a happy life.
This should not have caused any issues, because the replacement root certificate was issued in 2010 and by the end of 2015 it has been disseminated across all major operating systems, browsers and programming frameworks and runtime environments.
At the same time, the new root certificate was cross-signed by the old one.