Google, Apple, GoDaddy Mis-issue Over 1 Million Faulty Certificates

The trust you place in your Certificate Authorities (CAs) can change in a heartbeat. Even the largest and most trusted CAs (see Symantec) are vulnerable to human error. Just ask the owners of over 1 million certificates that were mistakenly issued by GoDaddy, Apple and Google with 63-bit serial numbers, instead of the 64-bits required by binding industry mandates. This is a direct violation of CA/B Forum Baseline Requirements and requires immediate action to revoke and replace all impacted certificates.
 

Kevin Bocek, vice president of security and threat intelligence for Venafi, explains why it is so important to hold CAs to such high standards, ‘Machine identities like TLS digital certificate establish what is good and trusted on the Internet, clouds, and business networks. Their powers are extreme and is so important they are being advertised more often on the dark web than ransomware and zero days.” Although the mis-issued certificates pose no immediate security risk, they are still technically vulnerable and must be replaced.

Ars Technica explains the nature of the operational error:
 

“The snafu is the result of the companies' misconfiguration of the open source EJBCA software package that many browser-trusted authorities use to generate certificates that secure websites, encrypt email, and digitally sign code. By default, EJBCA generated certificates with 64-bit serial numbers, in keeping, it seemed, with an industry mandate that serial numbers contain 64 bits of output from a secure pseudo-random number generator. Upon further scrutiny, engineers discovered that one of the 64 bits must be a fixed value to ensure the serial number is a positive integer. As a result, the EJBCA default produced a serial number with 63 bits of entropy.”
 

As a result of this mass mis-issuance, organizations everywhere will be scrambling to find and replace these impacted certificates within the 5-day window that CAs have to revoke non-compliant certificates, as required by industry rules. For many, that simply won’t be possible. In an online forum, Daymion Reynolds, senior director of SSL/PKI security products at GoDaddy, commented that the company would not meet that deadline, but instead would try to reissue all the impacted certificates within the next 30 days.
 

Why will it take so long? Reynolds explained, “We have a significant number of customers that use manual methods for managing their certificates, so being agile for them is difficult. We want to keep our customers using https through the entire revocation period. Due to the large number of certificates and the benign nature of the issue, our plan is to revoke in a responsible way.”
 

The bottom line is that manual methods simply do not scale when you are forced to quickly replace larger numbers of certificates. Before you can revoke and reissue them, you need to find them. And if you are using a spreadsheet, your intelligence is only as good as the staffers who have updated it.
 

According to Kevin Bocek, “Most businesses lack the intelligence to know where they are using machine TLS digital certificates. Plus, they have no means to replace them with speed of automation expected now in digitally transformed businesses. Replacing a single digital certificate can take hours, is highly error prone, and can introduce new vulnerabilities if not done corrected—or cause business systems to fail and not work.”
 

The pain that this type of mistake causes organizations should not be taken lightly. And the elevated risks that result should be acknowledged at the highest levels of an organization. “It’s a huge third-party risk that most CISOs and boards must understand,” comments Bocek. “This is just one more reminder of why organizations need Machine Identity Protection to give them the intelligence and automation they need to control all their machine identities – including TLS digital certificates.”
 

Are you prepared to replace massive numbers of machine identities if the need arises?



 

Related posts

• Why You Need More than Certificate Authority Management Solutions
• CA Agility: Why You Need to Maintain Tighter Control over Certificate Authorities
• CA Agility: What Should Security Leaders Do Next?