read the command for signing their code, and signed their code as instructed.
Today, the certificate they signed a driver with expired, and because the signature wasn't timestamped it means Windows can't know if the driver was signed with the certificate after it expired, so the signature is now treated as expired as well, so Windows doesn't trust the driver.
Why wasn't it timestamped? Probably because instructions like the link above treat that as a separate subject to signing your code, and when you sign your code it looks and works like it's fully correctly signed.
Your same link also explains how to sign a file with a timestamp as well, and contains a link on how to add a timestamp after the fact. It doesn't pretend to know what the best practice is for your specific use case of the signing tool is.
> Your same link also explains how to sign a file with a timestamp as well
Sure, further down it explains how to use signtool to timestamp something, but why would someone trying to get an app signed care about using the tool for timestamping?
> where Microsoft does talk about when you should be timestamping
If someone finds that article first, and reads to the bottom of it, it explains that timestamping is related and important and says the times you should be timestamping are "you should definitely do this", so perhaps a design that isn't a foot-gun would have "do this" as the default, with a --force option and alarmist warnings for anybody who has a reason to have their signed executables expire one day.
Design oversights and user mistakes like these will happen, but it doesn't mean influences and causes can't be identified and improved.
(most of the builds at the company I work for had not been timestamped either)
