コード署名証明書

ソフトウェアの発行元を証明し、改ざんを検出するための証明書。

概念URI

https://comcomponent.com/knowledge/code-signing-cert/

別名・表記

Authenticode証明書

下位概念

EVコード署名証明書 / OVコード署名証明書

最終確認日

2026-08-01

機械可読データ

JSON-LD

この概念が関わる関係

• Smart App Controlはコード署名証明書を前提とします。Smart App Controlのブロックを避けるために、マイクロソフトは有効な証明書でアプリに署名することを開発者向けの案内として挙げている / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• 発行者ルールはコード署名証明書を前提とします。発行者ルールは署名メタデータ(発行者・製品名・ファイル名・バージョン)を根拠にするため、対象バイナリへのコード署名が前提になる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• コード署名証明書はHSM/トークンでの秘密鍵保管を前提とします。公的に信頼されるCAが発行するコード署名証明書(OV・EV)については、2023年6月1日以降、CA/Browser Forumの基準により秘密鍵をFIPS 140-2レベル2相当以上のハードウェアで生成・保管することが必須になった。自己署名証明書や社内プライベートCAが発行する証明書はこの基準の対象外で、秘密鍵をソフトウェアで保管することもできる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• コード署名証明書はコード署名のタイムスタンプを利用します。証明書の有効期限が切れても署名の有効性を保ちたい場合、signtoolでの署名時にRFC 3161タイムスタンプサーバーを指定し、署名にタイムスタンプを付ける / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• アプリケーションマニフェスト(*.exe.manifest)はコード署名証明書で構成できます。アプリケーションマニフェストは、使用するコード署名証明書を指定して署名するかどうかを構成できる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• 配置マニフェスト(.application)はコード署名証明書で構成できます。配置マニフェストも同様にコード署名証明書で署名するかどうかを構成でき、マニフェストを手で変更した場合は再署名が必要になる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• 自動アップデート機能(updater)はコード署名証明書を前提とします。自前updaterで成果物を検証する場合、成果物にはコード署名証明書(Authenticode)による署名検証が必要になる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• コード署名証明書はGet-AuthenticodeSignatureで確認できます。コード署名の有効性は、運用手順やCIからPowerShellのGet-AuthenticodeSignatureで確認できる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• コード署名のタイムスタンプはコード署名証明書に対する本記事の推奨です。タイムスタンプが無くても署名も検証もできるが、証明書の有効期限が切れると署名が検証されなくなる。リリース時には必ずタイムスタンプ付き署名を使うことが推奨される / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 信頼された発行元ストアはコード署名証明書を前提とします。信頼された発行元として認識されるには、コード署名証明書で署名されている必要がある / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• コード署名証明書はActiveXに対する本記事の推奨です。自社配布のActiveX/マクロ/アドインにはコード署名を行い、Trusted Publisherを一元管理することが企業向けの推奨設定とされる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 実行ポリシーAllSignedはコード署名証明書を前提とします。AllSignedはローカル作成分を含むすべてのスクリプトに信頼された発行元の署名を要求するため、コード署名証明書が前提になる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• RemoteSignedポリシーはコード署名証明書を前提とします。RemoteSigned環境でインターネット由来のスクリプトを配布用に署名するなら、コード署名証明書が必要になる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• Set-AuthenticodeSignatureはコード署名証明書を利用します。Set-AuthenticodeSignatureはCert:ドライブなどから取得したコード署名証明書で署名を付与する / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• コード署名証明書はCert:ドライブに保存されます。Windowsの証明書ストアで管理する場合、コード署名証明書はCert:ドライブ経由でCert:\CurrentUser\Myなどのストアから取得できる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• Authenticode署名(スクリプトファイル)はコード署名証明書を利用します。Authenticode署名はコード署名証明書を使って各スクリプトファイルの発行元と完全性を保証する。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 信頼された発行元ストアはコード署名証明書を前提とします。信頼された発行元によるマクロ実行の許可は、マクロへのコード署名証明書の付与を前提とする / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• コード署名証明書はWindows SmartScreenを軽減します。Web配布や社外配布ではSmartScreen警告が出ることがあり、コード署名の扱いを合わせて整理する必要がある / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• Windowsアプリの外注・受託開発はコード署名証明書を利用します。配布・更新・権限の整理では、Web配布や社外配布で問題になるコード署名証明書の扱いも受託開発が検討する事項である / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• MSIXはコード署名証明書を前提とします。MSIXの配布ではsigntool.exeなどによる署名が前提となる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 独自updaterはコード署名証明書を前提とします。独自updaterで更新の安全性を担保する設計にするなら、署名検証とそのためのコード署名証明書の運用を自分たちで設計・運用する責任を負うことになる。技術的には署名検証なしでも動作はするが、その場合は改ざんされた更新を検知できない / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• コード署名証明書は未署名バイナリを防ぎます。EXE/DLL/MSI/MSIXにコード署名することで、配布物が未署名のまま出荷される状態を防げる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• コード署名証明書は更新物の署名・ハッシュ検証に対する本記事の推奨です。更新まわりの検証を署名で行う場合は、更新モジュール自身にもコード署名証明書を用意することが本記事の推奨である(ハッシュ検証のみで済ませる設計も本記事では許容している) / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• コード署名証明書はコード署名のタイムスタンプを前提とします。署名だけでなくタイムスタンプも付けることを、release手順に含めるべき最低限としている / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• コード署名証明書は信頼された発行元ストアに保存されます。署名済みソフトウェアの発行元を信頼済みとして登録する場所。GPOでの配布運用がある / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• コード署名証明書は誤検知(false positive)を軽減します。信頼されたルート認証局の証明書で一貫して署名し続けると、調査チームが出所を素早く特定でき誤検知や既知リスト入りの遅れを軽減できる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• コード署名証明書はWindows SmartScreenを軽減します。コード署名は発行元不明という要因を減らすが、ファイルや発行元の評判が蓄積されるまではSmartScreen警告が出ることがある / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• MSIXはコード署名証明書を前提とします。Windowsはインストール前にMSIXパッケージが有効なコード署名証明書で署名されていることを必須とする / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• ClickOnceはコード署名証明書を前提とします。発行元の真正性を検証させたい本番配布では、ClickOnceはAuthenticode証明書でアプリケーションマニフェストと配置マニフェストを署名する。署名なしで発行することもでき、その場合は発行元不明の扱いになる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• コード署名証明書はSignToolで確認できます。コード署名済みファイルはsigntool verifyコマンドで署名の妥当性を確認できる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• ビルド+テストの自動化はコード署名証明書より先に行うべきです。署名・配布の自動化より先に、まずビルド+テストの自動化だけを入れるのが実務の順序であり、最初から全部を組もうとすると署名周りで止まりがちになる。 / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• デスクトップアプリのCI/CDパイプラインはコード署名証明書を前提とします。Store外で配布するWindowsアプリにコード署名が実質必須であるため、配布物の完成を出口とするCI/CDパイプラインは公的なコード署名証明書を前提とする。ビルド+テストだけの最小段階では不要。 / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• コード署名証明書はHSM/トークンでの秘密鍵保管を前提とします。2023年6月以降にCA/Browser Forumの要件に基づき新規発行される公的なOV/EV証明書は、秘密鍵をHSMまたはハードウェアトークンで保管することが必須になった。社内CA発行や既存のPFX証明書はこの要件の対象外。 / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• コード署名証明書はGitHub Actionsのシークレットで構成できます。GitHub ActionsでCI/CDパイプラインを組む場合、PFX形式の秘密鍵はBase64化してGitHub Actionsのシークレットに格納し、ジョブ内でファイルとして復元して使う。 / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• SignToolはコード署名証明書を利用します。signtoolはPFXファイルなどの秘密鍵と証明書を使って、実行ファイルやDLLにコード署名を行う。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• MSIXはコード署名証明書を前提とします。Windowsは署名されていないMSIXパッケージのインストールを許可しないため、MSIX配布ではパッケージ署名が必須になる。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典

