AstroSkipper

You're absolutely right. My screenshot belongs to current user. When you compare yours to mine there is one thing strange and this is your Microsoft Root Cerificate Authority 2011. You have twice and I don't know why. If it were my system I would delete the one with "Friendly Name" <none>.

@Dave-H Once again I have reflected what additional steps I'd performed to solve MU related error codes. And the winner is: flushing the DNS cache which means clearing the DNS cache. Reasons for doing this: "It's important to flush a DNS cache for a few reasons. The first is the cache may contain outdated information. You might experience this as difficulty accessing websites or applications. If the domain name in the cache points to an old or incorrect IP address, the website won't return the correct information." quoted from https://www.google.de/url?sa=t&source=web&rct=j&url=https://www.dnsstuff.com/clear-flush-dns-server-cache-windows&ved=2ahUKEwjpz-K4utD1AhWO3KQKHdpBCWoQFnoECAUQBQ&usg=AOvVaw1UbhoAs53jSD5-BeNl42B4. Command in cmd console: ipconfig /flushdns Don't know if it can help in your case but I did it definitely.

@Dave-H This is bit disappointing. So @Mathwiz's guess has been disproved and my suggestion doesn't help too. At next I've made a screenshot of my Root Cerificate Authorities in my system beginning with "Microsoft". So you can compare if one or more are missing. There is less German so I think it won't be a problem to read. https://imgur.com/hX3nGr4

The only thing I can say in your case you have to check systematicly and seriously what is missing or going wrong. When I had all error codes someone can get and yours too I did all from scratch i.e. you have to reinstall the mentioned updates although they already exist in your system or you have to check deeply if "Restore_WU_XP_2003" has been installed actually properly and so on. It will cost more time but for me it was the only way. By the way I can't see where you come from. There is no flag in your profile but your screenshot tellls me from Asia so maybe it is country related too. And here is a link with information to your error code from Microsoft: https://web.archive.org/web/20130316104325/http://support.microsoft.com/kb/836941 And a bit older version of this article I attach below. There you can find your error code 0x80072F78 "ERROR_WINHTTP_INVALID_SERVER_RESPONSE". https://www.mediafire.com/file/gu3q9b8gtpxwblr/q836941.htm/file

@Jonuarl Reden Hi, the suggestion you've quoted is related to error code 0x800072F8F so different to yours. Have you already read the whole thread? I have made a little guide to get MU working. Look here:

