This helps Sea of Thieves and Master Chief Collection which timeout in Xbox login window on some instances (probably dependent on region / servers which might be using different Xbox servers and certificates). This is technically a regression although probably not from the latest development cycle. So I am not entirely sure if this is for code freeze, there are some rather extensive changes but leaving it to Hans for final judgement.
There are a few things going on there. Firstly, the certificates revocation checks through OCSP always fail, which is not fatal for login window functioning but causes the revocation requests not to be cached but evaluated each time (making the core issue, when reproducible, always happen on consequent attempts). There are two problems:
1. For one of the two concerned certificates, OCSP server (http://oneocsp.microsoft.com/ocsp) returns bogus OCSP response (the data length is one byte short for the outermost ASN sequence). This response can't be decoded by openssl program and also is marked as malformed by Wireshark. That only happens when OCSP request is sent using GET http verb and works fine with POST. The attached test program (which has problematic certificate data embedded) allows to see what happens on Windows when recording the traffic with Wineshark. Windows sents request with GET just like we do, and also receives similar bogus OCSP response. But then Windows falls back to POST request and gets the normal response. Patch 3 implements that (keep alive connection on first GET request is also the case on Windows).
2. Then, the two certificates (one of those is the same as in p. 1. embedded in the attached test program) fails to parse (while now it is correct). That is addressed by patch 2 (see [1], Page 9, SingleResponse definition, there is tag "[1]" for singleExtensions but current implementation assumes "[0]"). Patch 1 addresses similar issue with different response extensions and has embedded test. I didn't embedded for patch 2 because it is a bit involved generating such a certificate with openssl and the change corresponds to spec, and it is also tested by attached test program (while may try to generate such a test certificate if that is deemed necessary, or include MS server response in Wine test for parsing if it is not deemed undesirable).
Then, the core problem I think which might be the major trigger of the issues on some instances is that the certificate revocation check is invoked with CERT_VERIFY_CACHE_ONLY_BASED_REVOCATION, but we ignore that in OCSP (thus it might be taking a lot of time and lead to app's timeout if OCSP server is unavailable while the app explicitly requests cache-only check). This looks sort of flaky for embedded test because we'd need some dedicated test OCSP server for that, OCSP servers in the wild tend to change (e. g., that happened with the currently present revocation OCSP check, the server replies with "access denied" OCSP response while the test still succeeds through CRL fallback). This is also tested in the attached program (which manually clears certificate revocation check cache).
1. http://oneocsp.microsoft.com/ocsp
[revoccheck.c](/uploads/118e1d3e30b0f6c72505bdfa6d72fc57/revoccheck.c)