Thanks for the report, there isn't a vulnerability here so I'm dropping view restrictions.

+rsleevi for net/SSL expertise

Your Chrome version is ridiculously out of date. Please update to the latest version and then see if the problem reproduces.

Please also include the site that you are testing, and a chrome://net-internals log (see https://dev.chromium.org/for-testers/providing-network-details for details)

I updated my Chrome to Version 49.0.2623.87 m (64-bit)
But the problem still seems to exist on websites like:

https://www.ing.nl/
https://community.spiceworks.com/
https://community.norton.com/forums

It appears that you either cancelled logging too early, or you started logging too late.

To best reproduce this problem, close all existing tabs, including the last tab (which will then close Chrome). Then, restart chrome, open chrome://net-internals, and attempt to access the sites in question. After doing so, export the chrome://net-internals and attach to the bug.

IT seems i failed at it indeed, i captured some more events this time

Tried the following websites:
https://www.ing.nl/particulier/index.html
https://www.abnamro.nl/nl/index.html
https://community.spiceworks.com/
I attached a screenshot of the Components status of Google Chrome.

Deleted: Components status.PNG 34.1 KB

	Components status.PNG 34.1 KB View Download

Thank you for providing more feedback. Assigning to requester "rsleevi@chromium.org" for another review.

For more details visit https://sites.google.com/a/chromium.org/dev/issue-tracking/autotriage - Your friendly Sheriffbot

Any update on the issue?

There is no G3 certificate in the verified chain (Spiceworks to G4 to G5). Are you sure it's working in IE? The logs are more indicative of it being handled by a CryptoAPI DLL.

Does the problem exist in Chrome Canary ( https://www.google.com/chrome/browser/canary.html ) ?

Given that Forefront TMG is present, I would also encourage you to make sure that Root Autoupdate is enabled on both your client and your TMG server. Microsoft did have some issues with an Authroot update regarding Symantec certs, so I can't rule that out.

You can also rule out that Windows is causing this by enabling CAPI 2.0 logging - https://blogs.msdn.microsoft.com/benjaminperkins/2013/09/30/enable-capi2-event-logging-to-troubleshoot-pki-and-ssl-certificate-issues/ or http://unmitigatedrisk.com/?p=297 provide details

In particular, CertVerifyCertificateChainPolicy events and CertGetCertificateChain events will indicate if the OS view (on either client or TMG server) is presenting it as revoked, which is the current hypothesis.

Also, can you attach your CRLSet file - On Windows, this is either
"%LocalAppData%\Google\Chrome\User Data\Certificate Revocation Lists" (if on Stable/Beta/Dev) or
"%LocalAppData%\Google\Chrome SxS\User Data\Certificate Revocation Lists"

Network bug triager here.   Ping, kbvkloos@ any chance you can respond to rsleevi@'s questions in #9 and #10?

Issue seems to be resolved. It seems our DNS was blocking the certificates 
White listed the following websites:
s1.symcb.com
g2.symcb.com
tj.symcb.com
g2.symcb.com
sv.symcb.com
s2.symcb.com

Blacklisting those domain names shouldn't result in ERR_CERT_REVOKED (just UNABLE_TO_CHECK_REVOCATION). Sounds like there may be a new bug to investigate here, but without further logs/diagnostics, I don't know if we'll be able to.