I see two different sets of certificates for Google websites when I am at work and when I am at home

Question

I see two different sets of certificates for Google websites when I am at work and when I am at home.

I mean if I save the certificates (in firefox, click on the "Google.com" block on the left of https in the address bar and select "more information" -> security -> view certificate details -> export) both at home and at work they are different. (I am just comparing them using diff work.cert home.cert).

I noticed this when I started using "Convergence" FireFox plugin (http://convergence.io/)

Is it OK?

Answer 1

There may be a number of reasons for that. Without the information from both certificate chains, it is impossible to give a definite answers.

Different set of servers

Google has many server clusters distributed all over the world. Your request are handled by a cluster that is near to you based on network topology. It is possible that you end up in a different server cluster depending on your and the company's Internet Service Provider. Google might use different keys for different clusters.

https proxies

It is likely that your company uses a proxy server that sniffs https traffic. Since https is encrypted and has special measures in place to prevent man in the middle attacks, the proxy server has to fake the certificate.

A normal https proxy connections works like this:

1. the browser tells the proxy server: "I want a low level connection to www.google.com:443"
2. the proxy server connects to www.google.com:443 and blindly forwards all packets from the browser to google and via versa.

A dedicated https proxy does this instead:

1. the browser tells the proxy server: "I want a low level connection to www.google.com:443"
2. the proxy server generates a key pair for www.google.com:443
3. the proxy server signs the the certificate with the private key of a local CA.
4. the proxy server shows this certificate to the browser
5. the browser will check the certificate. Normally it would complain, but it was told by the administrator beforehand that the proxy CA is trustworthy.
6. the browser sends the http request for a page.
7. the proxy reads server the requests, opens a secure connection to www.google.com and requests the appropriate page
8. the proxy server receives the answer, decrypts it, checks it and encrypts it with the session key derived from the faked private key generated in step 2.
9. the browser receives the answer, decrypts it and is happy.

The critical step here that breaks SSL is that the administrator has configured the browser to accept the proxy CA which is used to sign the faked keys.

Answer 2

This is standard practice. Its been said that best practice is to not share certs between servers, so you'll see different certificates from servers in different locations. From Verisign:

Can I secure multiple servers with a single certificate? Sharing certificates on multiple servers increases risk of exposure. Auditing becomes more complex, reducing accountability and control. If a private key becomes compromised, it can be difficult to trace and all servers sharing that certificate are at risk. Because sharing certificates degrades security, the VeriSign certificate subscriber agreement prohibits customers from using a certificate on more than one physical server or device at a time, unless the customer has purchased additional server licenses. VeriSign’s licensing policy allows licensed certificates to be shared in the following configurations: redundant server backups, server load balancing, and SSL accelerators. See About SSL Certificate Licensing.

E.g., if I run nslookup www.google.com on different computers I'll find several different IP addresses for different google servers. One will give an SSL cert with a SHA256 fingerprint:

SHA-256: F6 41 C3 6C FE F4 9B C0 71 35 9E CF 88 EE D9 31 7B 73 8B 59 89 41 6A D4 01 72 0C 0A 4E 2E 63 52

while another will give:

SHA-256: 63 80 03 73 A7 74 72 E0 3E 7E 56 4E A2 17 2F C2 5C 37 D5 71 BD 05 10 1C B4 3C 14 00 04 92 0F 64

Both are "Builtin Object Token:Equifax Secure CA -> Google Internet Authority -> *.google.com" and appear to be valid.

Answer 3

@Hendrik covered the two most likely situations nicely. I might add that I would be suspicious if I saw different, public CA's at the root of the chain of trust for the same site at home vs. at work. It is entirely possible that your IT group is using an intercepting proxy, but I'd be surprised if I saw, for example, Equifax from work and Verisign from home. Maybe others can comment on how common it is to use different CA's for the same addresses in the real world, but personally, I've never run across it.

Answer 4

There is a (for all we know, still ongoing) MITM attack on (mostly Iranian) Internet users, using fraudulent certificates signed by the DigiNotar CA. If any of the certificate authorities says "DigiNotar" or "PKIoverheid", consider the connection insecure. This is a current event, watch e.g. this: http://www.google.com/search?aq=f&hl=en&gl=us&tbm=nws&btnmeta_news_search=1&q=diginotar

Answer 5

It is normal, expected and actually recommended that big sites use several certificates. Google is huge and has many servers around the world; DNS and routing are done in such a way that, on average, your requests to www.google.com go to the nearest server, where "near" is meant in the network's topology, which can differ from geographical considerations.

Each server with the www.google.com name must be able to use a certificate bearing its name (or something matching its name, like *.google.com), and the server must have access to the corresponding private key. However, if two geographically distant servers both use the same private key, then that private key must necessarily have travelled between them or from a common source at some point. The more a private key is duplicated and travels, the less "private" it can be.

It is thus better, security-wise, that each server generates its own private/public key pair, and obtains a server-specific certificate. From the point of view of a client, you may observe several of these certificates, in particular if you "move" (in the network world, your work office and your home can be quite far from each other).

Other situations which necessarily imply certificate changes are renewals. Certificates have a limited lifetime, with an "end of validity" date; they typically live for one to three years. Renewal may or may not reuse the same public key, but in any case the new certificate will be distinct from the old one, if only in the expiry date. X.509 is designed to support such updates smoothly. It is actually designed to support renewals every 5 minutes, which is complete overkill; Convergence tries to live in that "overkill margin" (i.e. it detects fishy certificates by virtue of them being seemingly renewed or changed way too often).

Answer 6

Are you using Firefox? If so go into Tools->Options->Advanced-> and choose view Certificates. Delete or distrust it. I believe if you want to be "safe" you should make the certificate chain the same path when viewing from the the same computer. When I did this from Firefox the certificate chain was then the same as presented from Chrome.