Referenzmaterialien

Auf dieser Seite werden die gemeinsamen Referenzinformationen des sslTrus-Remote-Codesignaturdienstes für verschiedene Integrationsmethoden zusammengestellt, darunter:

• Regeln zur Berechnung der Codesignatur-Anzahl.
• Authenticode- und RFC-3161-Zeitstempelprotokolle.
• Häufig verwendete Zeitstempelserver für die Codesignatur.
• Aspekte, die bei der Auswahl eines Zeitstempeldienstes in der Produktionsumgebung zu beachten sind.

Berechnung der Signaturanzahl

Die Signaturanzahl wird nach den tatsächlich abgeschlossenen Signaturaktionen berechnet.

Einfach ausgedrückt:

一个文件成功完成一次签名 = 一次签名次数

Die Anzahl der Signaturen wird weder nach der Anzahl der Quellcodedateien berechnet noch nach einem einzelnen Build, einem einzelnen Paket oder einer einzelnen CI/CD-Pipeline.

Zum Beispiel:

100 个源代码文件
        ↓
编译生成 1 个 app.exe
        ↓
app.exe 成功签名一次
        ↓
1 次签名

Wenn ein Build Folgendes erzeugt:

app.exe
helper.dll
installer.msi

Und nachdem alle drei Dateien jeweils signiert wurden, gilt:

签名次数 = 3 次

Grundregeln

Die Anzahl der Signaturen hängt hauptsächlich ab von:

1. Welche Dateien oder Objekte letztlich signiert werden.
2. Wie viele Signaturen jedes Objekt tatsächlich abgeschlossen hat.
3. Ob normale Client-Signaturen oder zugrunde liegende Signaturaufrufe wie KSP oder Jarsigner verwendet werden.
4. Ob das Build-Tool automatisch zusätzliche EXE-, DLL-, Deinstallationsprogramme oder Installationspakete signiert.

Zu den häufigen Signaturobjekten gehören:

• .exe
• .dll
• .msi
• .msp
• .sys
• .cat
• .jar
• Deinstallationsprogramme, z. B. uninstall.exe

Sobald ein Objekt tatsächlich erfolgreich eine Signatur abgeschlossen hat, wird es nach der entsprechenden Zählregel berechnet.

Zählung nur bei Erfolg

Nur wenn der Remote-Codesignaturdienst die Signatur erfolgreich abgeschlossen hat, entsteht eine Signaturanzahl.

In folgenden Fällen wird in der Regel nicht gezählt:

• Authentifizierungsfehler.
• Parameterfehler.
• Zertifikat nicht verfügbar.
• Netzwerkanfrage fehlgeschlagen.
• Der Server hat kein Signaturergebnis erfolgreich zurückgegeben.
• Zertifikatsabfrage.
• Abfrage von Signaturaufzeichnungen.
• Signaturprüfung.
• Entfernen vorhandener Signaturen.
• Erzeugen von Verifizierungsdateien.

Wenn der Remotedienst das Signaturergebnis bereits erfolgreich zurückgegeben hat, der Client danach jedoch beim lokalen Schreiben der Datei, beim Hinzufügen eines Zeitstempels oder bei der nachfolgenden Verarbeitung fehlschlägt, wird die bereits abgeschlossene Remote-Signatur dennoch als erfolgreiche Signatur berechnet.

Zeitstempel wird nicht separat gezählt

Der Zeitstempel dient dem Nachweis, dass die Signatur zu einem bestimmten Zeitpunkt bereits existierte, und stellt keinen neuen Codesignaturvorgang dar.

Daher:

Code-Signierung       → erzeugt Signaturanzahl
Zeitstempel hinzufügen → erzeugt keine zusätzliche Signaturanzahl
Signatur überprüfen   → erzeugt keine Signaturanzahl

Ob der Zeitstempeldienst erfolgreich ist, wirkt sich nur auf das Zeitstempelergebnis der endgültigen Signaturdatei aus und bedeutet nicht, dass eine zusätzliche Codesignatur durchgeführt wurde.

SignTool CLI

Verwenden Sie sslTrus SignTool CLI:

signtool sign \
  --cert-code CERT_CODE \
  --file app.exe

Wenn die Signatur erfolgreich ist:

1 个文件 × 1 次成功签名 = 1 次

Zum Beispiel:

signtool sign --cert-code CERT_CODE --file app.exe
signtool sign --cert-code CERT_CODE --file helper.dll
signtool sign --cert-code CERT_CODE --file installer.msi

Alle drei Dateien waren erfolgreich:

合计 = 3 次

SignTool CLI-Dual-Signatur

Wenn Sie die normale SignTool-CLI verwenden und gleichzeitig SHA-1 und SHA-2 aktivieren:

