6

This is sort-of a follow-up to my previous question What fields in a suspicious certificate should I look at?

Chrome just presented the warning icon against the certificate presented by https://login.facebook.com (I always type the URL in) because it could not verify the CRL. For want of anything better to do, I downloaded the certificate chain and was surprised to see an expired entry against intermediary certificate in the chain.

The intermediary certificate was issued to www.verisign.com/CPS Incorp. by Ref. LIABILITY LTD.(c)97 Verisign

Validity Fields on this d/l certificate are as follows

From: 17/04/1997

To: 08/01/2004

When viewed in the browser though, this certificate shows an end-date of 25/10/2016

Hopefully it's not cause for concern, but I can't help wondering ...

Why would the downloaded certificate show a different end-date as compared to the same certificate online?

p.s. I tried downloading the certificate chain again to a different location, and still see an expiry date of 2004.

Improve this question

2 Answers 2

Reset to default
7

Dan Kamisky discovered and blogged about a very similar issue three months ago with Facebook. He tracked down the issue to Facebook fielding some test load balancers based on old expired VeriSign certificates. As always with his writings, the sleuthing is well done and presented in an excellent read. The bottom line in his case is there was no threat. The blog entry is a great read blog link

Improve this answer
2
  • +1: Thanks for the link to Dan's blog. Helped unruffle the feathers a bit. At the same time I'm still curious about why the intermediary certificate shows different validity period on browser, and when downloaded ...
    – Everyone
    Commented Jan 5, 2012 at 14:42
  • 2
    Understood. Strange how these discussions are further confused by Facebook actually using expired certs in their online testing. Trust is literally lost at step one....
    – zedman9991
    Commented Jan 5, 2012 at 15:08
7

In SSL/TLS, the server sends his certificate as part of a chain. The client should ascertain the server's public key, and use it to finish the handshake.

How the client should "guess" and "validate" the server public key is completely his business; the certificate chain sent by the server is, nominally, purely indicative. It is a case of: "hey, client, you need to know (and be sure of) my public key; this set of certificates could be of some use to you". As per SSL/TLS specification, the chain sent by the server should be appropriate for validation, and a client would be entitled to abort the connection if the exact chain sent by the server does not validate; but nothing states that the client must use that exact chain, and none other.

In your case, it is plausible that Chrome, upon validating the server certificate, finds that one of the certificates is stale, but succeeds in validating the server certificate using other certificates that Chrome happens to know (either it already saw them from another prior connection somewhere, or it inherently knows them). Note that knowing a certificate is not the same as trusting a certificate; there is no security issue in have access to some big, potentially insecure storage for intermediate CA certificates, because the signatures on these extra certificates will still get verified upon usage (intermediate CA certificates are not root certificates).

To sum up, the Facebook server does an invalid thing, as per RFC 5246, in that it sends a certificate chain which is obviously invalid. The same RFC 5246 still allows clients to transparently recover, provided they can patch the chain with more up-to-date certificates, and that's what Chrome does.

Improve this answer
1
  • clever - I didn't realise RFC 5246 covered that second bit (I kinda skimmed :-)
    – Rory Alsop ♦
    Commented Jan 5, 2012 at 15:57

You must log in to answer this question.

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