This seems to be a somewhat common type of problem. I wonder if companies should routinely test on machines with the clock set one year into the future to catch them before they hit customers.
I think you'd run into other problems then, for example if your test machine needs to communicate with https sites powered by letsencrypt, all those sites will appear to use certs that "expired" at least 9 months ago.
It's a mess. At one point we had a backup domain controller that had gotten incorrectly setup as a time server, and was out of sync with the rest of the world, with a slight amount of drift. Randomly, our test servers would end up syncing time from that server at times, and wind up slightly off. When the time got slightly more than around five or ten minutes off, connections (over TLS encryption) from those boxes to our Lync IM servers would start failing, and weirdness would ensue. Reboot the box, or sometimes just sign in and out, and things would straighten out, for a while. Very spooky.
This was all years ago, so my recollection may be fuzzy, but I spent entirely too much time futzing with SIP traces and certs. Weird, weird things can result from time inconsistencies is my takeaway, however.
It’s not even necessary to test. Once you’ve done it a few times codesigning is a piece of cake. But there a few flags you absolutely pay attention to or else it’s going to bite you in the ass way down the line.
Yes but the test should be, “does this key have a valid timestamp?” not spin up a VM, set the clock 10 years in the future.
BTW, most commercial installer progtams will apply a valid timestamp if codesigning is enabled. So to save ~$1000 someone decided the tools built into Visual Studio were good enough. Anyone that ships commercial software that does more than a basic install into C:\program files will know to spend the money, it’s worth it.
