Apple's code signing actually has this and it's on by default. Don't ask me why it didn't help with their installers, though..

How does this help? In order to provide any security you would need to limit the time from signing, which would be very similar to just issuing the certificate for that much longer. There is no way to verify that the binary was actually signed at that time.

It uses trusted timestamping servers run by certificate authorities to sign the timestamp information.

Ok, I didn't realize that. But it still doesn't solve the problem of compromising an old certificate and creating a fake signature with your own time.

A timestamp authority is trusted in the same way that a certificate signing authority is, so you'd have to compromise a timestamp authority as well as the private keys paired with the certificate. A self-timestamped file would have the same level of trust as a file signed with a self-signed certificate.

Expired and compromised are two different things. If compromised, it will be published in a CRL with a reason flag.

The reason why certificates expire is because they will become easy to crack as computers get faster. So this would effectively be removing the expiry date. Now you can crack any old certificate and sign things claiming that you did it before the certificate expired.

As someone above has already said.

To do this, you'd need to compromise or convince a trusted timestamping authority to sign your signing request with an old date.

Does Microsoft co-sign the binary or something? If not that feature seems like it would defeat the purpose of expiring certificates.

It means that the certificate was valid at the time of signing. Trying to sign an executable after the certificate has expired will not produce a valid code-signed executable. It totally makes sense. That it is possible to make the certificate valid by simply setting the system clock (this works both on Windows and according to the article, OSX) shows that the whole certificate expiration thing is basically useless.

I'm not sure I understand. It doesn't matter if the consumer of the certificate is able to set their clock to make the certificate/signature valid because most people don't do that, but if the producer of the signature can simply set their clock to produce a signature/timestamp combination that's considered valid by a consumer regardless of their clock, then what's the point of expiring the certificate?

But yeah, it looks like Microsoft countersigns, assuming this is what that original comment was referring to: https://msdn.microsoft.com/en-us/library/windows/desktop/bb9...

It gets timestamped by the certificate authority, using their authorized servers. For example, I have a code-signing certificate issued by Comodo, and when I sign my software, it get timestamped by: http://timestamp.comodoca.com

I can't simply set that clock.

Yes I should have been more clear. A user which wants to run a signed executable with expired certificate can trick the validation process on his machine by setting the system clock back into the valid period.

But for the code-signer this trick doesn't work, the sign-tool needs to talk to a time-stamp server, usually owned by a certificate authority. I know that the Microsoft signtool.exe and the Java jarsigner can use timestamps, apparently on OSX this works too (search for --timestamp cmdline arg: https://developer.apple.com/library/mac/documentation/Darwin...)