AstroSkipper

If you extract winUpRestore!v28.exe you see what it does. After performing you have to set up Trusted Zone once again. Only the three mentioned urls related to MU. The tool is the latest one. The web site of the author doesn't exist anymore. I think that too but I am not absolutely sure.

Did you use it before? I thought you did only the manual way I posted under "Manually reset Windows Update components (KB971058)".

Ok, due to the fact I've never had this error I forgot the exact wording of the displayed message. Have you tried the method "Turning back time" more than once? Maybe MU actually considers a certificate as invalid and we need the date and time where it was valid. Go back to my provided date in April of 2019 and try once again! If it doesn't work turn back to 2018. Try it more times. And I agree the wording "an update certificate" is misleading and can be interpreted in different ways. I have to think about that. And there is nothing to lose. Try the tool winUpRestore!v28! I have used that and it helped me. Then install the latest WU agent and after that Restore_WU_XP_2003. Only a few steps if "Turning back time" doesn't work again. While researching internet articles related to error code 0x80072F8F I've read consistently this error appears due to invalid SSL certificates used by the Windows Update site and therefore it is suggested to reregister some dll files I posted before. Here is a quotation from original Microsoft knowledge base document: Hope will never die!

Where did you see the message "an update certificate"? I am a bit confused. Here is the link of winUpRestore!v28 if interested: https://web.archive.org/web/20120711072701/http://download.mshelper.de/mshregs/winUpdRestore!v28.exe

Yes, I have all POSReady updates installed. My system had always been updated by Windows Update and if any necassary update wasn't offered I downloaded and installed it. I had some problems to get MU working again but now it is working flawlessly. No error codes. But for resetting Windows Update I used the tool winUpRestore!v28.

@Dave-H Very disappointing! I'd almost have bet on it that this last solution would work for you. But alright. Either you've missed one or more steps which had to be performed or your system is more defective than I previously assumed. Anyway you said you couldn't click the button "Check updates". Maybe due to a misconfigured Internet Explorer. MU web site has been called up as a http web site. Check your settings in Internet Zone, set it to lowest security level and unselect SmartScreen Filter in Advanced tab. Check all other settings of your Internet Explorer. At this point I don't want to conceal what the most effective method is to get rid of error code 0x80072f8f. Most of affected users performed a complete reinstallation of Windows XP and they reported it would have worked. A lot of them were assisted by remote connection to Microsoft and their experts couldn't find the cause of the problem. And what did they do? Of course a complete reinstallation of Windows XP. So what does it tell us? Microsoft itself is the causer of error code 0x80072f8f. What would I do if I were you? At first I'd create an image of my system partition, replace CMOS battery, set up BIOS settings including date and time, clean my registry to get rid of all waste due to incomplete uninstallations and so on, clean complete system and all caches, reset Internet Explorer and Windows Update, perform all steps once again (and when I say all I mean all, regardless of steps or installations I did before) and execute all solutions I've posted here if necessary. If that didn't work I'd reinstall Windows XP or better I'd restore an image which was the last working one. I do have such images. If my system fails seriously I'll restore my system partition in less than 30 minutes and my computer is a very, very old one. Cheers!

@Dave-H Have you already tried this new solution?

@Dave-H And check in form of a binary comparison one more time if the correct patched version of wuaueng.dll still exists in relevant folders. I assume in your system is SFC enabled. Just to be sure.

Of course and definitely not! And I am not omniscient. But I decide what is promising by reading, analyzing, checking facts, concluding and if possible proving. I am mathematician and that's the way these strange people like me do it.

