MSIX 向け自己署名コードサイニング証明書：実践ガイド

2026-06-02

Tags: Windows · Microsoft Store · MSIX · ストアの落とし穴

---

前回の記事では、MSIX 提出前の完全なテストワークフローを説明しました。その中で繰り返し登場したのが、自己署名証明書の扱い——信頼されたユーザー（Trusted People）ストアへのインストールや、正しい証明書を使ったパッケージ化などです。しかし、あの記事では重要な疑問に十分に答えていませんでした。実際にどうやって証明書を作成するのか？

このガイドでは、MSIX パッケージングのための自己署名コードサイニング証明書について、作成、エクスポート、Visual Studio での使用、チーム内での管理まで、知っておくべきすべてを網羅します。

MSIX に署名が必要な理由

MSIX パッケージをインストールするには、デジタル署名が必須です。これはオプションではありません——サイドローディングやローカルテストの場合でも、オペレーティングシステムはすべての .msix ファイルに有効な署名を要求します。

Store 配布の場合、認定後に Microsoft が独自の証明書でパッケージに署名します。しかし、ローカルテストやサイドローディングには、自分自身の証明書が必要です。ここで自己署名証明書の出番です——商用のコードサイニング証明書を購入することなく、開発やテスト用のパッケージに署名できるようになります。

署名プロセスには 2 つの目的があります：

• 整合性：署名後にパッケージが改ざんされていないことを保証します
• 識別：発行者（あなた）を識別します——証明書の CN（Common Name）は Package.appxmanifest の <Publisher> 値と一致している必要があります

New-SelfSignedCertificate の使用

Windows には New-SelfSignedCertificate PowerShell コマンドレットが含まれており、テスト用の証明書を生成できます。PowerShell を管理者として開いて、次のコマンドを試してください：

New-SelfSignedCertificate -Type Custom -Subject "CN=YourCompany" -KeyUsage DigitalSignature -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.3", "2.5.29.19={text}") -CertStoreLocation "Cert:\CurrentUser\My"

各パラメーターの説明：

パラメーター	説明
-Type Custom	基本的な証明書ではなく、カスタム証明書を作成します
-Subject "CN=YourCompany"	Common Name を設定します——アプリの Package.appxmanifest における Publisher と一致させる必要があります
-KeyUsage DigitalSignature	証明書をデジタル署名用途としてマークします
-TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.3", "2.5.29.19={text}")	拡張キー使用法（Extended Key Usage）を Code Signing（1.3.6.1.5.5.7.3.3）に設定し、さらに基本制約（Basic Constraints）を End Entity（2.5.29.19）に設定します——Windows の展開エンジンがアプリパッケージに対して要求する設定です
-CertStoreLocation "Cert:\CurrentUser\My"	証明書を現在のユーザーの個人ストアに保存します

両方の TextExtension 値がなければ、証明書が完全に認識されない可能性があります——Basic Constraints OID はこれを End Entity（CA ではない）としてマークし、Windows の展開エンジンは MSIX パッケージの検証時にこれをチェックします。これがないと、特定の Windows ビルドで展開エラーや WACK 警告が発生する可能性があります。

注：実際のプロジェクトでは、Basic Constraints なしの自己署名証明書を使用しても問題なく動作しています。この制約は Microsoft の推奨ベストプラクティスですが、開発やサイドローディングでは必須ではありません。

Code Signing EKU 付き証明書の作成

既に Code Signing EKU なしで証明書を作成してしまった場合でも、正しいプロパティを持っているか確認できます。certlm.msc から証明書を開き、Details → Enhanced Key Usage を確認してください——Code Signing が表示されるはずです。

以下は、証明書を作成して MSIX で使用できる状態にする実用的なスクリプトです：

# 自己署名コードサイニング証明書を作成（Code Signing EKU + Basic Constraints）
$cert = New-SelfSignedCertificate -Type Custom -Subject "CN=YourCompany" -KeyUsage DigitalSignature -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.3", "2.5.29.19={text}") -CertStoreLocation "Cert:\CurrentUser\My"

# 証明書の詳細を表示
$cert | Format-List Subject, Thumbprint, NotAfter

# 拇印（サムプリント）を簡単に参照できるように出力
Write-Host "Certificate thumbprint: $($cert.Thumbprint)"

"CN=YourCompany" は実際のパブリッシャー名に置き換えてください。パブリッシャー名は Package.appxmanifest の Identity 要素で確認できます：

<Identity Name="YourApp" Publisher="CN=YourCompany" Version="1.0.0.0" />

PFX と CER のエクスポート

証明書を作成したら、通常は 2 種類のファイルが必要になります：

PFX（Personal Information Exchange）

