Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I'm trying to monitor the HTTP requests/responses made when performing a Windows Update.

I have a Windows 8 machine configured with a proxy in IE. I've also imported via netsh for winhttp:

netsh winhttp import proxy source=ie

The proxy is running on another machine on port 8080 and is configured to intercept SSL.

I have tried both with Burp proxy or with a normal Squid proxy (using ssl_bump). The root CA certificates are installed on the Windows 8 machine, in the Local Machine store, under Trusted Root CAs. If I browse from IE or Chrome I can access https sites without a warning (as the presented server certificate is signed by the proxy CA).

However, if I try to use Windows Update I get an error:

"There was a problem checking for updates"

This is a known issue, Bluecoat advise adding an exception for SSL interception for Windows Update:


Microsoft make the same recommendation for TMG:


So it seems like the Windows Update service doesn't just check the certificate in the usual way, it actually verifies against a different CA list, or specifically requires a certain server certificate from the Windows Update site.

The question is, how can I work around this, so that I can see the HTTP requests made by Windows Update?

share|improve this question
yes windows update has it's own pinned certificate list to stop such intercepts. However there is Windows Server Update Services which is run as a server inside a network so only one place needs to download the updates across the WAN to distribute to the whole LAN. How it gets over the SSL certificate issue I'm not sure. –  ewanm89 Mar 3 '13 at 13:39

1 Answer 1

Among possible updates are updates of the default contents of the trust store itself. If Windows was using the default trust store then any CA in that store could edit a forged update which would evict its competitors. It could also alter about any part of the OS. For an OS, the path for updates is very sensitive. It would be quite risky to give the power of updates to a hundred or so of CA, not all of which can be really trusted to do their job properly (mishaps have happened, not often, but yet...).

What you might try is to add your fake certificate for the Windows Update SSL server into the "trusted publishers" store (the one for the "local computer"). Include the fake server certificate itself, not the Burp-controlled CA which issues fake certificates on-the-fly (I don't know if Burp can use a specific non-dynamic fake certificate for a given server). This store is normally for validating signatures on drivers, not for SSL servers, but given the way Microsoft handles certificates, this may work and do what you want (I don't have a Windows machine handy to try that right now).

If the Windows code does not use an easy-to-access trust store, but instead hardcodes the list of acceptable certificates for the Windows Update server, then you will have to resort to DLL modifications, like malware writes do for a living. The OS will try to actively defend against that.

share|improve this answer
The fake certificate which is suppose to be included in the store, would it not trigger as FALSE or Fake by the Microsoft CA as its not signed by its CA. Don't you think Microsoft can inject the clients certificates on the fly for the update and then remove it. –  Saladin Mar 3 '13 at 16:14

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.