@Dave-H Ok, here is a final solution. If that doesn't work too I'll be out of ideas related to error code 0x80072f8f. You can't find any other solutions in the World Wide Web, nay, despite a very deep research I couldn't find any other reasonable solutions related to this error code except those I've already posted. Before performing this backup the registry key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate and the folder WINDOWS\SoftwareDistribution completely or better create an image of your system partition! Here it is: This is a fix if client machines are not reporting to WSUS properly: Client-Side Script: From an administrative command prompt on your system, run: net stop bits net stop wuauserv reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v AccountDomainSid /f reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v PingID /f reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v SusClientId /f reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v SusClientIDValidation /f rd /s /q "%SystemRoot%\SoftwareDistribution" net start bits net start wuauserv wuauclt /resetauthorization /detectnow PowerShell.exe (New-Object -ComObject Microsoft.Update.AutoUpdate).DetectNow() Explanation: What is this Doing? Should I be Afraid of Running this? This client-side script is something you should not be afraid of. Let’s walk through what is happening and why we’re doing it. We stop the Background Intelligent Transfer Service (BITS), and the Windows Update Service (wuauserv) services because we’re working with items that are in use by these services. We remove the following registry keys if they exist: HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\AccountDomainSid (usually errors out but is included to be totally inclusive but I haven’t seen this since before 2005) HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\PingID (usually errors out but is included to be totally inclusive but I haven’t seen this since before 2005) HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\SusClientId (This is what is responsible for most issues – duplicate SusClientId entries across multiple clients) HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\SusClientIDValidation (This also is responsible with SusClientId) We remove the SoftwareDistribution folder from the Windows folder on the system drive – represented using a dynamic variable. This folder contains the history of Windows Update locally on the machine, but it also includes things like the cache of the downloads and temporary files that Windows Update uses. We remove this folder so that it will be recreated by the Windows Update Agent the next time it checks for updates, creating a corruption-free cache. We start the Background Intelligent Transfer Service (BITS), and the Windows Update Service (wuauserv) services. We run the Windows Update Client (wuauclt) and tell it to reset the authorization to re-create the SusClientId and SusClientIDValidation registry keys. We’ve also stuck on the /detectnow switch on the end of that command to initiate a detection for updates for Windows 8.1 systems and lower. We’ve run the PowerShell equivalent of /detectnow for Windows 10 systems and Server 2016+ systems as they no longer use /detectnow as it has been deprecated. (We can also use UsoClient.exe StartScan instead of the PowerShell line however, Microsoft never intended UsoClient.exe to be used by anything other than the system itself through the orchestrator so your mileage may vary. The correct way is the PowerShell API). Background: What is SusClientId and What Symptoms Does Having Duplicate SusClientId Entries have? WSUS servers use the SusClientId to identify unique devices and then associate the computer’s hostname to the unique identifier for easy recognizable display purposes. Because more than 1 system has the exact same SusClientId, the WSUS server replaces the computer object’s hostname with the latest hostname that communicated with the server. This gives the appearance of a magician’s disappearing act with computers objects. More than 75% of the time that clients have issues, it is due to cloning or imaging computers. Systems that are the ‘golden’ image are often created in an environment that allows the system to communicate with any WSUS server, including Microsoft’s Windows Update. The moment a client system communicates with a Windows Update server, it creates 2 registry keys that are essentially a security identifier (SID) [SusClientId] and a validation key [SusClientIDValidation] that gives a unique hardware identifier in a binary form. The Windows Update Agent is supposed to use a hardware validation routine to determine whether the current client hardware has changed since the SusClientId value was created, and if it has, it is “supposed to” regenerate both the SusClientId and the SusClientIDValidation. “Supposed to” doesn’t always equate to “does” and this is where the problem lies. Note: In my system the subkeys AccountDomainSid and PingID don't exist probably due to the fact that my computer is a stand-alone one. In your system I could see in a screenshot that the subkeys PingID, SusClientId and SusClientIDValidation are present. Therefore I've crossed out all unnecessary steps and explanations including steps for Operation Systems except Windows XP.

I don't believe that this has an effect. In my system I have same date and time format in this key although my regional settings have been set to German DE and nonetheless MU is working flawlessly. @Dave-H Any news? Does changing services mode have any effect? Here is another change to Internet Options of IE, Advanced: unselect "Check for publisher's certificate revocation" too. Note: in my system it is selected at the moment. The entry "Check for server certificate revocation" should already be unselected in any case.

@Dave-H And I've taken a short look at your status of system services. Three system services are absolutely important for MU: bits, wuauserv and cryptsvc. These services should be started and set to automatic. So please set bits and cryptsvc to automatic! And truth be told you should have seen that. Short explanation: not all services could be started if they are set to manual only. Even your web site https://www.blackviper.com/service-configurations/black-vipers-windows-xp-x86-32-bit-service-pack-3-service-configurations/ has a recommended setting of automatic (started) for service cryptsvc. And in my screenshots too. Maybe bits works with mode manual too, seems to be standard but in my system I've set it to automatic. By the way thanks for this interesting link!

No problem but a little bit funny. Read post above!

@Dave-H The idea was only showing Microsoft system services in window of ServiWin sorted by company. Please new screenshots! And you may and should stay at HTTPSProxy but you know you can have both. They are portable and have their own certificates. We have fixed a lot in your system, maybe something has changed and ProxHTTPSProxy is now working you'll never notice. It's just a game called trial and error. PS I don't know how you usually start ProxHTTPSProxy but it has to be started by ProxHTTPSProxy_PSwitch.exe to let it change proxy settings automatically.

