Enterprise Software

The strange case of the Google certificate roadblock

Certificate errors while browsing the web can be confusing – especially when trying to access known good sites. Learn how one sticky Google certificate error got resolved.

I'm about to do something I usually never do, and that is to promote one web browser over another. This is like pushing a religion, as least among the techno crowd. Yes, after being a Firefox user for years (Internet Explorer? What's that?) I am now firmly in the Google Chrome camp and use it for my primary browsing, keeping the other browsers present for testing and troubleshooting for users if needed. Dealing with Firefox's notorious memory/resource problems and bizarre accelerated updates-with-no-apparent-benefit became too much. Chrome is fast, sleek and reliable - except on one recent noteworthy occasion.

A company I consult for relies on Google Apps for email, and we elected to get the Google Chrome web browser up and running on their computers, which use the 32-bit version of the Windows 7 operating system. My first notion as to how to benefit from using Chrome with Google Apps was to install the Offline Google Mail application, which provides the use of Gmail in offline mode (and which only works with Chrome).

Once Chrome was set up I tested it using a link I had to a helpful Google Apps migration document provided by "The New School" which proved useful in planning our post- migration tasks. I was surprised to get a security certificate error (Figure A) as shown below.

Figure A

Can't get there from here

No big deal, I immediately thought at first. At my day job we use self-signed certificates for all of our internal websites, and the need to accept or trust self-signed certificates is a common one (making sure the server and certificate are legitimate, of course). The problem, I quickly realized, was that this wasn't a self-signed certificate on an internal site: it involved an external site: sites.google.com - one of Google's very own pages, which surely their browser should trust. Furthermore, there was no way to accept the situation and "proceed anyway." It was a roadblock, plain and simple.

OK, I thought. Perhaps it's just a one-shot deal. I began checking other sites around the web. All seemed fine, as far as I could tell, until I got the error when accessing another link at sites.google.com. The error also came up when trying to connect to Google+, which is Google's social network. The certificate message seemed absurd given the browser and the sites were all Google-owned (however a good browser doesn't play favorites but should scrutinize all sites equally). I checked one more time by connecting to Twitter and the same message appeared. I was also able to reproduce the issue on another computer in the company. What was going on?

I viewed the certificate details in Chrome by clicking the padlock icon in the address bar (Figure B), which in my case showed with a red X.

Figure B

Clicking the padlock yielded the following message (Figure C).

Figure C

I checked sites.google.com and plus.google.com and saw similar details. We couldn't very well roll forward with this new browser, even on a trial basis, if it couldn't reliably access the web. As many consultants might relate, I was starting to feel the sting of a recommended product threatening to backfire on me.

Unraveling the tangled web

I did some research (Google searches worked for me even though they also used secure https connections, which was interesting) and found a Google product forum where the issue was being discussed. I came across tips such as:

  • Checking to make sure the date/time were accurate (they were)
  • Turning off Chrome's setting to "check for server certificate revocation" (no luck)
  • Clearing the browser cache (which seemed silly; this was a new installation!)
  • Updating the browser (it was already on the latest version)
  • Closing Chrome, deleting the "Certificate Revocation Lists" file under "C:\Users\[user]\AppData\Local\Google\Chrome\User Data" and opening Chrome again to let it recreate the file
  • Removing/reinstalling the browser (didn't try this; seemed a last ditch effort and I wasn't quite there yet)

Sometimes when reading up on a weird problem of this nature there is a tiny signal-to-noise ratio; few needles in the haystacks but lots of chatter and "me too" comments. I often joke that sometimes you almost have to climb a mountain to find the solitary guru who knows the key to these tough mysteries, like in the comic strip "B.C." However, before I got my rock climbing gear out, I came across a tip that suggested that my computers didn't have the necessary Windows root certificate update. Root certificates are used by a web browser to validate the certificate authorities which in turn validate the identity of websites so they are properly trusted.

As is often the case when we come across the solution, I immediately dismissed it. We use WSUS at this organization and surely all the computers had all the updates they needed. Or did they? I didn't see it listed at the WSUS server.

I downloaded the Windows XP version of the update and found it worked for both Windows XP and Windows 7 (note: if you install it, you will not see a confirmation that this worked, nor does it appear as an installed program - how's that for a silent install?). As soon as I installed this update I could then immediately access all sites and Chrome was happy again. I later found that the WSUS server should have had the "Updates" classification set in order to receive these root certificate releases; previously it was only downloading critical updates, security updates and service packs; this was checked off and the other systems soon got the update as well.

If not for those meddling kids

As it turned out, the issue wasn't with Chrome, but an oversight involving a critical Windows update which had slipped through the cracks. The mystery serves as a good reinforcement that updates really do matter, and you should never reject a potential solution without thinking it through and asking "Am I sure?" Moreover, sometimes problems can lead you in the wrong direction and you may have to wade through unnecessary or even unsafe suggestions (turning off Chrome's option to "check for server revocation" was OK for quick troubleshooting, but had this worked it would not have been wise to leave that security feature turned off) until you get to the bank on the other side. In the case of this solution, the bank was a gold mine.

Also read:

About

Scott Matteson is a senior systems administrator and freelance technical writer who also performs consulting work for small organizations. He resides in the Greater Boston area with his wife and three children.

Editor's Picks