秘密鍵 + 証明書を含みます。Visual Studio がパッケージの署名に使用するファイルです。パスワードと同様に扱ってください——PFX にアクセスできれば、誰でもあなたの代わりにパッケージに署名できます。

$password = ConvertTo-SecureString -String "YourPassword" -Force -AsPlainText
Export-PfxCertificate -Cert $cert -FilePath "codesign.pfx" -Password $password

CER（証明書ファイル）

公開証明書のみを含みます（秘密鍵は含まれません）。署名済みパッケージを信頼できるようにするために、テストマシンに配布するファイルです。

Export-Certificate -Cert $cert -FilePath "codesign.cer"

クイックリファレンス

形式	秘密鍵を含む？	用途
.pfx	はい	パッケージの署名（Visual Studio、signtool）
.cer	いいえ	テストマシンへのインストール（信頼の確立）

証明書のインポートと拇印（サムプリント）の確認

自己署名証明書で署名した MSIX パッケージをテストマシンにインストールするには、証明書がシステムに信頼されている必要があります。

証明書のインストール

1. .cer ファイルをダブルクリック → Install Certificate
2. Local Machine を選択 → Browse → 信頼されたユーザー（Trusted People） を選択
3. ウィザードを完了します

または、PowerShell を使用する場合：

Import-Certificate -FilePath "codesign.cer" -CertStoreLocation "Cert:\LocalMachine\TrustedPeople"

拇印（サムプリント）の確認

コマンドラインの署名ツールを使用する際には、拇印（サムプリント）が必要になります：

# 個人ストア内のすべてのコードサイニング証明書を一覧表示
Get-ChildItem -Path "Cert:\CurrentUser\My" -CodeSigningCert | Format-Table Subject, Thumbprint, NotAfter

拇印（サムプリント）は 40 文字の 16 進数文字列です。正確にコピーしてください——署名コマンドで必要になります。

Visual Studio での証明書の使用

PFX ファイルを用意したら、Visual Studio のパッケージングウィザードで使用できます：

1. プロジェクトを右クリック → Package and Publish → 新しいパッケージングプロファイルを作成
2. Select Signing Certificate ステップで、Select from File... をクリック
3. 目的の .pfx ファイルを参照し、パスワードを入力
4. パッケージングウィザードを完了

証明書はパッケージングプロファイルに保存されるため、毎回再選択する必要はありません。ただし、証明書が期限切れになったり、新しい証明書に切り替えた場合は、プロファイルを更新する必要があります。

証明書ストアからの証明書の使用

PFX を個人証明書ストアにインポートした場合、直接選択することもできます：

1. 署名ステップで、"Select from File..." をクリックする代わりに、ドロップダウンを展開
2. リストから証明書を探します（指定した CN で識別できます）
3. 選択して続行

この方法は便利ですが注意点があります——Visual Studio は特定の拇印（サムプリント）をキャッシュする可能性があり、証明書が更新された場合（新しいキーペア）、保存された参照が無効になることがあります。

証明書の有効期限、更新、再署名

New-SelfSignedCertificate で作成された自己署名証明書のデフォルトの有効期間は 1 年です（一部のバージョンではデフォルトが 3 年の場合もあります——NotAfter プロパティで確認してください）。

チェックリスト

• [ ] 証明書の有効期限を記録する
• [ ] 有効期限前に新しい証明書を作成し、すべてのパッケージに再署名する
• [ ] 新しい .cer をテストマシンに配布する
• [ ] Visual Studio のパッケージングプロファイルを更新する
• [ ] Store 提出用に、新しい証明書で新しいテストパッケージを生成する

有効期限の確認方法：

Get-ChildItem -Path "Cert:\CurrentUser\My" -CodeSigningCert | Format-Table Subject, NotAfter

更新時には、同じ CN で新しい証明書を作成し、新しい PFX/CER をエクスポートして、パッケージに再署名してください。拇印（サムプリント）は変更されるため、すべての参照が更新されていることを確認してください。

チーム開発のヒント

複数の開発者が同じ証明書でパッケージに署名する必要がある場合：

• PFX は安全な共有場所に保管する——チームストレージ内のパスワード保護アーカイブか、ファイル添付に対応したパスワードマネージャーを使用
• PFX をソース管理にコミットしない——*.pfx を .gitignore に追加
• パスワードはコードやドキュメントではなく、チームのパスワードマネージャーに記載
• 各開発者が PFX を個人証明書ストアにインポートし、Visual Studio から選択
• 開発者ごとに証明書を作成する必要がある場合（出荷しないビルド用）、すべての証明書で同じ CN を使用する

CI/CD パイプラインの場合、ほとんどのビルドエージェントは安全な環境変数やシークレットを介した PFX のインポートをサポートしています——お使いの CI プラットフォームのドキュメントで推奨される方法を確認してください。

---

この記事はストアの落とし穴シリーズの補足記事です。