News Update: Code Signing Certificate Status

[rconn]

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).

 

[PeterR]

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.

 

[rconn]

So far all I've gotten from Comodo is the typical Level 1 "read an unrelated issue from a script" technical support. Still waiting for a real answer. (Microsoft hasn't responded at all.)

 

[dim]

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

 

[Michael Geary]

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.

 

[timfrost]

Have you looked at the link I posted in another thread here? You first mentioned a Symantec certificate, though you are now calling it Comodo.

Many Symantec certificates have been revoked: https://www.theregister.co.uk/2018/03/01/trustico_digicert_symantec_spat/

 

[timfrost]

.... and your certificate on v21 executables (I have overwritten v22) is clearly showing here as revoked.

 

[erpomik]

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).

 

[rconn]

Have you looked at the link I posted in another thread here? You first mentioned a Symantec certificate, though you are now calling it Comodo.

Many Symantec certificates have been revoked: https://www.theregister.co.uk/2018/03/01/trustico_digicert_symantec_spat/

It's a Comodo certificate, but shows up in Windows as a Symantec.

 

[rconn]

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.

 

[erpomik]

The TCMD / TCC code signing uses the Verisign timestamp server.

However, IsLicense50.dll is not and I have no doubt, that that is what is causing the problem.

 

[drwtsn32]

However, IsLicense50.dll is not and I have no doubt, that that is what is causing the problem.

Good catch! Looks like when there is no timestamp, Windows considers it valid until the signing cert expires, which happened on 3/13/2018.

 

[pizzaman]

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.

 

[AnrDaemon]

Since Rex is using Verisign stamping servers, it may be their fault, and signing program did not fail when stamping failed.

 

[drwtsn32]

I don't think Rex signed the DLL in question.

 

[rconn]

I don't think Rex signed the DLL in question.

That's not the dll in question.

 

[AnrDaemon]

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.