1. Executable file X is created no later than 7 Feb 2020 23:59:59.
2. X is signed using a code signing certificate J issued by "VeriSign Class 3 Code Signing 2010 CA"[1] and with a validity no later than 7 Feb 2020 23:59:59.
3. X is counter-signed by a public time-stamping service (see RFC3161[2]) no later than 7 Feb 2020 23:59:59.
4. Even if code signing certificate J expires, Windows will continue to allow the execution of X because it is counter-signed by a trusted time-stamping service which attests that X existed at a point in time when the code signing certificate J was valid. Assuming SHA256 isn't broken, an attacker can't just throw millions of SHA256 hashes at a public time-stamping service and then hope to produce at a later date an executable that collides with one of the prior counter-signed/timestamped SHA256 hashes.
5. Windows always checks that X is signed with a valid certificate such as J, regardless of expiry dates and presence of a counter-signature/timestamp. Removal of trust in "VeriSign Class 3 Code Signing 2010 CA" means this validation of X fails, respite X still having a valid counter-signature/timestamp.
6. QuickBooks had a component QBWebConnector.exe that was signed prior to 7 Feb 2020 23:59:59 by a code signing certificate issued by "VeriSign Class 3 Code Signing 2010 CA". Even though "VeriSign Class 3 Code Signing 2010 CA" has already expired, the counter-signature from a public time-stamping service has allowed Windows to continue to execute QBWebConnector.exe.
7. Windows no longer trusts "VeriSign Class 3 Code Signing 2010 CA" and therefore, the old QBWebConnector.exe created and signed before 7 Feb 2020 23:59:59 cannot be executed. It's irrelevant whether QBWebConnector.exe is counter-signed by a public time-stamping service.
[1] SHA256:D0F90BBF6EE8629E4A31CFDBAA2202E324AF2F5F456967DD83CA5B3684C34297 (https://crt.sh/?id=163359911)
Airlock is security software. It's not their stuff that is failing -- they are dealing with reports about the issue and letting the world know what they've found.
> Over the coming months Airlock Digital customers may notice an elevated occurrence of files reporting ‘(invalid certificate chains)’ over the coming months, for software that was signed between 2006 – 2017 with revoked certificate chain.
As Airlock seems to be software intended to allowlist the execution of binaries, it would make sense that they pick up on the user running binaries signed with revoked certs.
However, Microsoft aren't doing this (their code signing ecosystem is frankly a mess compared to Apple's). Instead they're ignoring the timestamps in the signatures and breaking old binaries. Not cool.