この概念を扱う記事

• AppLocker・App Control for Business(WDAC)と業務アプリ配布 ── 「実行制御」でブロックされる前に(言及)
• ClickOnce とは何か - 仕組み、更新、向いている場面・向いていない場面を実務目線で整理(言及)
• 自動アップデートのセキュリティ設計 - HTTPSだけでは足りない理由(言及)
• Office 2024/Microsoft 365でActiveXが動かない原因と確認手順(言及)
• PowerShellの実行ポリシーとスクリプト署名 ── 「Bypassで蓋をする」運用から卒業する実務ガイド(主要トピック)
• PowerShellモジュールの社内配布と更新 ── PSResourceGetと社内リポジトリ(言及)
• VBA とは何か - 制約、将来性、置き換えるべき場面と現実的な移行パターン(言及)
• Windowsアプリ 外注・受託開発を依頼する前に整理したいこと(言及)
• Windowsアプリ配布方式の選び方 - MSI/MSIX/ClickOnce/xcopy/独自更新(言及)
• Windowsアプリ開発のセキュリティ最低限チェックリスト(主要トピック)
• Windows証明書ストア実務ガイド ── ユーザーとコンピューター、どちらに入れるか(言及)
• 自社開発のWindowsアプリがウイルス扱いされたら ── Microsoft Defenderの誤検知対応と、性能影響との付き合い方(言及)
• Windowsで「Windows によって PC が保護されました」が出る理由(主要トピック)
• WindowsアプリでUSB機器を扱う方法 ── 仮想COM・HID・WinUSB・専用SDKの選び方(言及)
• WinForms / WPFアプリのCI/CD実践 ── GitHub Actionsでビルドから署名・配布まで自動化する(言及)

一次資料

• https://learn.microsoft.com/dotnet/api/system.security.cryptography.x509certificates.x509store

このページはサイトの知識グラフ(_data/knowledge/)から自動生成されています。誤りの指摘はお問い合わせからお願いします。