And it will do this for about 5 minutes straight before it will allow me to join the game.
This happens for each process. If Roblox has an update, I’ll be waiting 15+ minutes because it has to wait once (5 minutes), start into the new bootstrapper (5 more minutes), and only then will it start the client (another 5 minutes).
I don’t think this super-long wait time is intended.
I do not know of a date when Roblox didn’t check OCSP servers. I only encountered this recently because I tried to use Roblox behind a firewall that blocks OCSP and CRLs.
Can you share a little bit more about your use case? Blocking access to OCSP and CRL servers seems unusual and would reduce the security of the application as it cannot check if Roblox certificates have been revoked.
They are blocked globally for privacy reasons — my application firewall comes configured by default to block OCSP/CRL servers, just like it blocks DNS over HTTPS requests so that they can be intercepted and filtered.
I recently migrated to this firewall over Windows Defender Firewall because this one allows matching executable paths by regex, which is required to cope with the Roblox launcher extracting copies of itself into 2–3 brand new locations every time it updates.
Before that point, I had to disable Windows Defender Firewall systemwide for Roblox updates, as it wouldn’t recognize the new copies of Roblox, and doesn’t support suspending/prompting for connection attempts either. Roblox would get blocked-by-default, panic, and delete itself / give up before I even had a chance to create a firewall rule for it.
This new firewall does not need to be disabled systemwide in order to update Roblox.
It’s worth noting some institutional or school firewalls might also block OCSP/CRL servers or only allow their own, so this is probably worth fixing, even if having other programs installed isn’t supported.
After doing some research and trying to reproduce locally, we believe the observed behavior is caused by the operating system, not the Roblox application.
The Roblox application performs most https requests itself, but for some early requests in the bootstrapper we use APIs from the operating system instead. Our testing shows it is the https requests made using these APIs which are resulting in queries to the CRL and OCSP endpoints.
We tested the mentioned firewall on Windows 11, and cleared the OCSP and CRL caches before each test run. We did observe two CRL/OCSP related requests which were both blocked, but there was no noticeable delay in application launch time.
You may be able to achieve the desired behavior by changing the configuration of how your operating system makes use of CRL/OCSP for its Https APIs. This is outside the scope of assistance we can provide, but it does seem that Windows offers some CRL related configuration options under Control Panel > Internet Options > Advance, in the “Security” group of checkboxes.