参考資料

このページでは、sslTrus リモートコード署名サービスをさまざまな統合方法で利用する際に共通する参考情報をまとめています。内容は以下のとおりです。

• コード署名回数の計算ルール。
• Authenticode および RFC 3161 タイムスタンププロトコル。
• よく使われるコード署名用タイムスタンプサーバー。
• 本番環境でタイムスタンプサービスを選択する際に注意すべき点。

署名回数の計算

署名回数は、実際に完了した署名アクションに基づいて計算されます。

簡単に言うと：

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

署名回数は、ソースコードファイルの数で計算されるわけではなく、1回のビルド、1回のパッケージング、または1回のCI/CDパイプラインで計算されるわけでもありません。

例：

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

一度のビルドで生成される場合：

app.exe
helper.dll
installer.msi

そして3つのファイルすべてがそれぞれ署名を完了した場合、次のようになります。

签名次数 = 3 次

基本ルール

署名回数は主に以下に依存します。

1. 最終的にどのファイルまたはオブジェクトが署名されたか。
2. 各オブジェクトで実際に何回署名が完了したか。
3. 通常のクライアント署名か、KSP、Jarsignerなどの低レベル署名呼び出し方式か。
4. ビルドツールが追加のEXE、DLL、アンインストーラー、またはインストールパッケージに自動署名したかどうか。

一般的な署名対象は以下のとおりです。

• .exe
• .dll
• .msi
• .msp
• .sys
• .cat
• .jar
• アンインストーラー。例：uninstall.exe

あるオブジェクトで実際に署名が1回成功するたびに、対応するカウントルールに従って計算されます。

成功時のみカウント

リモートコード署名サービスで署名が正常に完了した場合のみ、署名回数が発生します。

以下の場合は通常カウントされません。

• 認証失敗。
• パラメータエラー。
• 証明書が利用不可。
• ネットワークリクエストの失敗。
• サーバー側で署名結果が正常に返されなかった場合。
• 証明書の照会。
• 署名記録の照会。
• 署名の検証。
• 既存の署名の削除。
• 検証ファイルの生成。

リモートサービスが署名結果を正常に返した後、クライアント側でローカルへのファイル書き込み、タイムスタンプの追加、または後続処理が失敗した場合でも、すでに完了したリモート署名は成功署名としてカウントされます。

タイムスタンプは個別にカウントされない

タイムスタンプは署名が特定の時点で存在していたことを証明するものであり、新しいコード署名操作には該当しません。

したがって：

コード署名       → 署名回数が発生します
タイムスタンプ追加 → 追加の署名回数は発生しません
署名検証         → 署名回数は発生しません

タイムスタンプサービスの成否は、最終的な署名ファイルのタイムスタンプ結果にのみ影響し、コード署名が追加でもう一度実行されたことを意味するものではありません。

SignTool CLI

sslTrus SignTool CLI を使用します。

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

署名に成功した場合：

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

例：

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

3つのファイルがすべて成功しました：

合计 = 3 次

SignTool CLI デュアル署名

通常の SignTool CLI を使用して SHA-1 と SHA-2 を同時に有効にする場合：

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

通常の CLI 二重署名は、1 つのクライアント署名タスクとして計算されます。

GUI / SignTool CLI 双签 = 1 次

ここは、一般的なクライアント署名フローと KSP の下層署名呼び出しが最も混同されやすいところです。

Windows KSP

KSP は Windows CNG Provider の統合方式です。

Microsoft SignTool、MSBuild、Visual Studio、Electron パッケージツール、またはその他の Windows ソフトウェアが KSP を通じてリモートコード署名を呼び出す場合、回数のカウントは以下により近くなります。

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

例如：

操作	署名回数
app.exe に対して SHA256 署名を 1 回実行	1 回
最初に SHA256 を実行し、その後 SHA1 を追加	2 回
app.exe、helper.dll、uninstall.exe をそれぞれ署名	3 回

したがって：

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

如果工具对同一个文件执行多次底层签名操作，每次成功的远程签名都会分别计算。

CSP

CSP 是传统 Windows CryptoAPI Provider。

CSP 同样由 Microsoft SignTool 或其他 Windows 应用通过 Provider 调用远程签名服务。

判断签名次数时，应以实际发生的远程私钥签名操作为准。

如果工具分别对多个文件或对同一个文件执行多次签名，应分别计算。

Jarsigner

