I just went to accounts.google.com and I noticed that Firefox reports (unknown) as the owner of google.com. Should I be worried about this?

Here's a Dutch screenshot of the certificate:

Google certificate

  • Courtesy of LWN: googleonlinesecurity.blogspot.com/2013/01/… Another fraudulent *.google.com digital certificate was detected in late December; this one traces back to CA TURKTRUST. "In response, we updated Chrome’s certificate revocation metadata on December 25 to block that intermediate CA, and then alerted TURKTRUST and other browser vendors. TURKTRUST told us that [...] they discovered that in August 2011 they had mistakenly issued two intermediate CA certificates to organizations that should have instead received regular SSL certificates." Jan 5, 2013 at 12:05
  • @DeerHunter: If I've ever visited a spoofed Google domain that abused this certificate, Firefox would have displayed "Verified by: Turktrust" in the SSL popup, right?
    – Pieter
    Jan 5, 2013 at 16:19
  • Yes. This was rather a general comment on the state of affairs in the PKI-land... Jan 5, 2013 at 16:24
  • I'm rather unfamiliar with the technical side of SSL, but if I'm not mistaken this was a human error. Are there any SSL alternatives/improvements that can eliminate the possibility of human errors by certificate authorities? And then I'm not even considering the possibilities for hackers and governments to sabotage the system...
    – Pieter
    Jan 5, 2013 at 16:28
  • Alas, none. The human is the ultimate protection... and the greatest vulnerability of any system, PKI not being an exception. Jan 5, 2013 at 16:34

2 Answers 2


Nothing to be worried about. All this means is that Google doesn't use an extended validity certificate. It's well known that the Google.com site belongs to Google, so there's really no need for that information to appear in Google's certificate.

For a more detailed explanation of extended validity certificates and why Google doesn't need one, see this answer.

  • 1
    Google, one of the world's biggest tech companies, doesn't have one? That's weird. Some other well-known sites like PayPal do have them.
    – Pieter
    Oct 4, 2012 at 20:50
  • 1
    Google doesn't need an extended validity certificate because everyone known that Google.com belongs to Google Inc. For a more detailed explanation of this see security.stackexchange.com/a/13614/12216. I don't know why PayPal went to the trouble - perhaps they use other domains as well? Oct 4, 2012 at 20:58
  • It's not like they don't have the money to go through the additional hassle of getting an extended validity certificate. It might stop people like me from being worried if they see '(unknown)'.
    – Pieter
    Oct 5, 2012 at 8:44
  • @DavidWachtfogel - PayPal uses several domains for localized versions of their service. So it makes sense to roll out a cert that can handle their situtation.
    – Ramhound
    Oct 5, 2012 at 16:47
  • @Pieter - They have that money because they won't waste it on pointless certifications that verify that Google.com is owned by Google Inc.
    – Ramhound
    Oct 5, 2012 at 16:47

The content is still transferred encrypted. As to the validity of the SSL Certificate, so you know you are actually connecting to a google server, you should actually view the certificate itself, and view the chain to the root certificate authority. If you trust that root certification authority, (ie Verisign via Thawte in the case of Google) then you can trust that the certificate belongs to Google.

The only way this could be someone elses server is if someone redirected your google.com DNS lookup to their server (via DNS cache poisoning or elsewise) AND:

  1. The root (Verisign) CA was compromised, and a bogus certificate was signed for google.com; or
  2. Someone used a bogus CA certificate to sign this SSL certificate, and installed their root certificate in your trusted certificate store. In which case you could see that the root CA certificate does not belong to verisign.

I believe ownership information is only present in Extended Validation certificates, of which this SSL certificate may not be.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .