Share via

IE and Edge ignore PAC (proxy auto config) file

Anonymous
2019-06-19T19:06:13+00:00

IE and Edge are ignoring PAC script file. The file is on a webserver using HTTPS. If changing the URL to HTTP it works fine. Is there any known issue with Windows? I started seeing this behavior with Windows 10 Build 1903 but I'm not sure if it wasn't present on previous builds.

Again, using https://someserver/script.pac does NOT work. Using http://someserver/script.pac works.

Note: This could potentially be an issue with WinHTTP, as other browsers work perfectly, like Firefox or Chrome. I'm not sure but I think they use WinINet.

Windows for home | Windows 10 | Internet and connectivity

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

0 comments No comments

16 answers

Sort by: Most helpful
  1. Anonymous
    2019-07-01T13:44:16+00:00

    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.”

    Was this answer helpful?

    8 people found this answer helpful.
    0 comments No comments
  2. Anonymous
    2019-06-25T09:19:52+00:00

    Self signed certificates are working. How comes?

    Can you send the number of the support ticket or copy the whole response here?

    The whole response was:

    "We found that hosting the PAC file on a HTTPS site is never supported by us  and it’s a By-Design behavior to see this since the CRL-check for the HTTPS-site requires the PAC file again(doesn’t work with https and works with http). Chrome had the same previously and they recently agreed to resolve this request which you see.

    As far as IE and Edge are considered- due to the Certificate Revocation List option in the settings that comes into picture while considering secure connections, it ensures that a secure channel is established correctly (via SSL connection) and the SSL-tunnel requires validation - and that will require another http-request. So this was never supported by us even previously( I suspect that it had worked previously if they access the CRL before checking the PAC file path and browse).”

    Not sure I follow that logic though. Why did it work in 1809 without a problem and why does Chrome work without a problem on 1903?

    Was this answer helpful?

    4 people found this answer helpful.
    0 comments No comments
  3. Anonymous
    2019-06-24T17:37:41+00:00

    Anybody?

    Isn't it a critical problem/show stopper?

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments No comments
  4. Anonymous
    2019-06-20T21:30:28+00:00

    Andre,

    Changing user agent string does not change behavior. We're still seeing the same issue. The only way to circumvent this, as far as I've seen, is using HTTP instead of HTTPS for the PAC script url.

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments No comments
  5. Anonymous
    2019-06-19T19:09:58+00:00

    Hi Eduardo

    My name is Andre Da Costa; an Independent Consultant, Windows Insider MVP and Windows & Devices for IT MVP. I'm here to help you with your problem.

    Because Windows 10 1903 is very new, this is an issue the engineers are not aware that might need to be fixed.

    I would recommend you file a bug report; send me the short link so I can vote on it and bring it to the attention of the Windows engineers.

    https://windows10.help/blogs/entry/54-how-to-su...

    You can also try changing the user agent string in Edge and IE to see if it works:

    https://www.groovypost.com/howto/change-user-ag...

    Information in the above link is sourced from a trusted Microsoft MVP blog.

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments No comments