使用 sslTrusJarsigner Provider 时，标准 jarsigner 会在签名过程中调用远程代码签名服务。

通常：

操作	签名次数
对 app.jar 签名	1 次
对 3 个 JAR 分别签名	3 次
对同一个 JAR 再执行一次签名	再增加 1 次
jarsigner -verify	0 次
生成验证用 keystore	0 次

因此：

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

インストールパッケージ

インストールパッケージでは以下を区別する必要があります。

1. インストールパッケージ内の実行可能ファイル。
2. インストールパッケージ自体。

例えば：

app.exe       → 署名 1 回
installer.msi → 署名 1 回

則：

合计 = 2 次

如果还有其他文件：

文件	是否签名	签名次数
app.exe	是	1
helper.dll	是	1
driver.sys	是	1
installer.msi	是	1
合计		4

安装包中包含多少源代码、资源文件、图片或配置文件不会直接影响签名次数。

关键是：

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

Electron

Electron Builder、Electron Forgeなどのデスクトップアプリケーションビルドツールは、1回のパッケージングプロセスで複数のファイルに自動署名する場合があります。

一般的な対象は次のとおりです。

• メインプログラム .exe
• DLL
• アップデータ
• アンインストーラ
• インストールパッケージ .exe
• MSI
• その他の補助実行可能ファイル

例：

成果物	署名回数
MyApp.exe	1
ffmpeg.dll	1
update.exe	1
uninstall.exe	1
MyApp Setup.exe	1
合計	5

したがって、

一次 Electron Build ≠ 一次签名

実際に署名された成果物の数と、各成果物に対して実行された署名回数に基づいて計算する必要があります。

Electron が KSP を使用し、同じファイルに対して二重署名を実行する場合、そのファイルではさらに 2 回のリモート署名が発生する可能性があります。

迅速な判断

1 回のビルドで発生する署名回数がわからない場合は、順番に確認できます。

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

簡単に理解すると：

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

特別注意：

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

タイムスタンプサーバー

コード署名では通常、タイムスタンプサービスを併用します。

タイムスタンプは、デジタル署名が特定の時点で既に存在していたことを証明できるため、検証側は署名証明書、タイムスタンプ証明書、失効状態、検証ポリシーを組み合わせて署名の有効性を判断できます。

コード署名でよく使われるタイムスタンププロトコルは次の2つです。

プロトコル	説明
Authenticode	Microsoft の従来のタイムスタンププロトコルで、主に旧式の Windows コード署名フローとの互換性のために使用されます
RFC 3161	汎用タイムスタンププロトコルで、現代のコード署名シナリオに適しています

現代のコード署名シナリオでは通常、RFC 3161 を優先して使用します。

RFC 3161

RFC 3161 のタイムスタンプリクエストでは、元のファイルではなく、タイムスタンプ対象データのダイジェストを送信します。

基本フロー：

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

タイムスタンプトークンには通常、以下が含まれます。

• データダイジェスト。
• タイムスタンプの発行時刻。
• TSA ポリシー。
• TSA デジタル署名。

タイムスタンプサーバーは、タイムスタンプを追加することによって sslTrus コード署名回数を追加で消費することはありません。

一般的なタイムスタンプサーバー

以下のエンドポイントは、一般的なコード署名シナリオに適用されます。

本番環境で使用する前に、該当プロバイダーの最新の公式ドキュメント、サービスポリシー、および可用性を再確認する必要があります。

Microsoft

http://timestamp.acs.microsoft.com

主に RFC 3161 タイムスタンプに使用されます。

Windows の最新コード署名シナリオにおけるタイムスタンプ候補として適しています。

例：

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

Microsoft SignTool：

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

Sectigo

http://timestamp.sectigo.com

支持：

• Authenticode
• RFC 3161

可用于 Windows 和其他支持相应协议的代码签名工具。

Sectigo 对批量调用存在服务侧使用要求，生产系统应根据其当前官方策略控制调用频率。

DigiCert

http://timestamp.digicert.com

RFC 3161 をサポートし、Microsoft Authenticode などのコード署名シナリオに利用できます。

Certum

http://time.certum.pl

サポート：

• Authenticode
• RFC 3161

Certum 公式コードサイニング資料は、Windows および Java JAR 署名シナリオをカバーしています。

GlobalSign

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

現在、GlobalSign コード署名資料ではこの RFC 3161 タイムスタンプアドレスを使用しています。

