News Update: Code Signing Certificate Status

rconn

Administrator
Staff member
May 14, 2008
10,532
94
#1
I got a response from Comodo (who issued the code signing certificate). But it wasn't particularly helpful - they said the problem is most likely due to a bad internet connection, and the WinVerifyTrust API (the Windows API that's returning the CERT_E_EXPIRED error) couldn't be returning CERT_E_EXPIRED, but actually is returning CERT_E_REVOCATION_FAILURE (unable to verify the signature) error. I responded that it was unlikely given that (1) several thousand users suddenly had a bad internet connection, and it would work if they set their system clock back, and (2) the error returned by WinVerifyTrust was absolutely, positively CERT_E_EXPIRED. No further response, but they did obliquely hint that Microsoft might have added the certificate to the CRL (certificate revocation list).
 
May 11, 2010
8
0
#2
I doubt that it is due to a bad internet connection as in our case the error occured also on all systems we registered with manual/offliine keys because the do not have and never had a internet connection.
 

dim

Dimitry Andric
May 31, 2008
204
1
Netherlands
#4
Hmm, isn't the problem that the IsLicense50.dll file (which I'm assuming is used for the licensing functionality) has an expired certificate, and no signed timestamp? The certificate expired on ‎Tuesday, ‎March ‎13, ‎2018 19:33:39, so that seems pretty likely. Note that this could be the same type of issue that hit Oculus, where they didn't add a signed timestamp to one of their files: https://www.reddit.com/r/oculus/comments/82nuzi
 
Likes: erpomik
Apr 11, 2013
5
1
#5
Agreed, as soon as I saw the email this morning I thought, "must be the same problem as Oculus." You beat me to it by a few minutes. :-)

When you sign your code, you have to get it co-signed by a timestamp server. This prevents the signature from expiring when the certificate does, because it validates that the certificate was valid at the time of signing. Once you do that, your signed code remains valid even after the certificate expires.

Here is some information on Comodo's timestamp server.
 
Last edited:
Likes: erpomik
Aug 19, 2009
16
2
#8
Hmm, isn't the problem that the IsLicense50.dll file (which I'm assuming is used for the licensing functionality) has an expired certificate, and no signed timestamp? The certificate expired on ‎Tuesday, ‎March ‎13, ‎2018 19:33:39, so that seems pretty likely. Note that this could be the same type of issue that hit Oculus, where they didn't add a signed timestamp to one of their files: https://www.reddit.com/r/oculus/comments/82nuzi
I was about to report the exact same thing. A signed peace of code needs to be timestamped, otherwise Windows refuses to load it (if the certificate is expired, that is).
 
Last edited:

rconn

Administrator
Staff member
May 14, 2008
10,532
94
#9

rconn

Administrator
Staff member
May 14, 2008
10,532
94
#10
Agreed, as soon as I saw the email this morning I thought, "must be the same problem as Oculus." You beat me to it by a few minutes. :-)

When you sign your code, you have to get it co-signed by a timestamp server. This prevents the signature from expiring when the certificate does, because it validates that the certificate was valid at the time of signing. Once you do that, your signed code remains valid even after the certificate expires.

Here is some information on Comodo's timestamp server.
The TCMD / TCC code signing uses the Verisign timestamp server.
 
Oct 24, 2011
57
1
#13
It sounds like a lack of decent support by Comodo. Under those circumstances, I suggest a new vendor is called for. The reliability of any product depends on the reliability of the suppliers.
 
Aug 23, 2010
191
2
#17
I faintly recall that one of the stamping utilities I tried has special switch to consider timestamping failure to be a (non?)fatal error. I don't recall details, sorry. I'd need to dig through my VM's and find my old buildbot config for more information. Been several hard hears since I've used it, sorry.