We have integrated the code signing of our modules into the automatic build process. In the process
we use the signcode.exe tool to sign and timestamp our modules and install MSI packages.
The problem is that the process is not stable. Tonight the build was stopped again with:
s:\build\full_win64.rel\build\ede\tools\signtool.exe sign /d "Expisoft CSP Debug" /sha1 AB98E0775CA514F0B656AF1D09688E845B07816F /t http://timestamp.comodoca.com/authenticode win64.rel\cspdebug.msi > win64.rel\cspdebug.msi.sig
SignTool Error: ISignedCode::Timestamp returned error: 0x8007000D
The data is invalid.
SignTool Warning: Signing succeeded, but an error occurred while attempting to
NMAKE : fatal error U1077: ‘s:\build\full_win64.rel\build\ede\tools\signtool.exe’ : return code ‘0x2’
We have 4 builds running every night, and almost every morning we find that one of the builds have stopped before completing.
Does anyone else seen any problems with the comodo timestamp server?
Any ides of what to look for?
Please try the below command and let us know the status.
signtool sign /f /p /t http://timestamp.comodo.com/authenticode
I don’t understand why I should retry with the pfx in a file. As you can see from the printout the signing has succeeded but the timestamping failed.
It is a basic signing command so that I recommended it. There is no problem with our Timestamping server so please try sign your file again with your previous command and let us know the status.
I think I am seeing the same thing (different error message though, so it’s hard to tell):
EXEC : error information: “SignerTimeStamp() failed.” (-2147024883/0x8007000d)
EXEC : SignTool error : An unexpected internal error has occurred.
c:\builds.…\build.proj(279,3): error MSB3073: The command "signtool.exe sign /f cert.pfx /p **** /t Timestamp Server And Stamping Protocols | Sectigo® Official blah.exe […] " exited with code 1.
Note that I have 47 .exe files included in this command (right now, I’m just including ***.exe – and I have several projects, with bin and obj directories for each).
I’ve only been using this for a day so far, and about 4 of 20 builds has had this problem. I run it again manually immediately afterwards (no other source changes) and it works fine.