x/sys/windows: TestWinVerifyTrust failures on windows-arm64-10 since 2021-10-31

[bcmills]

--- FAIL: TestWinVerifyTrust (0.31s)
    syscall_windows_test.go:654: ntoskrnl.exe did not verify: A required certificate is not within its validity period when verifying against the current system clock or the timestamp in the signed file.
FAIL
FAIL	golang.org/x/sys/windows	1.800s

greplogs --dashboard -md -l -e 'FAIL: TestWinVerifyTrust'

2021-11-01T13:12:37-611d5d6-4056934/windows-arm64-10
2021-11-01T13:08:16-611d5d6-732db40/windows-arm64-10
2021-11-01T02:47:30-611d5d6-fde4cc2/windows-arm64-10
2021-10-31T18:39:05-611d5d6-89c5270/windows-arm64-10
2021-10-31T18:13:09-611d5d6-fd09e88/windows-arm64-10
2021-10-31T17:52:41-611d5d6-3fa9ee4/windows-arm64-10
2021-10-31T15:36:50-611d5d6-243c5ae/windows-arm64-10

[bcmills]

It isn't clear to me why this started on Oct. 31; it does not appear to have been masked by #49217, but the only failures so far are at the most recent commit of x/sys (which fixed that issue, which was itself Windows-specific).

This test itself was added in CL 331010 for #46906 (CC @zx2c4).

This could be due to a bad builder configuration (CC @golang/release).

[zx2c4]

Think you could grab \windows\system32\ntoskrnl.exe from the affected builder? (I would do it myself but I don't have gomote access.) I'd be curious to see if I can repro locally and to see if there's something interesting about the timestamp in the signature or a lack of a timestamp and suchlike.

[dmitshur]

@zx2c4 Sure, I can get that exe. Will update this in a bit.

Edit: Shared over email.

[dmitshur]

@toothrot mentioned potentially needing to update the Windows 10 version that we use on this builder, and I'm starting to realize this failure might be directly related to that. Will discuss with Alex after he's back.

[zx2c4]

Thanks for sending me the file. It looks like this is an ntoskrnl.exe from an arm64 insiders build. Apparently test builds don't get their binaries timestamped, so when the CA for this file expired -- 10/31/2021 -- so did the file. Ordinarily there's a counter signature from a timestamp server, with that server's CA being valid for a very long time, so that the actual file CA expiring isn't an issue. But I suppose they don't bother doing these for insider build files, which makes sense. You might consider moving from the insider track to the stable track.