About a week ago I revived an old Sony VAIO laptop (model PCG-R505TS) that hadn’t been used for a few years. It had lost CMOS contents so I had to re-enter the date and adjust a few BIOS settings.
The laptop had XP SP1 installed, which I successfully updated to SP3. Too lazy to use the built-in wired Ethernet, I plugged in a Belkin wireless PC Card instead. Windows Update successfully installed the usual bazillion of updates and the laptop was running stable, yet I was experiencing inexplicable errors and odd behavior.
Some web sites reported certificate errors, which I (erroneously, it turned out) ascribed to out of date root certificates on the system. Updated root certificates are available on Windows Update, but that’s where another strange problem hit: For whatever reason, the root certificates are an optional update and as such, require Windows to be validated (the infamous WGA). Windows Update offered to validate my copy of Windows, but the validation process eventually landed on an empty web page with no error message whatsoever. The validation did not really fail (declaring my setup a pirate copy), it just did nothing. What was I doing that was so unusual to trigger some untested error path?
The answer was, as it often is the case, deceptively simple. The clue was staring me right in the eye, when I bothered to read the detailed certificate error description in Firefox: The certificate is valid from February 1, 2014, but the system date is January 20, 2014.
Whoops! Clearly I wasn’t paying enough attention when setting the system date and selected January instead of February. But wait! Since the default XP setting is to use Internet time, Windows should have set the correct date, right?
Wrong. Manually invoking the time update revealed that since the system’s date was a month behind, the Windows time sync intentionally did not update the system clock “for security reasons”. Brilliant.
Once I corrected the system date, the laptop was much happier. Suddenly the Windows validation worked (allowing me to install optional updates), the time synchronization worked as well, and the bogus certificate errors were gone.
It’s not unreasonable that certain security-related operations fail when the local and remote time wildly differs. But why is it so hard to show an error message saying “your system thinks it’s January but we think it’s February”?
Windows has a nasty tendency to fail in very mysterious ways when the system time is more than slightly off. The fact that this also causes the automatic time sync to quietly fail is just sad. Moral of the story—if you’re having strange problems, make sure the system date and time is set correctly!
A post on the oldnewthing blog regarding this: http://blogs.msdn.com/b/oldnewthing/archive/2010/11/05/10086404.aspx#10088640
Seems I’m not the only one who thinks that quietly failing to fix system time when it’s off is not a very smart idea.
Mind you, I understand the security concern, but if the logic is that a remote time server with the time significantly off is an attempted exploit, that’s more reason to loudly notify the user, not less.
‘eanwhile, Microsoft broke that link at some point, so the post is at https://devblogs.microsoft.com/oldnewthing/20101105-00/?p=12343 (but the comments are gone).