I want to use the timestamp option /t resp. /tr of the Microsoft Visual Studio signtool tool. The timestamp service I have in mind requires authentication. For this purpose you get a personalized soft token to identify yourself at the timestamp server.
My question: Is this authentication supported by signtool? In other words: does signtool support RFC 3161 (Time-Stamp Protocol) and RFC 2246 (Authentication)?
Thank you
Related
Recently our SafeNet Authentication Token used for software and driver signing expired (Symantec) and we ordered a new one (now Thales, bought Symantec?).
The expired one had these CAs:
VeriSign Class 3 Public Primarey Certification Authority - G5
Symantec Class 3 Extended Validation Code Signing CA - G2
The user certificate has the intended Purpose: Code Signing
The replacement token has these CAs:
Digicert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1
Digicert Trusted Root G4
The user certificate has the intended Purpose: Code Signing
With the old token:
We could sign driver and catalogs and use these direct on
PCs without Secure Boot. We could attestation sign these drivers at Microsoft
to get them to work on PCs with Secure boot.
With the new token:
We can sign drivers and catalogs. We can attestation sign these drivers at Microsoft to get them to work on PCs with (and without) Secure boot.
But they no longer work on PCs without Secure Boot.
The device manager presents this:
Windows cannot verify the digital signature for the drivers required
for this device. A recent hardware or software change might have installed
a file that is signed incorrectly or damaged, or that might be malicious
software from an unknown source. (Code 52)
The driver itself presents the new signature:
And a nice chain of trust:
One possibility to get this still working on the test PCs,
would be to disable driver verification using "bcedit".
But I would not like to force beta testers to do it. Also, I do
not want to manually "attestation sign" every CI build...
This wrecks out CI infrastructure and automatic test environment.
My questions:
Is this intended behavior with new code signing tokens?
Did we receive a bad or not-good-enough token as a replacement?
This is the command-line of signtool:
sign /s MY /sha1 KEY_SHA1 /n "My GmbH" /fd sha256 /tr http://timestamp.digicert.com' driver.sys
I ask this openly because I think there are a few guys in different companies
getting these issues with token updates and I hope the answers to this thread will help them (and us).
Bye Gunther
Ok today I found out:
Microsoft deprecated code signing certificates mid 2021:
https://learn.microsoft.com/en-us/windows-hardware/drivers/install/deprecation-of-software-publisher-certificates-and-commercial-release-certificates#will-we-continue-to-be-able-to-sign-non-driver-code-with-our-existing-3rd-party-issued-certificates-after-2021
Very short answer: New certificates like our new code signing dongle are not cross-signed to "Microsoft Code verification Root" or do not provide any cross certificate chain.
So our signed driver will not load in production Windows.
Possible Options for testing and debugging:
Enable testsigning:
bcdedit /set TESTSIGNING ON
In this mode any driver with or without signature is allowed.
When using signtool.exe to perform authenticode signing of executables, we want to use timestamping to ensure that the executable will still be valid in the future. It seems that the timestamping server protocol only supports http:// and not https:// out of the box. This seems like a security vulnerability on Microsoft's part.
Does anyone know how to perform signtool.exe timestamping via SSL? In other words, to use a time server https://timestamp.digicert.com instead of http://timestamp.digicert.com
I want reach the timestamp server for sign a file with signtool.exe behind a firewall, this is my current command:
signtool.exe timestamp /t http://timestamp-server foo.exe
has sign tool some feature for set the proxy?
has sign tool some feature for set the proxy?
I think it is impossible to set the proxy with signtool.exe.
See also:
How to timestamp Authenticode signatures when our proxy requires authentication
We sign our executables on the build server. Suddenly the build server failed to build giving the error:
SingTool Error: The sepcified timestamp server either could not be reached or returned an invalid response.
After changing the timestamp server to http://sha256timestamp.ws.symantec.com/sha256/timestamp, singing did work again.
Are there any issues with our old url? Why is it not available anymore?
Could we have some (security) issues with the old signed files or the new url?
I know this is a little bit broad I just don't want to miss anything...
I asked Symantec about that, so they sent me this link: https://knowledge.symantec.com/support/partner/index?page=content&id=NEWS10071&viewlocale=en_US
By April 18, 2017, Symantec will decommission the "Legacy"
timestamping service.
(Legacy) RFC 3161 SHA128 Timestamp Service:
https://timestamp.geotrust.com/tsa
To support business continuity for our customers, we have provided the
following replacement services.
(New) RFC 3161 Service SHA256:
http://sha256timestamp.ws.symantec.com/sha256/timestamp
Important: Customers must leverage SHA256 Timestamping service going
forward, and should not use a SHA1 service unless there is a legacy
platform constraint which doesn't allow use of SHA2 service (in this
case you can use this new URL: RFC 3161 Service SHA128:
http://sha1timestamp.ws.symantec.com/sha1/timestamp).
Background and Key Industry Mandates affecting the Timestamping
services
To comply with Minimum Requirements for Code Signing (CSMRs) published
by CA Security Council and Microsoft Trusted Root Program Requirements
(section 3.14), Symantec has set up the "new" RFC 3161 (SHA1 and SHA2)
service as per specifications and requirements laid out by section
16.1 which requires FIPS 140-2 Level 3 key protection. In the near future, Oracle will be taking steps to remove SHA1 support for both
Java signing and timestamping. This will not impact Java applications
that were previously signed or timestamped with SHA1 as these will
continue to function properly. However, Java applications signed or
timestamped with SHA1 after Oracle's announced date may not be
trusted.
Working link for timestamp from another provider:
http://tsa.starfieldtech.com
You can also try:
http://timestamp.globalsign.com/scripts/timstamp.dll
http://timestamp.comodoca.com/rfc3161
You can choose KeyStore Explorer (sign tool with good GUI). It has default and not be working link http://timestamp.geotrust.com/tsa
If so, do not forget to change the unworking link in the option TSA URL (Add timestamp) with other working options.
For example, this option (link) worked for me fine:
http://tsa.starfieldtech.com
I experienced the same TSA issue starting on 2017-04-21. Switching from https://timestamp.geotrust.com/tsa to http://sha256timestamp.ws.symantec.com/sha256/timestamp fixed our problem as well, so thanks for the pointer. The specific error I received using the old URL was that jarsigner returned"java.net.socketException: software caused connection abort: recv failed."
The Verisign knowledge base article AR185, updated 2017-03-16, recommends the jarsigner arguments "-tsa http://sha256timestamp.ws.symantec.com/sha256/timestamp" where it used to recommend https://timestamp.geotrust.com/tsa . This documentation change suggests to me that the disabling of the URL may be intentional, but I don't know whether that has any implications for the level of trust of JARs signed using the old timestamp server.
Hy!
I want sign a windows .exe binary with signtool from the Microsoft Platform SDK (7.1) and add a timestamp to the signature. I have two problems with that.
The (RFC compliant) timestamp server I want to use only allows encrypted https connections, but the /tr option of signtool returns an error, if the URL is not prefixed by http://
I need to authenticate to the timestamp server prior to using it, either by TLS-Client-Authentication (using the signature certificate) or by classic HTTPS username/password login. But I can't find a way to set any of these with signtool.
Is there a way to accomplish this?