Does an expired timestamping certificate invalide the Code Signing?

Question

TL;DR Question

Does the expiry of the Timestamp Certificate have any bearing on the validity of the signed file (under normal Windows operation)?

Preamble

The basics of Code Signing and Timestamping can be found at various locations:

So, the gist is: You sign your code with a Code Signing certificate and then sign it with a timestamp authority to make sure the point-in-time of the signature is recorded.

The problem is that I haven't any good explanation of what happens when the timestamp cert expires.

Problem

I am unable to observe when and if Windows 10 will ever report expired certificates on either side. This was prompted by trying to analyze what will happen to my binaries and setups once the timestamping certificate has expired, but it can be demonstrated using an older setup executable on Windows (so I don't need to anonymize anything here):

I have an old Skype Setup lying around here:

Skype-8.55.0.141.exe
2022-01-04
...

(File currently still available at https://download.skype.com/s4l/download/win/Skype-8.55.0.141.exe)

When I run this through signtool.exe I get the following output:

D:\Temp>"c:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x64\signtool.exe" verify /pa /all /v Skype-8.55.0.141.exe

Verifying: Skype-8.55.0.141.exe

Signature Index: 0 (Primary Signature)
Hash of file (sha256): E3B908069A92B8F729C7A049DEBD28FCB788218CF337BD45858FA1C5F9420DA2

Signing Certificate Chain:
    Issued to: Microsoft Root Certificate Authority 2011
    Issued by: Microsoft Root Certificate Authority 2011
    Expires:   Sun Mar 23 00:13:04 2036
    SHA1 hash: 8F43288AD272F3103B6FB1428485EA3014C0BCFE

        Issued to: Microsoft Code Signing PCA 2011
        Issued by: Microsoft Root Certificate Authority 2011
        Expires:   Wed Jul 08 23:09:09 2026
        SHA1 hash: F252E794FE438E35ACE6E53762C0A234A2C52135

            Issued to: Skype Software Sarl
            Issued by: Microsoft Code Signing PCA 2011
            Expires:   Fri Mar 27 21:27:19 2020
            SHA1 hash: 69B5EC76AEC591881552A0A496238A98ADA69056

The signature is timestamped: Fri Dec 13 20:02:19 2019
Timestamp Verified by:
    Issued to: Microsoft Root Certificate Authority 2010
    Issued by: Microsoft Root Certificate Authority 2010
    Expires:   Sun Jun 24 00:04:01 2035
    SHA1 hash: 3B1EFD3A66EA28B16697394703A72CA340A05BD5

        Issued to: Microsoft Time-Stamp PCA 2010
        Issued by: Microsoft Root Certificate Authority 2010
        Expires:   Tue Jul 01 23:46:55 2025
        SHA1 hash: 2AA752FE64C49ABE82913C463529CF10FF2F04EE

            Issued to: Microsoft Time-Stamp Service
            Issued by: Microsoft Time-Stamp PCA 2010
            Expires:   Thu Feb 11 23:40:37 2021
            SHA1 hash: 76B2B4193E340864CDF670A700DD22CCBEA9D4C9


Successfully verified: Skype-8.55.0.141.exe

Number of signatures successfully Verified: 1
Number of warnings: 0
Number of errors: 0

D:\Temp>echo %DATE% %TIME%
30.09.2022 13:36:34,66

We have two cert chains here:

Code Signing with Issued to: Skype Software Sarl expired Mar 27 2020
Signature Timestamp Issued to: Microsoft Time-Stamp Service expired Feb 11 2021
Today is Sept 30 2022

And signtool reports: Number of signatures successfully Verified: 1 No warnings/errors. The explorer menus will also all read "Certificate Valid". Powershell Get-AuthenticodeSignature will report Valid.

Question

Does the expiry of the Timestamp Certificate have any bearing on the validity of the signed file under normal Windows operation?

Do the expiry dates of the root certificates have any bearing?

Background check

While trying to find an answer, I found "Why should we set a timestamp when we do a codesigning?", where the answer states:

((@user:47961)) Update: the timestamp is also signed with a certificate. This signature is also validate using regular rules, which means that the certificate used to sign the timestamp must be valid at the moment of signature validation. In the above example if the timestamping certificate expired on the 1st of April, 2012, then the timestamp will be reported as not valid and won't be counted during validation of the signature.

Followed by a comment discussion:

This statement "certificate used to sign the timestamp must be valid at the moment of signature validation" and the example given in the last update at the end is wrong ... The timestamp certificate need to be valid only during the signing of timestamp not while validating. – Byju Veedu Nov 20, 2014 at 6:11

...

@EugeneMayevski'AlliedBits , you mentioned after the timestamping certificate expires, the timestamp will become invalid. As I checked, ... example, its signing certificate expires on 2003-12-19, while its timestamp signing certificate expires on 2004-01-07. However, as I view it from today, Windows 10 still reports that the digital signature is valid. ... – robbie fan Jan 3, 2019 at 3:16

...

@robbiefan this behavior contradicts to the general rules of how certificate validation works. After 2004-01-07, the signature is not valid. If Windows 10 accepts it, such behavior violates the validation rules ... – Eugene Mayevski 'Callback Jan 3, 2019 at 14:10

So, what is going on with checking expired timestamped Code Certs on Windows (10)??

I have found a counterexample -- https://stackoverflow.com/a/30514676/321013 -- where a user mentions:

I can verify from my painful experience today: an expired timestamp certificate (in my case, Comodo's timestamp cert) will cause Windows (7) to fail the overall code signing check (signtool.exe) with error 0x80096005.

But there are no more details in this answer or comments.

So, will it fail? When? How? Has it changed in Windows versions?

You cannot sign a file using an expired certificate. Previously signed files will continue to be accepted after the expiry of the certificate in my experience. With that last post, it looks like signtool did not accept the certificate, not the OS. All my old signed executables, cat files and MSIs continue to work years after signing. — Clifford, Sep 30 '22 at 12:15
Note that you can see a file's certificate info through its properties in Explorer. It does not need signtool. — Clifford, Sep 30 '22 at 12:23
@Clifford - of course I wouldn't try to *sign* with an expired cert. And, yes, I already mentioned in the Q explorer and also Get-AuthenticodeSignature. -- " All my old signed executables, cat files and MSIs continue to work years after signing" - that is my and others observation. Some (see links) disagree. Hence question. — Martin Ba, Sep 30 '22 at 14:06
Well they are incorrect. If you had say some old documents created with a tool no longer available or updated, if you could no longer install or run that tool because it's cert had expired, you would loose access to all that content. That does not happen. In some cases and jurisdictions, it would possibly be illegal. I am not sure what the point is of asking the question, if given an answer, you are still going to doubt it due to the previous answered cited. I am pretty certain it is an OT question, which is why I only posted a comment. It is about how the OS handles certificates, so OT. — Clifford, Sep 30 '22 at 18:53
"If you had say some old documents created with a tool no longer available or updated, if you could no longer install or run that tool because it's cert had expired, *you would loose access to all that content. That does not happen."* - the Q never asks whether Windows will somehow block anything. It simply asks what the expiry of the timestamp certificate means for the Authenticode Signature as a whole. If you can provide a technical answer, possibly based on the relevant RFC, or official MS docs, please go ahead. Otherwise I heard your opinion. — Martin Ba, Oct 03 '22 at 09:58
The question is off- topic. You are asking the question in the wrong place, so I will not post an answer. Comments are not answers, I have not claimed to have an answer. I must say that your belligerent attitude to anyone trying to assist in good faith is extraordinary. If the information is not applicable perhaps the question is unclear, or because you asked in the wrong place, the appropriate expertise is not available. — Clifford, Oct 03 '22 at 12:31