To anyone following this thread,
Eric Lawrence from Microsoft was great in getting the answers, and updated me, regarding the Build 1903 issue we’re facing with HTTPS PAC URLs:
“So, unfortunately the news isn't good. Basically, your best path forward is to open a product support incident with Microsoft Support. This will ensure that you're able to track progress on getting this fixed and backported to 1903.”
“Windows 10 Build 1903 introduced a revocation check for the TLS certificate found when downloading the proxy configuration script from a HTTPS URL.
To avoid a recursive loop (downloading a OCSP/CRL requires figuring out what proxy to use), flags were passed to force the revocation check to only check the local cache and not hit the network.
Unfortunately, this new check failed to also specify that a "revocation data unreachable" should not be treated as a fatal error. As a consequence, HTTPS-served PAC scripts are likely to fail to download.
This will only impact PAC scripts that rely upon HTTPS certificates that specify revocation information (e.g. Fiddler's MITM certificates don't) and HTTPS servers that do not staple a cached OCSP-response to the HTTPS handshake.”
“Basically, there aren't a lot of good workarounds here. 1. If your clients use a private PKI that allows you to generate certs without revocation information, you could use that. Or 2. If the server serving the PAC data could use OCSP-stapling to staple fresh OCSP response data to the response, this should resolve the problem.”
Me: Thanks for all the information. Is there a link to an online response I can direct others to?
“There's not, at present, a KB article or anything like that; the process that generates those is typically kicked off by the formal support incident.”