signtool sign \
  --cert-code CERT_CODE \
  --file app.exe \
  --sha1=true \
  --sha2=true

Normale CLI-Doppelsignatur wird als eine Client-Signaturaufgabe gezählt:

GUI / SignTool CLI 双签 = 1 次

Hier wird der normale Client-Signaturprozess am leichtesten mit dem zugrunde liegenden Signaturaufruf über KSP verwechselt.

Windows KSP

KSP ist die Integrationsmethode für Windows CNG Provider.

Wenn Microsoft SignTool, MSBuild, Visual Studio, Electron-Paketierungstools oder andere Windows-Software über KSP Remote-Codesignatur aufrufen, ähnelt die Zählung eher:

底层远程私钥签名调用次数

Zum Beispiel:

Vorgang	Anzahl der Signaturen
Einmalige SHA256-Signatur für app.exe	1 Mal
Zuerst SHA256, dann zusätzlich SHA1	2 Mal
Separate Signatur für app.exe, helper.dll, uninstall.exe	3 Mal

Daher:

SignTool CLI 双签 = 1 次
KSP 双签          = 2 次

Wenn das Tool mehrere zugrunde liegende Signaturvorgänge für dieselbe Datei ausführt, wird jede erfolgreiche Remote-Signatur separat gezählt.

CSP

CSP ist der traditionelle Windows CryptoAPI Provider.

CSP wird ebenfalls von Microsoft SignTool oder anderen Windows-Anwendungen über den Provider aufgerufen, um den Remote-Signaturdienst zu nutzen.

Bei der Bestimmung der Signaturanzahl gilt die tatsächlich erfolgte Remote-Signaturoperation mit dem privaten Schlüssel.

Wenn das Tool mehrere Dateien signiert oder für dieselbe Datei mehrere Signaturen ausführt, werden diese jeweils separat gezählt.

Jarsigner

Bei Verwendung des sslTrusJarsigner Providers ruft der Standard-jarsigner während des Signaturvorgangs den Remote-Codesignaturdienst auf.

In der Regel:

Vorgang	Signaturanzahl
Signieren von app.jar	1 Mal
3 JAR-Dateien jeweils einzeln signieren	3 Mal
Dieselbe JAR-Datei erneut signieren	weitere 1 Mal
jarsigner -verify	0 Mal
Keystore zur Verifizierung generieren	0 Mal

Daher:

每个 JAR 每次成功完成签名 = 1 次

Installationspaket

Bei Installationspaketen muss unterschieden werden zwischen:

1. der ausführbaren Datei im Installationspaket.
2. dem Installationspaket selbst.

Zum Beispiel:

app.exe       → 1-mal signiert
installer.msi → 1-mal signiert

dann:

合计 = 2 次

Wenn es noch weitere Dateien gibt:

Datei	Signiert	Anzahl der Signaturen
app.exe	Ja	1
helper.dll	Ja	1
driver.sys	Ja	1
installer.msi	Ja	1
Gesamt		4

Wie viele Quelldateien, Ressourcendateien, Bilder oder Konfigurationsdateien das Installationspaket enthält, hat keinen direkten Einfluss auf die Anzahl der Signaturen.

Der entscheidende Punkt ist:

最终到底有哪些产物被实际签名

Electron

Desktop-Anwendungs-Build-Tools wie Electron Builder und Electron Forge können bei einem einzigen Paketierungsvorgang automatisch mehrere Dateien signieren.

Häufige Objekte sind:

• Hauptprogramm .exe
• DLL
• Updater-Programm
• Deinstallationsprogramm
• Installationspaket .exe
• MSI
• Weitere ausführbare Hilfsdateien

Beispiel:

Artefakt	Anzahl der Signaturen
MyApp.exe	1
ffmpeg.dll	1
update.exe	1
uninstall.exe	1
MyApp Setup.exe	1
Gesamt	5

Daher:

一次 Electron Build ≠ 一次签名

Es sollte basierend auf der tatsächlichen Anzahl der signierten Artefakte und der Anzahl der pro Artefakt durchgeführten Signaturen berechnet werden.

Wenn Electron KSP verwendet und dieselbe Datei doppelt signiert wird, kann diese Datei außerdem zwei Remotesignaturen erzeugen.

Schnelle Beurteilung

Wenn Sie nicht wissen, wie viele Signaturen bei einem Build erzeugt werden, können Sie dies der Reihe nach überprüfen:

1. 最终有哪些文件被签名？
2. 每个文件签了几次？
3. 使用的是 SignTool CLI 还是 KSP / Jarsigner？
4. 构建工具有没有自动签额外文件？

Kann vereinfacht so verstanden werden:

签名次数 = 成功完成的签名动作数量之和

Besonderer Hinweis:

