7

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.

  1. Are there any issues with our old url? Why is it not available anymore?
  2. 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...

Mat
  • 1,960
  • 5
  • 25
  • 38

3 Answers3

23

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.

Mat
  • 1,960
  • 5
  • 25
  • 38
Heldai
  • 246
  • 1
  • 2
  • 2
    Hi. Welcome to SO. Its better to put some description into your answer as the links can expire or become dated. Improve your answer by including your key points from the link (also keep the link). – miltonb Apr 25 '17 at 21:03
3

Working link for timestamp from another provider:

You can also try:

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

Roman
  • 19,236
  • 15
  • 93
  • 97
1

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.

Eric Boesch
  • 101
  • 1
  • 5