Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
2  
Could you paste the certificate details? This could be helpful in determining the source of the discrepancy. –  Iszi Sep 6 '11 at 19:18
    
@iszi What details would be helpful? You mean like date issued and expiration date and ...? –  Ali Sep 6 '11 at 19:22
2  
Pretty much any detail you can give us about the certificates would be useful. Especially pertinent are any items that you're seeing which are different from one another. –  Iszi Sep 6 '11 at 19:49
    
I would do it tomorrow and post the result here. –  Ali Sep 6 '11 at 20:40
    
All the metadata (as well as the SHA1 and MD5 which is displayed in the FF certificate viewer) are exactly the same! Only when I export them they are different! –  Ali Sep 7 '11 at 17:03

5 Answers 5

up vote 6 down vote accepted

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.

share|improve this answer
    
Is it possible for the proxy admin, to get (given the authority, and access to a root CA) a key to sign the packets on behalf of google or anybody else so that they'd be able to inspect the packets and enforce some internet connection policy? (I mean just to avoid tampering with the browsers so that they accept the ssl proxy's signature) –  Ali Sep 6 '11 at 19:09
1  
If I understand your question correctly, then yes, there are vendors out there (e.g., Bluecoat) who make boxes that are able to issue certificates on-the-fly that tie to a custom CA cert installed on your laptop, all for the purpose of seeing (although probably not changing) what's going on inside your SSL sessions. –  Steve Dispensa Sep 6 '11 at 20:54

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).

share|improve this answer

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.

share|improve this answer
    
So Basically the certificate itself could not be used to verify if it is valid or not, unless you can check if it is signed by a valid CA (or the valid CA) is the key? –  Ali Sep 6 '11 at 20:39
1  
@Ali: Pretty much. The CA that signed the certificate vouches for its authenticity. There are some preliminary sanity checks you can do with the certificate itself (particularly "valid from-to"), but that's about it. –  Piskvor Sep 7 '11 at 13:34

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

share|improve this answer

@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.

share|improve this answer
1  
Yup. In addition, if one of the root CAs is DigiNotar, DO NOT TRUST. (if you're using IE, the root CA has been only removed with today's system update (fashionably late as usual ;)) - although various certs have been already revoked, there are various unaccounted-for rogue certificates signed by them still floating around) –  Piskvor Sep 7 '11 at 7:30
    
Firefox has removed DigiNotar's trust in 6.0.1, and did some more cleanup in 6.0.2. –  Iszi Sep 7 '11 at 13:03
    
@Iszi: Both FF and Chrome reacted with commendable speed; however, as FF's update requires user interaction (on Windows XP, at least - "why is it nagging me to update again? I already updated last week!"), I believe there is still a significant percentage of FF users at 6.0.0 or lower. –  Piskvor Sep 7 '11 at 13:30
    
I'm personally a fan of requiring opt-in (or, at least permitting opt-out) for full automatic updates, but that's another discussion entirely. I had heard that Chrome had been updated, but wasn't sure of the version number or when it happened. –  Iszi Sep 7 '11 at 13:53

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.