Trust, but Verify

“Google Chrome is about to require ssl certs to have certificate transparency. What is Certificate Transparency? How do they plan to validate if a certain certificate has it? How will users obtain it? What will happen to sites without it?”

That is a company chat I came across from Ruvos Senior Systems Architect and DevOps team member Geo Miller. At Ruvos, no problem is too simple or too complex, so we took it upon ourselves to look into this new regulation to determine the effect it would have on the portals we have built — and currently maintain — for national clients.

Upon first look, the Google Certificate Transparency Project described itself as aiming to fix structural flaws in the existing SSL Certificate system. This system, consisting of algorithms, or rule sets used to decipher data, and keys, or strings of data, underlies all HTTPS connections that you use on Chrome today. Sounds like something you don’t want to believe has fatal flaws in it, right? These structural flaws are maintained as they arise, but in worst case scenario they can be overlooked, leading to major security penetrations and attacks.

You have seen the headlines — not even companies as large and supposedly robustly fortified as Yahoo, Equifax, or Facebook are safe from fake or weak SSL certificates, which allow malicious users to impersonate sites that you trust in order to watch your activity on those sites. Everything you do from the time you input your password to the time you sign out could be fair game.


The aim of this Transparency Project is three-fold. First, they want to make it impossible for a Certificate Authority (CA), the entity itself who issues these certificates like DigiCert, to issue a SSL certificate for a domain “without the certificate being visible to the owner of that domain”.

In addition to visible issuance, Google will be providing an open auditing and monitoring system that lets any domain owner or Certificate Authority determine whether certificates have been mistakenly or maliciously issued. An open audit system describes the fact that you will be able to look into anything that you believe was done in error or in malice. This simply alludes to the fact that the logs that are already being created in the background autonomously will now be visible to domain owners. You see now how aptly the initiative was named.

The third goal of the project is to protect users — hey, that’s us! — from mistakenly or maliciously issued certificates. This can truly be a “blunder” as was the case for the Chinese CA WoSign, who in 2016 accidentally issued a duplicate ssl cert for the entire slew of GitHub domains to a random GitHub user — oops! (4). This would be like gaining control over all of Facebook because you have a Facebook account. It has happened at GoDaddy recently, at the University of Central Florida, and multiple times at Symantec.

Geo had obvious concerns about the company’s day-to-day function after this program was fully implemented. You can see from the email we received from our Amazon Web Services representative, our systems living in the AWS environment will be affected starting April 24th, nearly a whole week earlier than the Chrome July start date of April 30th. This notice of about one month could devastate project timelines in place for micro organizations and monolith companies; for this specific occasion our size is strategic, positioning us to be agile while still having the manpower and resources to research and configure solutions to surprise complexities like this.

You may want to make sure your organization’s systems will not be impacted. No need to be intimidated, it only took the Ruvos team about 3 man hours to run checks on ours. Let us know what we missed in the comments below — or better yet, tweet us!

https://www.certificate-transparency.org/
https://transparencyreport.google.com/https/certificates
https://www.certificate-transparency.org/what-is-ct
https://thehackernews.com/2016/08/github-ssl-certificate.html