@Dave-H Requested certs have been sent via PM. And give your ProxHTTPSProxy a second chance by installing original certificate in program folder. For this purpose apply ProxHTTPS Cert Install.exe. Maybe your generated HTTPSProxy CA certificate is problematic when you try to connect to MU. You know my HTTPSProxy CA certificate has a different timestamp. And don't forget to close HTTPSProxy by clicking exit in systray menu if using ProxHTTPSProxy.

Of course the 10th of March 2021. I'll send you missing certificates as soon as possible. I think they aren't unique, only made for my system. They are from Microsoft. And try method "Turning back time" at all costs! But now Microsoft Update isn' t working anymore. You have to check all including status of all services. And please send me your screenshots listed by ServiWin. Comparing with help of your log file is too tiring.

@Dave-H A little correction. I meant registry key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate and there the value of LastRestorePointSetTime. Here is my value: 2019-04-12 13:45:09. You see it's your English format. Try the point in time you have there first! Then you may try other points in time. The method "Turning back time" can mean to go back one year or one day. You just have to try out. It's trial and error. Maybe it works. I'll forgive you due to your "senior moment". But where is the 'Use HTTP 1.0' option? I have only these entries: Use HTTP 1.1 and the Use HTTP 1.1 through proxy connections. If there wasn't both entries it had to be assumed that your Internet Explorer was not properly installed or is faulty. Anyway, look at last post of me above to download screenshots of my services in better quality.

@Dave-H Do you want me to upload these missing certificates via PM or not? Your decision. By the way I found out that on platform imgur images in jpg format have a bad quality due to strong compression. Therefore here a link of my two screeshots of all Microsoft services existing in my system listed by ServiWin but more readable plus all services in a txt file: https://www.mediafire.com/file/odq8y7iyx7i5kdf/Microsoft_services_-_AstroSkipper.7z/file

@Dave-H Due to the fact that the Microsoft service HTTP-SSL was disabled in your system I think it is a good idea to compare our Microsoft services and their status generally to be sure all necessary system services are still working. There might be some services not being essential but anyway in my system Microsoft Update is working properly. To do that download the tool ServiWin 1.71 from NirSoft. Here is the homepage link: https://www.nirsoft.net/utils/serviwin.html and here the download link: https://www.nirsoft.net/utils/serviwin.zip. It's portable so there is nothing to install. I've taken two screeshots of all Microsoft services existing in my system listed by ServiWin. Columns with German description have been faded out. So it's much easier for comparing. Here they are: https://imgur.com/az67Jo6 and https://imgur.com/bIQ2jIN.

@Dave-H What about the 5 missing certificates under Intermediate Certification Authorities? You didn't mention it. In the next days I'll post another very interesting solution to fix your problem. I still have to work it out a bit. Of course if turning back time doesn't help! Now I'll go to bed. Cheers!

@Dave-H Maybe your Internet Explorer installation is faulty. Just a guess!

Here the DNS servers I suggested: Google Public DNS. 8.8.8.8. 8.8.4.4. and Cloudflare. 1.1.1.1. 1.0.0.1. Try them! And here's another fix referring to error code 0x80072f8f I have found while researching: Open in a registry editor the key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\LastRestorePointSetTime. Here you can see a date and a time (that's my idea to find a suitable point in time). Now go back to this date and time plus for example one hour. Try to access MU. Reboot. Then adjust clock to current date and time. Do a synchronization. Reboot. Then try again! The idea is to go back in time to the last successful update on MU web site and try to access the MU server. Some people had success with turning back time to solve error code 0x80072f8f. And here a screenshot of my Internet Options - Advanced referring to HTTP settings: https://imgur.com/EHW7rix

