Browser

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.

11 comments
adr971
adr971

GREAT! No solution worked for me until I have installed the fu**ing rootsupd.exe file! I'm on Windows 7 x64 with Chrome Version 31.0.1650.57 m

Thanks a lot Scott Matteson

Mcgyver3k
Mcgyver3k

All you need to do is go to Tools:Internet options:Advanced and uncheck the box that says "Check for publishers certificate revocation" and "check for server certificate revocation" an click "apply".

Deadly Ernest
Deadly Ernest

The organisation I do volunteer work at two days a week has recently upgraded from Win XP to Win 7 Enterprise (it's a big international organisation) and we've gone from MSIE 8 to whatever is the latest (I keep forgetting to check) but still have one Win XP system in use. All the systems have both MSIE and Firefox installed so the public who come in to use them can use whatever they're familiar with. We've NEVER had a security certificates issue using MSIE 7 or MSIE 8 or Firefox on the Win XP systems. But that's all changed with the new systems. Most of what we deal with is Family History research and there are a number of major FH sites we visit. There is one site we visit a heck of a lot and now when we go there using the Win 7 system we get a warning from Microsoft that the website is untrusted and does not have current security certificate - to the best of my knowledge it never has had a security certificate, but it does use https and our systems automatically log us in under our organisation membership account - the site concerned is very trustworthy. We always just click the go to the site anyway button. The thing is this behaviour only happens when using MSIE on the Win 7 systems, it does NOT happen using Firefox on those systems nor when using MSIE 8 on the Win XP system. The problem is clearly something within the MSIE version in Win 7, as I suspect if it had been within the OS it would also affect the FF access. What does worry me is the majority of our general public users are not that IT literate and the only way we can deal with this issue is to just tell them where to click and to ignore the message here. But that does worry me that we're teaching them poor Internet use skills and that they may do that on some other site that should not be trusted at our office or at their home. I would welcome any advice on how I can resolve this in a more permanent manner as the problem also affects many other branches of the volunteer organisation across Australia.

fairportfan
fairportfan

I think i'll check on that - every so often, Opera refuses to access GMail, saying "A secure connection could not be established" (or words to that close effect) ... and then it starts working again. Probably not the cause, but...

Mark W. Kaelin
Mark W. Kaelin

Have you come across certificate authentication problems? How did you resolve them?

smmatteson
smmatteson

Hi Ernest, sorry for the delay in replying to your query; I was away until recently. Is there an option in MSIE to permanently install the certificate to suppress further prompts? If so this may solve the issue. Alternately, if your organization uses Group Policy there is a method you can use to configure the Windows-based clients to accept this certificate.

Deadly Ernest
Deadly Ernest

The systems are imaged at the organisation's headquarters and locked down re security etc. They even have a regular weekly remote audit check of what's on the systems and push out any updates. If you do manage to get in and change something the very next major check and update will reset all the setting back to the HQ wanted setting. Thus I can NOT change any system settings and make them stick, but I can change settings within the browser options and make them stick. But I can't find an option that affects the certificates, yet. However, the issue appears to be a problem with the MSIE browser as it's happening only with the systems with MSIE 9 on them. It doesn't affect systems with MSIE 8. It would appear that any time you go to a site and have https in the URL MSIE 9 wants to see a current security certificate, even when there is no other code on the site about certificates. The whole things just strikes me as a great big unneeded waste of time and trouble created by someone at Microsoft because they don't trust the clients to do anything.

Deadly Ernest
Deadly Ernest

but I don't have access to MSIE 9 except at the Family History Centre as I use Zorin OS 5 Linux at home. The systems are maintained and updated automatically from HQ, so I'm not allowed to play with any of that stuff. But we still have on system on hand that runs MSIE 8 in XP and it does NOT have this issue, nor do any of our regulars report any problems when using MSIE 8 at home - none have MSIE 9. All that's why I see this as an MSIE 9 issue as I also have Firefox on those same systems and I don't get the problem with FF. Thanks for the assist, but I doubt I'll be allowed to fix this locally as the HQ people have good reason not to trust the majority of locals and have their systems set up accordingly - I'm an oddity for them since I know what I'm doing in IT. This is a common problem with volunteer staff.

smmatteson
smmatteson

... that's a wildcard certificate, so I wonder if that has something to do with it. A few ideas: -Make sure familysearch.org is a trusted site in IE 9? -View the certificate for the site in IE 9 and see if it reports any errors? (there shouldn't be but this may provide a clue) -The certificate was issued by "Comodo High-Assurance Secure Server CA." Click the Certificate Path in the Certificate window, then select the "Comodo High-Assurance Secure Server CA" object and click View Certificate to look for any errors? -The certificate to Comodo was issued by "Add Trust External CA Root." In IE9, go to Internet Options-Content-Certificates and make sure this appears in the "Trusted Root Certification Authorities" tab with an expiration date of 5/30/20. -Also, you have the Windows update that I outlined in my article installed, right? :-)

Deadly Ernest
Deadly Ernest

the LDS Family History data site at https://familysearch.org/ the real funny thing about this is I know it's not the site or the server itself as I've no issues when accessing via Firefox, but when I do have the problem its when I'm at the Family History centre and using their computers to hit the site from a computer on a LAN that's connected via VPN to the same WAN that the website is part of.

smmatteson
smmatteson

I hear you - I find IE9 very frustrating to use, myself. It has a tendency to bug the user about everything; certain security prompts will nag users until they finally get shut off; this then leads to another series of prompts which causes people to just throw up their hands in frustration. Personally I'd like to see adaptive browsers (and operating systems) at some point which are intuitive, can learn from user behavior, and can be better tailored according to the expertise of the person using them. Do you mind posting the URL you're having trouble with? I may be able to test it and find a solution after some trial and error.

Editor's Picks