GUI / SignTool CLI 双签                = 1 次
KSP 对同一个文件执行两次底层签名       = 2 次
Jarsigner 每个 JAR 每次成功签名         = 1 次
时间戳                               = 0 次
验证签名                             = 0 次

Zeitstempelserver

Bei der Codesignatur wird in der Regel gleichzeitig ein Zeitstempeldienst verwendet.

Ein Zeitstempel kann nachweisen, dass eine digitale Signatur zu einem bestimmten Zeitpunkt bereits existierte. Dadurch kann die prüfende Stelle die Gültigkeit der Signatur anhand von Signaturzertifikat, Zeitstempelzertifikat, Widerrufsstatus und Validierungsrichtlinie beurteilen.

Bei der Codesignatur sind zwei Zeitstempelprotokolle üblich:

Protokoll	Beschreibung
Authenticode	Traditionelles Zeitstempelprotokoll von Microsoft, hauptsächlich zur Kompatibilität mit älteren Windows-Codesignaturprozessen
RFC 3161	Universelles Zeitstempelprotokoll, geeignet für moderne Codesignaturszenarien

In modernen Codesignaturszenarien wird in der Regel RFC 3161 bevorzugt.

RFC 3161

Eine RFC-3161-Zeitstempelanfrage sendet den Hash der zu zeitstempelnden Daten und nicht die Originaldatei.

Grundablauf:

代码签名
   ↓
计算待时间戳数据摘要
   ↓
发送摘要到 TSA
   ↓
TSA 返回时间戳令牌
   ↓
写入最终签名

Zeitstempeltoken enthalten in der Regel:

• Daten-Digest.
• Zeitpunkt der Zeitstempelausstellung.
• TSA-Richtlinie.
• Digitale Signatur der TSA.

Der Zeitstempelserver verbraucht durch das Hinzufügen eines Zeitstempels keine zusätzlichen sslTrus-Codesignierungs-Kontingente.

Gängige Zeitstempelserver

Die folgenden Endpunkte eignen sich für gängige Codesignierungsszenarien.

Vor dem Produktiveinsatz sollten die aktuellsten offiziellen Dokumentationen, Dienstrichtlinien und die Verfügbarkeit des jeweiligen Anbieters erneut bestätigt werden.

Microsoft

http://timestamp.acs.microsoft.com

Hauptsächlich für RFC 3161-Zeitstempel verwendet.

Geeignet als Zeitstempel-Kandidat in modernen Windows-Codesignatur-Szenarien.

Beispiel:

--timestamp-rfc3161=http://timestamp.acs.microsoft.com

Microsoft SignTool：

/tr http://timestamp.acs.microsoft.com
/td SHA256

Sectigo

http://timestamp.sectigo.com

Unterstützt:

• Authenticode
• RFC 3161

Kann für Code-Signatur-Tools unter Windows und anderen Systemen verwendet werden, die die entsprechenden Protokolle unterstützen.

Sectigo hat serverseitige Nutzungsanforderungen für Massenaufrufe. Produktionssysteme sollten die Aufruffrequenz gemäß der aktuellen offiziellen Richtlinie steuern.

DigiCert

http://timestamp.digicert.com

Unterstützt RFC 3161 und kann für Codesignatur-Szenarien wie Microsoft Authenticode verwendet werden.

Certum

http://time.certum.pl

Unterstützt:

• Authenticode
• RFC 3161

Die offiziellen Code-Signing-Materialien von Certum decken Signierszenarien für Windows und Java JAR ab.

GlobalSign

http://timestamp.globalsign.com/tsa/r45standard

Derzeit verwendet das GlobalSign-Codesignaturprofil diese RFC-3161-Zeitstempeladresse.

Es wird nicht empfohlen, historische GlobalSign-Adressen weiterzuverwenden, die nicht mehr in der aktuellen offiziellen Codesignaturdokumentation enthalten sind.

SSL.com

http://ts.ssl.com

RFC 3161 wird unterstützt, das traditionelle Authenticode-Zeitstempelprotokoll jedoch nicht.

Wenn das Zielsignaturwerkzeug oder Altsysteme Kompatibilitätseinschränkungen hinsichtlich des von der TSA verwendeten Schlüsselalgorithmus aufweisen, sollte vor der Produktionsanbindung eine praktische Verifizierung erfolgen.

Vergleich der Zeitstempelserver

Anbieter	Adresse	Authenticode	RFC 3161
Microsoft	http://timestamp.acs.microsoft.com	Nicht bestätigt	Unterstützt
Sectigo	http://timestamp.sectigo.com	Unterstützt	Unterstützt
DigiCert	http://timestamp.digicert.com	Nicht bestätigt	Unterstützt
Certum	http://time.certum.pl	Unterstützt	Unterstützt
GlobalSign	http://timestamp.globalsign.com/tsa/r45standard	Nicht bestätigt	Unterstützt
SSL.com	http://ts.ssl.com	Nicht unterstützt	Unterstützt