@Dave-H Ok, thanks for further details! I have compared our lists of certificates intently. If you had compared our lists of certificates intently too you would have realized that only one of them is identical. And that is the list of certificates referring to Microsoft in Third Party Root Certification Authorities. But in my list of Intermediate Certification Authorities I have 8 certificates referring to Microsoft and you only 3. Have a look! That's a big difference. If wanted I can upload these missing certificates via PM so that you can import them under Intermediate Certification Authorities. As I told you two posts above expired certificates can still be required and in use too. At last I have analyzed your Windows Update Log once again. Here the interesting lines: 2022-02-01 22:53:27:781 1856 9b0 PT +++++++++++ PT: Synchronizing server updates +++++++++++ 2022-02-01 22:53:27:781 1856 9b0 PT + ServiceId = {7971F918-A847-4430-9279-4A52D1EFE18D}, Server URL = https://fe2.update.microsoft.com/v6/ClientWebService/client.asmx 2022-02-01 22:53:28:796 1856 9b0 Misc WARNING: Send failed with hr = 80072f8f. 2022-02-01 22:53:28:796 1856 9b0 Misc WARNING: SendRequest failed with hr = 80072f8f. Proxy List used: <https=localhost:8080> Bypass List used : <<local>> Auth Schemes used : <> 2022-02-01 22:53:28:796 1856 9b0 PT + Last proxy send request failed with hr = 0x80072F8F, HTTP status code = 0 . . . 2022-02-01 22:53:28:796 1856 9b0 PT WARNING: GetConfig failure, error = 0x80072F8F, soap client error = 5, soap error code = 0, HTTP status code = 200 2022-02-01 22:53:28:796 1856 9b0 PT WARNING: PTError: 0x80072f8f 2022-02-01 22:53:28:796 1856 9b0 PT WARNING: GetConfig_WithRecovery failed: 0x80072f8f 2022-02-01 22:53:28:796 1856 9b0 PT WARNING: RefreshConfig failed: 0x80072f8f 2022-02-01 22:53:28:796 1856 9b0 PT WARNING: RefreshPTState failed: 0x80072f8f 2022-02-01 22:53:28:796 1856 9b0 PT WARNING: Sync of Updates: 0x80072f8f 2022-02-01 22:53:28:796 1856 9b0 PT WARNING: SyncServerUpdatesInternal failed: 0x80072f8f 2022-02-01 22:53:28:796 1856 9b0 Agent * WARNING: Failed to synchronize, error = 0x80072F8F 2022-02-01 22:53:28:796 1856 9b0 Agent * WARNING: Exit code = 0x80072F8F As we already know Microsoft Update 0x80072f8f error code means ERROR_INTERNET_SECURE_FAILURE ErrorClockWrong. What does it really imply in your case? You can see it in your Windows Update Log. Look at bold text! A client fails to contact its server. In your case client is your computer and server is Microsoft Update Server. Request sent from your computer to MU failed. Synchronizing of client and server failed. Getting configurations failed. That' your problem. What is the conclusion? The connection and synchronization failures between client and server have to be fixed. At first we have to think about what we've already restored and fixed. The Windows Update Agent looks fine and you have reported that all steps of my post "Manually reset Windows Update components (KB971058)" have been performed: Have you performed step 4 too or have you skipped it as recommended? If you skipped step 4 then it should be catched up. Furthermore I added another registering of a DLL component: in step 6: Perform this registering to complete step 6. Now some settimgs: Go to IE Internet Options, Advanced and click to select the Use HTTP 1.1 and the Use HTTP 1.1 through proxy connections check boxes if not already selected. Next check if system service HTTP-SSL has system been started. If not start it and set it to Auto Start. Now reboot your computer, try to access MU again and post your Windows Update Log. If these tips don't solve the problem I have another one: Change your DNS servers to Cloudflare or Google and check if it helped. I use often DNS servers of Cloudflare but at the moment the servers of my provider. So far from me today!

@Dave-H I've read an interesting article of a person who had same error code and the solution was a missing certificate in a chain of certificates. Check if following certificate exists under Trusted Root Certification Authorities: GTE CyberTrust Global Root valid until 14.08.2018. I know it has expired but I've read that such expired certificates can still be in use. It's just a try. Furthermore I've found another tip that obviously others had helped: And one more question: Do you have a normal installation of XP or are you running it in a VM? Is your computer a clent or server in a network or a stand-alone one?

@Dave-H Yesterday I had trouble to access Google and other web sites using HTTPSProxy. What had happened? I checked and found out that HTTPSProxy's cacert.pem was faulty. I downloaded a new one manually from this link https://curl.se/ca/cacert.pem and copied it in HTTPSProxy's program folder. I deleted all certificates in certs folder and after starting the proxy I could access all sites without any problems. Updating cacert.pem in SysTray menu is working again. So what is the teaching of that? You have to check and deeply too. Comparing two files only due to size and date is not enough. A binary comparison is necessary or comparing hash values. You can do it for example with Total Commander. So download a fresh cacert.pem from link above and compare it to yours just to be sure your certs are valid and proper in your HTTPSProxy's program folder. Here is a screenshot of my Intermediate Certificate Authorities (there are Microsoft related certificates too): https://imgur.com/G2ogHnj I don't know if they are relevant, they seem to be expired. And here my Third Party Root Certificate Authorities: https://imgur.com/vY3dnq8 What is your current time server? And please upload a new WindowsUpdate.log! Maybe something has changed. A lot of Windows users have reported getting error code 0x80072f8f due to activation problems. So my next question. Is your Windows XP Professional properly activated? Do you have Windows Genuine Advantage (WGA) Validation Tool installed and what is your version? As far as I know the latest version for XP is 1.9.40.0. And I know a lot of questions. Sorry!