Referenzmaterialien

Auf dieser Seite werden die Referenzinformationen zusammengestellt, die der Remote-Codesignaturdienst von sslTrus in verschiedenen Integrationsmethoden gemeinsam nutzt, einschließlich:

• Regeln zur Berechnung der Anzahl der Codesignaturen.
• Authenticode- und RFC-3161-Zeitstempelprotokoll.
• Häufig verwendete Codesignatur-Zeitstempelserver.
• Punkte, die bei der Auswahl eines Zeitstempeldienstes in der Produktionsumgebung zu beachten sind.

Berechnung der Anzahl der Signaturen

Die Anzahl der Signaturen wird anhand der tatsächlich abgeschlossenen Signaturaktionen berechnet.

Einfach verstanden:

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

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

Zum Beispiel:

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

Wenn ein Build folgende Ergebnisse liefert:

app.exe
helper.dll
installer.msi

Und alle drei Dateien wurden jeweils signiert, dann:

签名次数 = 3 次

Grundregeln

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

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

Häufige Signaturobjekte sind:

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

Sobald für ein Objekt tatsächlich eine Signatur erfolgreich abgeschlossen wurde, wird sie nach der entsprechenden Zählregel berechnet.

Nur erfolgreiche Signaturen werden gezählt

Es entstehen nur dann Signaturvorgänge, wenn der Remote-Codesignaturdienst die Signatur erfolgreich abgeschlossen hat.

Die folgenden Fälle werden in der Regel nicht gezählt:

• Authentifizierungsfehler.
• Parameterfehler.
• Zertifikat nicht verfügbar.
• Netzwerkanfrage fehlgeschlagen.
• Der Server hat kein Signaturergebnis erfolgreich zurückgegeben.
• Abfrage von Zertifikaten.
• Abfrage von Signaturaufzeichnungen.
• Überprüfung von Signaturen.
• Entfernen vorhandener Signaturen.
• Erzeugen von Validierungsdateien.

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

Zeitstempel werden nicht gesondert gezählt

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

Daher:

Codesignatur       → Gesamtzahl der Signaturen
Zeitstempel hinzufügen → Keine zusätzliche Signatur
Signatur überprüfen     → Keine Signatur

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 die 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-Doppelsignatur

Wenn Sie die gewöhnliche 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 berechnet:

GUI / SignTool CLI 双签 = 1 次

Hier verwechseln normale Clients den Signaturablauf am leichtesten mit den zugrunde liegenden KSP-Signaturaufrufen.

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 von app.exe	1 Mal
Zuerst SHA256, danach zusätzlich SHA1	2 Mal
Getrennte Signatur von app.exe, helper.dll und uninstall.exe	3 Mal

Daher:

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

Wenn das Tool denselben Dateiinhalt mehrmals signiert, 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 ist die tatsächlich ausgeführte Remote-Signaturoperation mit dem privaten Schlüssel maßgeblich.

Wenn das Tool mehrere Dateien oder dieselbe Datei mehrmals signiert, sind diese jeweils separat zu zählen.

Jarsigner

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

In der Regel:

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

Daher:

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

Installationspaket

Beim Installationspaket muss unterschieden werden zwischen:

1. Der ausführbaren Datei innerhalb des Installationspakets.
2. Dem Installationspaket selbst.

Zum Beispiel:

app.exe       → 1 Mal signieren
installer.msi → 1 Mal signieren

dann:

合计 = 2 次

Wenn es noch andere 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, wirkt sich nicht direkt auf die Anzahl der Signaturen aus.

Der entscheidende Punkt ist:

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

Electron

Desktop-Anwendungs-Build-Tools wie Electron Builder und Electron Forge können während eines einzigen Paketierungsvorgangs automatisch mehrere Dateien signieren.

Häufige Objekte sind:

• Hauptprogramm .exe
• DLL
• Updater
• 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 ≠ 一次签名

Die Berechnung sollte auf der tatsächlichen Anzahl der signierten Artefakte und der Anzahl der pro Artefakt durchgeführten Signaturen basieren.

Wenn Electron KSP verwendet und eine Doppelsignatur auf dieselbe Datei anwendet, kann diese Datei außerdem zwei Remote-Signaturen erzeugen.

Schnelle Beurteilung

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

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

Kann einfach so verstanden werden:

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

Besonderer Hinweis:

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

Zeitstempelserver

