参考資料

このページでは、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 連携