I think it's not unimportant to have only one ProxHTTPSProxy CA certificate in your system. If regenerating a new one leads to getting two of them then something is going wrong. Maybe your system restores this second old one. So delete all ProxHTTPSProxy CA certificates, make a reboot at first and have a look if your system has restored the old one before regenerating a new one. And only if you want try my suggestion two posts above: "Now I have two suggestions for you. First delete both ProxHTTPSProxy CA certificates and generate a new one from 2017 to 2027 following the guess of @Mathwiz. Delete all certificates in your ProxHTTPSProxy certs folder and let ProxHTTPSProxy generate new certs for all MU related sites (www.microsoft.com, download.windowsupdate.com, fe2.update.microsoft.com, www.update.microsoft.com, update.microsoft.com and so on; you can use Wireshark or more simple NirSoft's HTTPNetworkSniffer for finding all connected sites) by using New Moon browser or Mypal. Then try to access MU using IE and look if it works. Check your settings in Internet Zone too (relevant for accessing http://fe2.update.microsoft.com). The idea is letting a new browser generate these MU relevant certificates. If that doesn't work for you you can go back to ProxHTTPSProxy CA certificate valid until 2025 which was the one originally provided. Of course you can do this all using HTTPSProxy at first too."

@Dave-H Ok, your screenshot was a bit misleading. The certificate to the right is in your ProxHTTPSProxy's certs folder and the one to the left is your system root certificate. Therefore you have two ProxHTTPSProxy CA certificates due to the fact that you haven't deleted the old one before installing regenerated certificate. Is that right? Now I have two suggestions for you. First delete both ProxHTTPSProxy CA certificates and generate a new one from 2017 to 2027 following the guess of @Mathwiz. Delete all certificates in your ProxHTTPSProxy certs folder and let ProxHTTPSProxy generate new certs for all MU related sites (www.microsoft.com, download.windowsupdate.com, fe2.update.microsoft.com, www.update.microsoft.com, update.microsoft.com and so on; you can use Wireshark or more simple NirSoft's HTTPNetworkSniffer for finding all connected sites) by using New Moon browser or Mypal. Then try to access MU using IE and look if it works. Check your settings in Internet Zone too (relevant for accessing http://fe2.update.microsoft.com). The idea is letting a new browser generate these MU relevant certificates. If that doesn't work for you you can go back to ProxHTTPSProxy CA certificate valid until 2025 which was the one originally provided. Of course you can do this all using HTTPSProxy at first too. Due to the fact that HTTPSProxy and ProxHTTPSProxy is working flawlessly for me and for other members it will work for you too. There is one thing or more you have missed and you have to find it. Don't give up!

The old trick to avoid long searches of MU was reinstalling latest cummulative IE update. Resetting of datastore.edb can help too. By the way my search lasts only seconds.

@Dave-H I am a little bit confused. In your list of Trusted Root Certification Authorities I can see two ProxHTTPSProxy CA certificates. But why is your new one issued to *.update.microsoft.com as well as to ProxHTTPSProxy CA? I do not have that. That's no good I think. The dates look as expected. But I assume you can't have both due to the fact that only one instance of ProxHTTPSProxy should use its certificate. Comparing to my ProxHTTPSProxy CA certificate I would delete the "right one" with "Issued to: *.update.microsoft.com". The ProxHTTPSProxy CA certificate belongs to ProxHTTPSProxy and not to MU website. Truth be told I would rather delete both (make a backup before incl. Certs folder) and let ProxHTTPSProxy create a new one (e.g. from 2020 to 2030 or 2018 to 2028). The idea is before generating a new certificate by ProxHTTPSProxy you have to delete its old one. One instance of ProxHTTPSProxy, one ProxHTTPSProxy CA certificate. For me it looks like a bit messed up. But maybe @Mathwiz could tell us more.

And here is my log of ProxHTTPSProxy when MU searching for updates has finished successfully: https://imgur.com/q5ezkA9 @Dave-H Comparing your log to ours I discovered you are using a more recent version of ProxHTTPSProxy. You've got urllib3/1.25.7 and we've got urllib3/1.25.3. I don't know if it is relevant.

In my system when MU searching for updates has finished successfully all connections of HTTPSProxy to MU are red. https://imgur.com/xFTx1fk And here my log more readable: https://imgur.com/GawLOUT

@Dave-H And if that fails then is my final advice to do all steps described in my post once again. Doesn't matter if you did before or not. Do it and check all mentioned problems! I did so and now it is working perfectly.

@Dave-H No, you have to set back to year 2020 and only to generate in HTTPSProxy a new certificate valid until 2030.To let HTTPSProxy do that you have to delete the old one called HTTPSProxyCA.crt. After that you can turn back time to current date and time. I did often such manipulation without any serious problems. Believe me! And the best is manipulations of HTTPSProxy don't harm your ProxHTTPSProxy installation. You can try whatever you want.

@Dave-H How did you get the log file? Where is the log file located? I couldn't find anyone. And what is about turning back time to 2020 and letting HTTPSProxy generate a new one with duration of 10 years beginning at time of creation? Certs folder of HTTPSProxy must be cleared. Then we will know whether our guess is correct or not. And check your Trusted Zone. Trusted Zone to high with only these three urls related to MU: http://www.update.microsoft.com, https://www.update.microsoft.com and http://update.microsoft.com. Disable in IE settings "Check for server certificate revocation". https://imgur.com/UBI7btL

@Dave-H Here my log of HTTPSProxy on working MU site: https://imgur.com/EZWYr7p By the way where is the log file located? I couldn't find anyone.

@Mathwiz Ok, indeed this could be the problem. @Dave-H Maybe you turn back time to 2020 and let HTTPSProxy generate a new one with duration of 10 years beginning at time of creation. Certs folder of HTTPSProxy must be cleared. Then we will know whether our guess is correct or not.

@Mathwiz Of course I don't know how long these remnants of MU will last but deleting the HTTPSProxy CA certificate in HTTPSProxy's program folder let HTTPSProxy generate a new one with duration of 10 years beginning at time of creation I think.

@Mathwiz My ProxHTTPSProxy CA certificate is valid until 2025 but my HTTPSProxy CA certificate is valid until 2030 which was recreated in 2020. I deleted all certificates in \Certs and site certificates were recreated when visiting these sites. I have installed both Proxy versions and after configuring properly they are working on Microsoft Update site without any problems.

@Dave-H Use the folder HTTPSProxy! Both are identical versions except for one file and this is config.ini. In folder HTTPSProxy there is one, in folder Update HTTPSProxy is none due to the idea you will update an existing installation and don't want to loose your settings which would be overwitten by new one. In first installation you have no config.ini so you are working from scratch. I think that was the idea of @Thomas S.. He released two versions but first release had been faulty so users had to update.

@maile3241 As I already mentioned some posts above copy your patched file first to system32\dllcache and then to system32. If it is blocked do it from outside using linux or WinPE. Restart computer and check if both files are still there. And then...hopefully... But one thing I have to say. It would be much easier if you read your posts a little bit more intently. Hope it'll work finally.

@Dave-H You have got a PM just now.

@maile3241 Fine but is your folder male? :)

@Dave-H I know and that for a long time. And therefore I asked you if I were allowed to upload HTTPSProxy due to the fact that @Thomas S. hadn't been here for a long time and he is the author. What do you think? You are a Super Moderator and I think you'll know if I am allowed to or not.

@maile3241 A normal Windows XP Professional system has a folder to backup system files to restore them. This is the dllcache folder. In most systems c:\WINDOWS\system32\dllcache\. I really don't know what kind of system you have. In my dllcache folder there are currently 3426 files. If this folder doesn't exist in your system create one and copy your patched dll into. No more I can say. But you didn't mention if now SFC is disabled and copying of wuaueng.dll is working after this long procedure. Oh @Dave-H is right. Probably you have hidden your system files. Change it in explorer.

@ExtremeGrief I could do that but I didn't. If you want to merge it's up to you. I did it my way as Frankie Boy would say (or better sing). Don't say other people what they should, could or have to do. If you want to do it "better" do it by your own!