現在の公式コード署名ドキュメントに記載されていない過去の GlobalSign アドレスの継続使用は推奨されません。

SSL.com

http://ts.ssl.com

RFC 3161 に対応しており、従来の Authenticode タイムスタンププロトコルには対応していません。

対象の署名ツールや旧システムに TSA が使用する鍵アルゴリズムとの互換性制限がある場合は、本番導入前に実際の検証を行ってください。

タイムスタンプサーバーの比較

プロバイダー	アドレス	Authenticode	RFC 3161
Microsoft	http://timestamp.acs.microsoft.com	未確認	対応
Sectigo	http://timestamp.sectigo.com	対応	対応
DigiCert	http://timestamp.digicert.com	未確認	対応
Certum	http://time.certum.pl	対応	対応
GlobalSign	http://timestamp.globalsign.com/tsa/r45standard	未確認	対応
SSL.com	http://ts.ssl.com	非対応	対応

表の「対応」は、該当プロバイダーの公開資料で確認されたプロトコル能力を示します。

タイムスタンプサービスのポリシーは変更される可能性があるため、本番設定前にプロバイダーの最新の公式資料を再確認してください。

制限付きタイムスタンプサービス

一部のタイムスタンプサーバーは RFC 3161 サービスを提供していますが、匿名の公開 TSA として直接使用することはできません。

QuoVadis

公開されている RFC 3161 アドレスには以下が含まれます。

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

当サービスは、呼び出し元のエグレスIPを事前に登録する必要があるため、接続前に該当する認可を完了する必要があります。

Apple

http://timestamp.apple.com/ts01

Apple コード署名エコシステムで使用されるタイムスタンプサービスに属します。

これを Windows Authenticode の汎用タイムスタンプサーバーとして直接使用すべきではありません。

テスト用タイムスタンプサービス

一部の公開 RFC 3161 サービスは、プロダクションのコード署名 TSA として直接使用するよりも、プロトコルテストに適しています。

例：

https://freetsa.org/tsr

この種のサービスは、独自のCAおよびTSA証明書を使用する可能性があります。

そのため、以下のように想定することはできません。

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

デフォルトでは、その証明書チェーンが信頼されます。

本番環境では、ターゲットプラットフォームで実際に署名成果物を検証する必要があります。

本番環境でのチェック

タイムスタンプサーバーを本番構成に追加する前に、少なくとも以下を確認してください。

1. サービスプロバイダーの公式資料に、そのエンドポイントが明確に公開されていること。
2. サービスプロバイダーが、必要なタイムスタンププロトコルを明確にサポートしていること。
3. SHA-256 またはより強力なタイムスタンプダイジェストアルゴリズムを使用すること。
4. ターゲットシステムが TSA の完全な証明書チェーンを検証できること。
5. DNS、プロキシ、ファイアウォール、およびエグレスネットワークから TSA に安定してアクセスできること。
6. 認証方式、レート制限、リージョン制限、および利用規約を確認済みであること。
7. 実際の署名成果物を使用して検証テストを完了していること。

以下の方法だけで判断しないでください。

浏览器可以打开
HTTP 返回 200

タイムスタンプサーバーがコード署名に適しているかどうかを判断します。

実際の署名ツールを使用してタイムスタンプリクエストを送信し、最終成果物に対して検証を実行する必要があります。

タイムスタンプ選択の推奨事項

現代のWindows SHA-2コード署名では、通常、RFC 3161をサポートするタイムスタンプサービスを優先的に選択します。

例：

Microsoft
Sectigo
DigiCert
Certum
GlobalSign

最終的な選択では、以下を総合的に考慮する必要があります。

• 対象オペレーティングシステム。
• 署名ツール。
• TSA 証明書チェーン。
• ネットワーク到達性。
• リージョン制限。
• 呼び出し頻度制限。
• 利用規約。
• サービスレベル契約。
• 実際の署名生成物の検証結果。

証明書プロバイダーがタイムスタンプサービスについて明確な要件を定めている場合は、対応する証明書ポリシーとサービスプロバイダーの要件を優先して従う必要があります。

関連する連携方法

連携方法によって、本ページの署名回数とタイムスタンプのルールが使用されます。

利用シーン	ドキュメント
SignTool CLI	クライアントツール
Windows KSP / CSP	Windows Provider
Jarsigner	Java 連携
GitHub Actions、Electron Builder、Advanced Installer	CI/CD とビルドツール
リモート署名 API を直接呼び出す	API 連携