{"action":"created","issue":{"url":"https://api.github.com/repos/18F/fpki-testing/issues/2","repository_url":"https://api.github.com/repos/18F/fpki-testing","labels_url":"https://api.github.com/repos/18F/fpki-testing/issues/2/labels{/name}","comments_url":"https://api.github.com/repos/18F/fpki-testing/issues/2/comments","events_url":"https://api.github.com/repos/18F/fpki-testing/issues/2/events","html_url":"https://github.com/18F/fpki-testing/issues/2","id":135104380,"number":2,"title":"Why is the \"test3\" site (path to IdenTrust) still valid in my browsers?","user":{"login":"grandamp","id":13126304,"avatar_url":"https://avatars.githubusercontent.com/u/13126304?v=3","gravatar_id":"","url":"https://api.github.com/users/grandamp","html_url":"https://github.com/grandamp","followers_url":"https://api.github.com/users/grandamp/followers","following_url":"https://api.github.com/users/grandamp/following{/other_user}","gists_url":"https://api.github.com/users/grandamp/gists{/gist_id}","starred_url":"https://api.github.com/users/grandamp/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/grandamp/subscriptions","organizations_url":"https://api.github.com/users/grandamp/orgs","repos_url":"https://api.github.com/users/grandamp/repos","events_url":"https://api.github.com/users/grandamp/events{/privacy}","received_events_url":"https://api.github.com/users/grandamp/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":40,"created_at":"2016-02-20T17:33:13Z","updated_at":"2016-02-21T06:38:36Z","closed_at":null,"body":"[The certificate from IdenTrust to the FBCA was revoked on February 17th](https://bugzilla.mozilla.org/show_bug.cgi?id=1037590#c27), yet this certificate path remains valid through Mozilla Firefox:\r\n\r\n![image](https://cloud.githubusercontent.com/assets/13126304/13198066/d90ec6c0-d7cc-11e5-8685-ef68971aac4d.png)\r\n\r\nAs well as Chrome 48.0.2564.95 on Android 6.0.1:\r\n\r\n![image](https://cloud.githubusercontent.com/assets/13126304/13198091/a9be9142-d7cd-11e5-8008-7689a88b6f3d.png)\r\n\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/18F/fpki-testing/issues/comments/186760099","html_url":"https://github.com/18F/fpki-testing/issues/2#issuecomment-186760099","issue_url":"https://api.github.com/repos/18F/fpki-testing/issues/2","id":186760099,"user":{"login":"rmhrisk","id":1619279,"avatar_url":"https://avatars.githubusercontent.com/u/1619279?v=3","gravatar_id":"","url":"https://api.github.com/users/rmhrisk","html_url":"https://github.com/rmhrisk","followers_url":"https://api.github.com/users/rmhrisk/followers","following_url":"https://api.github.com/users/rmhrisk/following{/other_user}","gists_url":"https://api.github.com/users/rmhrisk/gists{/gist_id}","starred_url":"https://api.github.com/users/rmhrisk/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rmhrisk/subscriptions","organizations_url":"https://api.github.com/users/rmhrisk/orgs","repos_url":"https://api.github.com/users/rmhrisk/repos","events_url":"https://api.github.com/users/rmhrisk/events{/privacy}","received_events_url":"https://api.github.com/users/rmhrisk/received_events","type":"User","site_admin":false},"created_at":"2016-02-21T06:38:36Z","updated_at":"2016-02-21T06:38:36Z","body":"@grandamp re: HID/CoreStreet; I don't know of any large deployments outside the federal government using CoreStreet, though I am biased as I worked on the Valicert/Axway responder it was far superior. There are a few commercial CAs still using the ValiCert/Axway product but they basically put that product on lifesupport a few years ago and I probably wouldnt consider it anymore. Several of the largest OCSP responder deployments on the internet are based on EJBCA. I would not consider OpenCA, its a hobby project at best. I personally have my own responder that I would use if it were my infrastructure, absent that the only COTS solution i would consider would be EJBCA.\r\n\r\nre: Microsoft and OCSP, I was responsible  for the OCSP stuff at MS, so I am very familiar with the client and server behavior. I would not consider using their responder in your deployment, it was not designed for those scenarios and while changes were made to accommodate them architecturally it is not made to scale to the volumes you need, for example I would only pre-produce at this scale. As for the client behavior of switching to CRLs after it determines that it would be more efficient, yes this is a policy setting that can be configured via group policy but 50 is the default.\r\n\r\nre: Microsoft and CNG, CNG is actually just the crypto stuff youre referring to CryptoAPI; yes, I was also a PM for CryptoAPI 2 where all that is done, all URL retrievals are done via something called CryptNet, specifically CryptRetrieveObjectByUrl, the retrieval call is a blocking call and some responders perform very badly. As such it will \"time out\" in 15seconds but keep retrieving the object in the background so subsequent calls may succeed instantly even if the first call failed (the response is cached then prefetching takes over). It also limits the number of external fetches to prevent loops and DOOS like scenarios on clients.\r\n\r\nre: the Firefox thing, I have run wireshark here on my mac and linux box and I see is a IPv6 connection to the ocsp responder being denied by the server, my assumption is the fail open behavior of clients is causing the behavior in question.\r\n\r\nI will use my wife's Windows machine in the morning, disable IPv6 and see if I can force it to go via IPv4 and see what I see there with CAPI debugging enabled (http://unmitigatedrisk.com/?p=318) and let you know what I see.."}}