Chrome is working on its own root store for site certificates

Everyone “wants” to be safe on the internet but the problem is, the average user has no comprehension of what goes on behind the scenes to make internet browsers and websites safe for us common folk. Strong passwords are great but they are only a small piece in a much larger puzzle that means to ensure a safe browsing environment. What happens to your data when it passes between your device, the browser, and the endpoint website can be one of the most vulnerable places that may result in your personal information being exposed. That’s where SSL and TLS security certificates step in to help.

What are security certificates?

I won’t bore you with the intricate details of security protocols on the web. Instead, let’s dumb this down a bit so that people like me can understand it. I know that this will be oversimplifying things but I don’t believe you have to grasp how security certificates work to understand the end result. As you are likely aware, websites over the past few years have moved from the “HTTP” URL format to “https” but what does that mean? HTTPS stands for Hyper Text Transfer Protocol Secure and it simply means that the website has a valid SSL or TLS security certificate in place that lets you, the user know that your data is secure when moving back on forth between you and the site. Now, that doesn’t mean that you are 100% safe when browsing a secure website but that’s a discussion for another day.

In recent months, you yourself may have visited a site in the Chrome browser and been greeted by the “scary” popup letting you know that site wasn’t secure. It doesn’t mean that you can’t browse the site. It is just Chrome telling you that your data may be visible while in transport and that you should be wary of what type of information you share on the page. Security certificates are the web browser’s way of assuring you that the tunnel in which your data is traveling is secure. The browser pings the website to check for the SSL/TLS certificate and then reports the condition of the connection to the URL bar of the browser. That results in the lock icon you often see in your browser’s URL bar. Alternatively, it triggers the insecure warning and a red lock if the certificate is missing, incomplete, or invalid. Consider it a digital handshake between the browser on the website.

Who decides which SSL/TLS certificates are to be trusted. That really on the browser or the host operating system being used by the operator. For example, the Firefox browser hosts its own “root store” which is nothing more than a list of valid certificates that the browser uses to verify the certificates as they are issued by a variety of CAs or Certificate Authorities. On the other hand, Chrome has historically relied on the root store of the host operating system but that will change in the near future. Chromium Developers have introduced a roadmap for the Chrome Root Program that details the transition to the in-house certificate database that will be utilized by the browser on Android, Chrome OS, Linux, Windows, and macOS. iOS isn’t on the list as Apple prevents Chrome from using the native verification tool. Whatever, Apple.

Why it matters

At the end of the day, this will have little effect on the end-user from an interface standpoint. Chrome will continue to check for certificates and alert users that the site they are browsing is or isn’t secure. How this will benefit the user is that it gives Chrome more granular control over the certificates that are considered valid. If an instance arises where a certain certificate provided is deprecated or perhaps a CA platform is compromised, Chrome can swiftly remove the related certificates from its own root store. This will allow the developers to keep users safer, faster when unforeseen circumstances arise.

Google has not released a timeline for the transition to the in-house root store but you can see the entire roadmap of how the changes will take place on the Chromium website here. Most certificates that are already issued from the currently trusted CAs will be added to the transitional root store with new and updated certificates being added in the future on a per-case basis. Many of these trusted certificates are being pulled from the same Common CA database used by Mozilla and various operating systems. For certificates not automatically added, developers can contact the project directly with questions here.