„Unterstützt“ in der Tabelle beschreibt die Protokollfähigkeit, die durch die öffentlichen Informationen des jeweiligen Anbieters bestätigt ist.

Die Richtlinien der Zeitstempeldienste können sich ändern. Vor der Produktionskonfiguration sollten die aktuellen offiziellen Informationen des Anbieters erneut geprüft werden.

Eingeschränkte Zeitstempeldienste

Einige Zeitstempelserver bieten zwar RFC-3161-Dienste an, können jedoch nicht direkt als anonyme öffentliche TSA genutzt werden.

QuoVadis

Zu den öffentlichen RFC-3161-Adressen gehören:

http://ts.quovadisglobal.com/eu
http://ts.quovadisglobal.com/ch

Dieser Dienst erfordert eine vorherige Registrierung der ausgehenden IP-Adressen des Aufrufers. Vor der Anbindung muss daher die entsprechende Autorisierung abgeschlossen werden.

Apple

http://timestamp.apple.com/ts01

Gehört zum Zeitstempeldienst im Apple-Codesignatur-Ökosystem.

Es sollte nicht direkt als universeller Zeitstempelserver für Windows Authenticode verwendet werden.

Test-Zeitstempeldienste

Einige öffentliche RFC-3161-Dienste eignen sich eher für Protokolltests als unmittelbar als TSA für die Produktions-Codesignatur.

Zum Beispiel:

https://freetsa.org/tsr

Solche Dienste verwenden möglicherweise ihre eigenen CA- und TSA-Zertifikate.

Daher kann nicht vorausgesetzt werden:

Windows
macOS
Java
其他代码签名验证器

Standardmäßig wird der gesamten Zertifikatskette vertraut.

In Produktionsumgebungen sollten die tatsächlich signierten Artefakte auf der Zielplattform verifiziert werden.

Überprüfung in der Produktionsumgebung

Bevor ein Zeitstempelserver in die Produktionskonfiguration aufgenommen wird, sollten mindestens folgende Punkte bestätigt werden:

1. Die offiziellen Unterlagen des Anbieters geben diesen Endpunkt eindeutig an.
2. Der Anbieter unterstützt ausdrücklich das erforderliche Zeitstempelprotokoll.
3. Es wird SHA-256 oder ein stärkerer Zeitstempel-Digest-Algorithmus verwendet.
4. Das Zielsystem kann die vollständige Zertifikatskette der TSA validieren.
5. DNS, Proxy, Firewall und ausgehendes Netzwerk können die TSA stabil erreichen.
6. Authentifizierungsmethode, Ratenbegrenzung, regionale Einschränkungen und Nutzungsbedingungen wurden bestätigt.
7. Der Signaturprüfungstest wurde mit tatsächlich signierten Artefakten abgeschlossen.

Nicht nur anhand von:

浏览器可以打开
HTTP 返回 200

Beurteilen Sie, ob der Zeitstempelserver für die Codesignatur geeignet ist.

Es muss ein tatsächliches Signaturwerkzeug verwendet werden, um eine Zeitstempelanforderung zu senden, und das endgültige Produkt muss überprüft werden.

Empfehlungen zur Auswahl des Zeitstempels

Für moderne Windows-SHA-2-Codesignaturen sollten in der Regel Zeitstempeldienste bevorzugt werden, die RFC 3161 unterstützen.

Zum Beispiel:

Microsoft
Sectigo
DigiCert
Certum
GlobalSign

Die endgültige Wahl sollte umfassend berücksichtigen:

• Zielbetriebssystem.
• Signaturwerkzeug.
• TSA-Zertifikatskette.
• Netzwerkerreichbarkeit.
• Regionale Einschränkungen.
• Limits für die Aufrufhäufigkeit.
• Servicebedingungen.
• Service-Level-Agreements.
• Ergebnisse der tatsächlichen Signaturprodukt-Validierung.

Wenn der Zertifikatsanbieter klare Anforderungen an den Zeitstempeldienst stellt, sollten die entsprechenden Zertifikatsrichtlinien und Anbieteranforderungen vorrangig befolgt werden.

Verwandte Integrationsmethoden

Verschiedene Integrationsmethoden verwenden die Signaturanzahl- und Zeitstempelregeln auf dieser Seite:

Anwendungsszenario	Dokumentation
SignTool CLI	Client-Tools
Windows KSP / CSP	Windows Provider
Jarsigner	Java-Integration
GitHub Actions, Electron Builder, Advanced Installer	CI/CD und Build-Tools
Direkter Aufruf der Remote-Signaturschnittstelle	API-Integration