Beim Codesigning wird in der Regel gleichzeitig ein Zeitstempeldienst verwendet.

Ein Zeitstempel kann nachweisen, dass eine digitale Signatur zu einem bestimmten Zeitpunkt bereits existiert hat. Dadurch kann die verifizierende Stelle die Gültigkeit der Signatur anhand des Signaturzertifikats, des Zeitstempelzertifikats, des Widerrufsstatus und der Validierungsrichtlinie beurteilen.

Beim Codesigning sind zwei Zeitstempelprotokolle gebräuchlich:

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

In modernen Codesigning-Szenarien wird in der Regel RFC 3161 bevorzugt verwendet.

RFC 3161

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

Grundablauf:

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

Zeitstempeltoken enthalten in der Regel:

• Den Daten-Hash.
• Den Ausstellungszeitpunkt des Zeitstempels.
• Die TSA-Richtlinie.
• Die digitale Signatur der TSA.

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

Gängige Zeitstempelserver

Die folgenden Endpunkte eignen sich für gängige Codesignatur-Szenarien.

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

Microsoft

http://timestamp.acs.microsoft.com

Wird hauptsächlich für RFC 3161-Zeitstempel verwendet.

Geeignet als Zeitstempel-Kandidat für moderne 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

Verwendbar für Windows und andere Codesignatur-Tools, die die entsprechenden Protokolle unterstützen.

Sectigo stellt serverseitige Nutzungsanforderungen an 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 klassische Authenticode-Zeitstempelprotokoll jedoch nicht.

Wenn das Zielsignaturwerkzeug oder ältere Systeme Kompatibilitätseinschränkungen hinsichtlich des von der TSA verwendeten Schlüsselalgorithmus aufweisen, sollte dies vor der Produktivintegration praktisch verifiziert werden.

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

Die Angabe „unterstützt“ in der Tabelle beschreibt die Protokollfähigkeit, die durch öffentliche Unterlagen des jeweiligen Anbieters bestätigt ist.

Die Richtlinien für Zeitstempeldienste können sich ändern; vor der Produktionskonfiguration sollten die aktuellen offiziellen Angaben des Anbieters erneut geprüft werden.

Eingeschränkte Zeitstempeldienste

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

QuoVadis

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

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

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

Apple

http://timestamp.apple.com/ts01

Gehört zum Zeitstempeldienst des Apple-Codesignierungs-Ökosystems.

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

Test-Zeitstempeldienst

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

Zum Beispiel:

https://freetsa.org/tsr

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

Daher kann nicht angenommen werden:

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

Standardmäßig wird der gesamten Zertifikatsketten vertraut.

In der Produktionsumgebung sollte das tatsächlich signierte Artefakt auf der Zielplattform verifiziert werden.

Prüfung in der Produktionsumgebung

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

1. Die offiziellen Unterlagen des Dienstanbieters weisen diesen Endpunkt eindeutig aus.
2. Der Dienstanbieter unterstützt ausdrücklich das benötigte Zeitstempelprotokoll.
3. Verwendung von SHA-256 oder eines stärkeren Zeitstempel-Digestalgorithmus.
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, Ratenlimit, regionale Einschränkungen und Servicebedingungen wurden bestätigt.
7. Der Signaturprüfungstest wurde mit dem tatsächlich signierten Artefakt abgeschlossen.

Nicht ausschließlich über:

浏览器可以打开
HTTP 返回 200

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

Sie müssen mit dem tatsächlich verwendeten Signaturwerkzeug eine Zeitstempelanfrage senden und das endgültige Ergebnis validieren.

Empfehlungen zur Auswahl des Zeitstempels

Für moderne Windows-SHA-2-Codesignaturen wird in der Regel ein Zeitstempeldienst bevorzugt, der RFC 3161 unterstützt.

Zum Beispiel:

Microsoft
Sectigo
DigiCert
Certum
GlobalSign

Die endgültige Auswahl sollte umfassend berücksichtigen:

• Zielbetriebssystem.
• Signaturwerkzeug.
• TSA-Zertifikatskette.
• Netzwerkerreichbarkeit.
• Regionale Einschränkungen.
• Aufrufhäufigkeitsbeschränkungen.
• Nutzungsbedingungen.
• Service-Level-Agreement.
• Tatsächliche Verifizierungsergebnisse der Signaturprodukte.

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