2017-04-24 4 views
7

Wir signieren unsere ausführbaren Dateien auf dem Build-Server. Plötzlich versagte der Build-Server zu geben, den Fehler zu bauen:Ist http://timestamp.geotrust.com/tsa für SignTool nicht mehr verfügbar?

SingTool Error: The sepcified timestamp server either could not be reached or returned an invalid response.

Nach dem Zeitstempel-Server http://sha256timestamp.ws.symantec.com/sha256/timestamp ändern, Singen wieder funktionierten.

  1. Gibt es irgendwelche Probleme mit unserer alten URL? Warum ist es nicht mehr verfügbar?
  2. Könnten wir einige (Sicherheits-) Probleme mit den alten signierten Dateien oder der neuen URL haben?

Ich weiß, das ist ein wenig breiter Ich will nur nichts verpassen ...

Antwort

18

Ich fragte Symantec darüber, so schickten sie mich auf diesen 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.

+2

Hallo. Willkommen bei SO. Es ist besser, eine Beschreibung in Ihre Antwort zu schreiben, da die Links ablaufen oder veraltet sein können. Verbessere deine Antwort, indem du deine Schlüsselpunkte aus dem Link einfügst (behalte auch den Link). – miltonb

1

erlebte ich das gleiche Problem TSA auf 2017.04.21 beginnen. Der Wechsel von https://timestamp.geotrust.com/tsa zu http://sha256timestamp.ws.symantec.com/sha256/timestamp hat unser Problem ebenfalls behoben, also danke für den Zeiger. Der spezifische Fehler, den ich mit der alten URL erhalten habe, war, dass jarsigner "java.net.socketException: software connection abort: recv failed" zurückgegeben hat.

Der Verisign Knowledge Base-Artikel AR185, aktualisiert 2017-03-16, empfiehlt die Argumente des Jars-Zeichens "-tsa http://sha256timestamp.ws.symantec.com/sha256/timestamp", wo es https://timestamp.geotrust.com/tsa empfohlen hat. Diese Änderung der Dokumentation legt nahe, dass die Deaktivierung der URL beabsichtigt sein könnte, aber ich weiß nicht, ob das Auswirkungen auf die Vertrauenswürdigkeit von JARs hat, die mit dem alten Zeitstempelserver signiert wurden.

Verwandte Themen