Code Signing Error (due to Symantec timestamping service)

Started by usheretov, August 31, 2024, 02:54:30 AM

Previous topic - Next topic

usheretov

Im having a problem with Built-in Winbatch Code Signing - all of a sudden it stopped working, nothing has changed - when I compile, I get the following error:

FAILED
File signing Error:
0

Certifiacte is intalled properly, working (previously) valid until 2026
I updated to with the latest version of WinBatch, same problem.

When I remove [ ] Use RFC 3161 Timestamp (Recommended), same problem

FAILED
Error signing file error:
-2147012889

** UPDATE **
Using the CODESIGN.WBT in samples, I was able to replicate the same problem...

after troubleshooting the problem is in the "if statement":

BEFORE:
; Sign file based on certificate data like friendly name
              certdata =  filetosign : @tab : friendlyname : @tab : desc : @tab : url : @tab : timestamp
              if p1 == 3 then  certdata := @tab : "SHA256"
              IntControl(93, p1, certdata, 0,  0)

ERROR: 0

AFTER:
; Sign file based on certificate data like friendly name
              certdata =  filetosign : @tab : friendlyname : @tab : desc : @tab : url : @tab : timestamp : @tab : "SHA256"
              ;if p1 == 3 then  certdata := @tab : "SHA256"
              IntControl(93, p1, certdata, 0,  0)

WORKS: "Notice!", "The file has been signed successfully."

also: custom timestamp server is not replaced within witnbatch, although i specifiy http://timestamp.sectigo.com?td=sha256, the old default timeserver.dll remains as a second line.

is there a way to modify Winbacth compile settings? it saves a lot of time to compile in winbatch, and we are using a workaround at the moment that has slowed us down.


td

A simple example shows that the "tab-delimited string BROKEN" diagnosis is not correct:
filetosign = "exanok.wbt"
friendlyname = "example cert"
desc = "Example"
url = "https:\\example.com"
timestamp = "http://timestamp.sectigo.com"
p1 = 3

certdata =  filetosign : @tab : friendlyname : @tab : desc : @tab : url : @tab : timestamp
certdata1 = filetosign : @tab : friendlyname : @tab : desc : @tab : url : @tab : timestamp: @tab : "SHA256"
if p1 == 3 then  certdata := @tab : "SHA256"

if certdata == certdata1 then Text = 'Same'
else Text = 'Different'
Message('Comparision Result', text)

Currently, there is no way to change the time stamp URL in the compiler. It is not uncommon for certificate authorities to have problems with time stamp servers so it may be a temporary issue. It could also be the case that Digicert has dropped support for the Symantec timestamp server.

We will consider adding the ability to change the timestamp URL in the next release. In the interim you could write a simple script to run the compiler in silent mode without code signing and sign the file after the compile is complete using IntControl 93. It should be almost as fast as signing using the compiler.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

usheretov



I still have this problem, and it has always woked before, now its not working anylonger.

Let me know what you think

https://prnt.sc/w9d2HEbDGJNa

usheretov

I see the time stamp server was shutdown: https://docs.digicert.com/zf/whats-new/change-log/certcentral.html

August 14, 2024
DigiCert shutting down Symantec timestamping service
On August 14, 2024, at 17:00 MDT (23:00 UTC), DigiCert will shut down our Symantec timestamping service. DigiCert customers who are still relying on this service must use the DigiCert timestamping service instead.

Note: The Symantec timestamping service shutdown was originally scheduled for July 24, 2024 and then postponed until July 29, 2024.

How does this affect me?

Do your code or document signing signatures use the Symantec timestamping URLs listed below?

sha256timestamp.ws.symantec.com

sha256timestamp.ws.digicert.com

No, I don't use the Symantec timestamping service.

Then, no action is required. This change will not affect your signing processes or signed code and documents.

Yes, I use the Symantec timestamping service.

Then, action is required. This change may affect software build processes, end users trying to verify if a software update is legitimate or end users trying to verify that a signed document is still valid.

For example,

Software build processes may be broken by executables signed with the legacy Symantec timestamp service after August 14.

Documents and code signed with the legacy Symantec timestamp service after August 14 may not retain the desired date of existence or execution.

What do I need to do?

By August 14, 2024, you must update your code signing and document signing processes to use the DigiCert timestamping URL: timestamp.digicert.com.

Additionally, you may need to add the DigiCert timestamping service domain or IP address to your allowlist:

timestamp.digicert.com

216.168.244.9

usheretov

The below workaround seems to work for me now (not sure for how long), but compile is working again.

I would hope that WinBatch corrects/adds the ability to change the timestamping serivce, since its already avalable to do so, but does not properly remove/replace the default embedded address which is NOW obsolite.

*** WORKAROUND ***

Edit your local HOSTS file located in C:\Windows\System32\drivers\etc (you need to copy to the desktop and edit with notepad)

Add:
216.168.244.9   sha256timestamp.ws.symantec.com

td

Yes, I suspected that Digicert shutdown the Symantec timestamp server after you posted the topic originally. Note the comment in the first reply, "It could also be the case that Digicert has dropped support for the Symantec timestamp server." We just hadn't confirmed it yet.

Digicert's workaround is a good temporary solution and a nice find on your part. The Compiler's interface will be modified to accept a timestamp URI in the next release.

Thanks for bringing this to our attention.

FWIW, an easy way to modify the hosts file is to download MSFT's "Power Toys" app. It has a hosts file editor that takes care of some of the syntax and permission problems automagically.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade