![](https://www.ssls.com/blog/wp-content/uploads/2019/04/SSL-certificate-revocation.jpg)
News has recently come to light that three of the biggest Certificate Authorities in the world are recalling millions of SSL certificates. “What?” I hear you cry. “How can this be?”.
Well, it seems an entire generation of non-compliant serial numbers was created due to an operational error. This has rendered millions of SSL/TLS, and probably other sorts of certificates as well, totally non-compliant.
So how does a company like Google make an operation error on this scale? Okay, hold on to your hats, we’re about to get geeky… Every type of security certificate needs a serial number. It’s how the certificates are recognized and secured – computers think in numbers, after all. They need to be completely unique with 64 bits of entropy – which, in very basic terms, is a measurement of how many possible variations of that sequence of numbers can exist – or how secure it is. There is no wiggle room. The numbers must be 64-bit.
Google, Apple, and GoDaddy (and probably others too) were using EJBCA software to generate their serial numbers. Unfortunately, the default settings for EJBCA didn’t account for the 64-bit minimum, and so it was generating 63-bit serial numbers….and no one noticed. Until now.
1-bit might not sound like a lot, but in security terms, it’s a massive difference. So, all the 63-bit certificates need to be replaced with compliant versions.
How many certificates are being revoked?
GoDaddy’s first estimate was that 1.8 million certificates were not compliant, though they’ve since brought that figure down. Apple has held its hands up to 878,000, but about a third of those had expired or already been revoked. Lastly, Google estimated that it had issued over 100,000 non-compliant certificates, but they stated only about 7,100 of them were still valid.
How did this mistake come to light?
Discovering this problem actually happened as part of an investigation into another company: DarkMatter. They have recently applied to become a fully fledged Certificate Authority, which has caused a lot of controversy in the digital security world through their perceived ties to government agencies – which is putting it very simply.
It seems that many went looking for reasons not to approve DarkMatter’s application, and in doing so discovered some non-compliant serial numbers. It then came to light that this was, in fact, a problem relating to EJBCA’s default settings, and so you can guess the rest. The industry had a collective ‘uh-oh’ moment!
Does this pose a risk to me?
If you’re SSLS.COM customer, absolutely not. Your certificates and serial numbers are fully compliant and encrypted to the max. But even if you had fallen victim to this mistake, the effects would be more of a business rather than a security headache. The time and effort needed to replace multiple certificates will be a major hassle for larger organizations. But the security implications are actually very minimal.
The low-security risk is because the 64-bit encryption standard was actually invented to handle future security threats, rather than existing ones. It’s there to compensate for more advanced attacks that have yet to be invented. 63-bit serial numbers may not be compliant, but they’re still pretty air-tight against today’s threats. They need to be replaced, but no one is actually in any great danger.
So, one of the biggest misuses of cybersecurity services has created some operational headaches (and bruised a few brands) but no real security threats. It has, however, given a bit more fuel to the ongoing debate around global compliance, internet regulation, and industry responsibilities.
![](https://www.ssls.com/blog/wp-content/uploads/Cora-ava.png)
Cora is a digital copywriter for SSLs.com. Having eight years of experience in online content creation, she is a versatile writer with an interest in a wide variety of topics, ranging from technology to marketing.