.NET MAUIで作ったWindowsアプリをVisual Studio 2022からPublishしてMSIXを別PCに配布したのに、「証明書が見つからない」「このアプリパッケージは信頼されていません」などの証明書エラーでインストールできない…。原因はほぼ“自己署名証明書をどのストアに入れたか”です。この記事では最短の解決手順と、台数が増えたときの現実的な運用までまとめます。
症状：別PCでMSIXを実行すると証明書関連のエラーで止まる
Visual Studio 2022の発行（Publish）ウィザードで、.NET MAUI（Windows）アプリをMSIX（またはMSIXBundle）として生成し、テスト用の別PCにコピーしてインストールしようとしたところ、次のようなメッセージで失敗するケースがあります。
- 「証明書が見つからない」
- 「このアプリ パッケージは信頼されていません」
- 「発行元（Publisher）を検証できません」
- エラーコード例：0x800B0109 / 0x800B010A（証明書チェーンが信頼されていない系）
多くの場合、MSIX自体が壊れているわけではなく、署名に使われた証明書をWindows側が「信頼済み」と判断できていないことが原因です。
原因：MSIXは署名必須。自己署名証明書は“自動では信頼されない”
MSIXは、配布・インストールの仕組みとしてコード署名（パッケージ署名）を前提にしています。署名が正しくても、その署名証明書が信頼されていなければ、Windowsは「未知の発行元」としてインストールをブロックします。
Visual StudioのPublishウィザードで作る「自己署名証明書」は便利ですが、一般的なCA（認証局）から発行された証明書ではありません。そのため、別PCへ持って行った時点では、Windowsにとっては“初めて見る発行元”です。
| 項目 | 自己署名証明書（VSで生成） | CA発行のコード署名証明書 |
|---|---|---|
| 信頼の状態 | 配布先PCでは未信頼（手動で信頼させる必要あり） | 多くの環境で既に信頼されている（または組織で信頼させやすい） |
| テスト用途 | 向いている | コストや手配が重くなりがち |
| 台数が多い社内配布 | 証明書配布の仕組みがないと運用が破綻しやすい | 運用が安定しやすい |
| 社外配布 | 基本的に不向き（利用者に手作業を強いる） | 推奨（またはMicrosoft Storeなど別手段） |
まず押さえる：.cer と .pfx の違い（「配布先に必要なのはどれ？」）
Publish出力フォルダーには、MSIXと一緒に証明書ファイルが生成されることがあります。ここで混乱しやすいのが、拡張子の違いです。
| 拡張子 | 中身 | 主な用途 | 注意点 |
|---|---|---|---|
| .cer | 公開鍵（証明書） | 配布先PCで「信頼する」ためにインストールする | これだけでは署名はできないが、インストールの“信頼”には十分 |
| .pfx（または.p12） | 公開鍵＋秘密鍵 | 署名（サイン）に使う。開発側で保管する | 漏えいすると第三者が“正規アプリのふり”をできるので厳重管理 |
別PCでMSIXをインストールするだけなら、基本的に必要なのは.cer（公開鍵側）です。逆に、.pfxは配布先に渡す必要はありません（渡すべきでもありません）。
「ストアの場所」が重要な理由：Current User と Local Machine
証明書はWindows内の「証明書ストア」に保存されます。似たような画面でも、どこに入ったかで結果が変わります。
| ストアの場所 | 効き方 | 典型的なハマりどころ |
|---|---|---|
| 現在のユーザー（Current User） | そのユーザーでの信頼にだけ影響する | 別ユーザーで試すとインストールできない／管理ツールから見え方が違う |
| ローカル コンピューター（Local Machine） | そのPC全体の信頼に影響する | 管理者権限が必要。ここに入っていないと「入れたつもり」になりがち |
テスト端末が複数ユーザーで使われたり、評価担当が管理者ではないユーザーでログインする運用だと、Current User側だけに入れても再現します。今回のような「別PCで確実に動かす」用途では、ローカル コンピューター（Local Machine）側に信頼を置く方がトラブルが少なくなります。
結論：自己署名証明書は“各PCで”正しいストアに「信頼できる証明書」として入れる
自己署名証明書で署名されたMSIXを別PCに配布する場合、そのPCの証明書ストアに、該当証明書を信頼させた状態で入れる必要があります。今回の解決手順は次のとおりです。
解決手順（GUIで最短で直す）
- MSIX（インストーラー）と同じフォルダーにある証明書ファイル（.cer など）を開き、「証明書のインストール」を選択します。
- インストール先は「ローカル コンピューター（Local machine）」を選びます。環境によっては管理者権限が必要です（UACが出たら許可）。
- 「証明書をすべて次のストアに配置する」を選び、参照（Browse）から「信頼されたルート証明機関（Trusted Root Certification Authorities）」を選択してインストールします。
- インストール完了後、改めてMSIXを実行してインストールします。
ポイントは、Current User（現在のユーザー）ではなくLocal Machine（ローカル コンピューター）を選ぶこと、そして信頼されたルート証明機関に入れることです。自己署名証明書は“自分がルート”のような形になりやすいため、信頼の起点として扱われるストアに入れるとエラーが解消しやすくなります。
| よくある選択 | 起きやすい結果 | 対処 |
|---|---|---|
| 現在のユーザー（Current User）に入れた | ユーザーを変えるとインストールできない／検証で失敗することがある | ローカル コンピューター（Local Machine）側へ入れ直す |
| 「個人（Personal）」や別ストアに入れた | “信頼”として扱われず、証明書エラーが解消しない | 信頼されたルート証明機関（または組織方針で信頼されるストア）に入れる |
| MSIXと別の証明書を入れた | 署名と一致せずインストール不可 | Publish出力フォルダー内の.cerを使う／署名に使った証明書を特定する |
GUIで確実に「入ったか」を確認する方法（certlm.msc）
「確かにインストールしたのにまだエラーになる」場合、実は別の場所に入っていることがよくあります。Windows標準の管理ツールで確認すると、迷子になりません。
- Windowsキー + R で「ファイル名を指定して実行」を開き、certlm.msc を入力して実行します（ローカル コンピューターの証明書）。
- 左ツリーで 信頼されたルート証明機関 > 証明書 を開きます。
- 一覧に、今回インストールした証明書があるか確認します。見分けがつかない場合は、証明書をダブルクリックして サブジェクト（Subject）や 拇印（Thumbprint）を見ます。
同じ証明書管理でも、certmgr.msc（現在のユーザー）を開いてしまうと、見ているストアが違うので注意してください。今回確認したいのは「ローカル コンピューター側」です。
PowerShellでインポートする（手順書に貼りやすく、事故が減る）
複数台に配布する、あるいは手順を文章で渡したい場合は、GUIよりPowerShellの方が再現性が高いです。配布先PCで管理者としてPowerShellを開き、.cerを指定して実行します。
PowerShell（管理者）で実行:
Import-Certificate -FilePath "C:\Temp\YourApp.cer" -CertStoreLocation Cert:\LocalMachine\Root
「Root」は信頼されたルート証明機関に相当します。インポート後に再度MSIXを実行すれば、証明書が原因のエラーは解消できるケースが多いです。
また、テスト完了後に証明書を削除したい場合（セキュリティ的に元に戻したい場合）は、拇印で特定して削除できます。
拇印（Thumbprint）で検索:
Get-ChildItem Cert:\LocalMachine\Root | Where-Object { $_.Thumbprint -eq "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" }
削除（十分注意して実行）:
Remove-Item "Cert:\LocalMachine\Root\XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
「信頼されたルート」に入れることの注意点（テスト用途に限定する）
信頼されたルート証明機関は、PCが信用する“根っこ”です。ここに入れた証明書で署名されたものは、Windowsから見て強く信頼されやすい状態になります。
- 配布元が自分（または自社）であることが明確な証明書だけを入れる
- テストが終わったら削除する運用も検討する
- 第三者から受け取った.cerを安易に入れない
「とりあえず直す」だけでなく、安全な運用の線引きもセットで考えておくと安心です。
証明書を入れたのに直らないときのチェックリスト
上の手順で直るケースが多い一方、環境や過去の発行履歴によっては別の罠もあります。次の項目を上から順に潰すと、原因が切り分けやすくなります。
MSIXの署名と証明書が一致しているか確認する
まずは「入れた証明書が本当にそのMSIXを署名しているか」を確認します。WindowsのエクスプローラーからMSIXを右クリックし、プロパティに署名タブが出る場合はそこでも確認できます（出ない場合もあります）。確実にやるならSignToolを使います。
signtool verify /pa /v "YourApp_1.0.0.0_x64.msix"
検証結果に「チェーンが信頼されていない」「ルートが不明」などが出るなら、証明書ストア側の信頼設定が足りない可能性が高いです。一方で「署名が無効」「ハッシュが一致しない」などが出る場合は、ファイル破損や署名工程の問題を疑います。
Publisher（発行元）が変わっていないか
MSIXはパッケージのIDにPublisher（発行元）情報が強く結びつきます。Visual Studioで毎回「新しい自己署名証明書」を作り直すと、証明書のサブジェクトが変わり、結果としてPublisherが変わった扱いになります。
- 以前インストールした同アプリが残っていて、更新扱いで入れようとして失敗する
- 別PCで「想定している発行元と違う」と判断される
心当たりがある場合は、一度アンインストールしてからインストールし直す、またはPublisherが変わらないように同じ証明書（同じPFX）で署名し続ける運用に寄せると安定します。
古いパッケージが残っていないか（同名アプリの罠）
テストを繰り返していると、別の証明書で署名した旧版が端末に残っていることがあります。MSIXの更新は署名証明書（Publisher）に依存するため、旧版が残っていると「更新できない」形で失敗することがあります。
- 設定 > アプリ から対象アプリをアンインストールする
- 同名・同Publisherのパッケージが複数ないか確認する
PCの日時がずれていないか
証明書には有効期間があります。テスト端末の時計が大きくずれていると、証明書が「まだ有効ではない」または「期限切れ」に見えてエラーになることがあります。特に仮想マシンやクリーンインストール直後の端末では、まず日時同期を確認してください。
インストール方法を変えてみる（PowerShell）
ダブルクリック（App Installer）で分かりにくいエラーになる場合、PowerShellでインストールすると、より具体的なメッセージが出ることがあります。
PowerShell（管理者）で実行:
Add-AppxPackage -Path "C:\Temp\YourApp_1.0.0.0_x64.msix"
ここで表示されるエラーコードや理由が、次の一手（証明書ストア／依存ランタイム／権限）を決めるヒントになります。
Windowsの設定（開発者向け設定）も確認する
組織端末のポリシーやWindowsの設定によっては、ストア外アプリ（サイドロード）のインストールが制限されていることがあります。証明書の問題が解消しても、別の制限で止まる場合があるため、次も確認しておくと安心です。
- Windows 11: 設定 > プライバシーとセキュリティ > 開発者向け（Developer modeの状態）
- 会社PC: 管理者ポリシーでアプリのインストールが制限されていないか
代表的なエラーパターンと対処を整理
「証明書エラー」と一言で言っても、実際には複数の原因が混ざります。現場で遭遇しがちなパターンを、対処とセットで整理しておきます。
| 見え方（メッセージ／コード例） | 原因の方向性 | 現実的な対処 |
|---|---|---|
| 証明書が見つからない／信頼されていない 0x800B0109 など | 署名証明書チェーンが未信頼 | 配布先PCで.cerをローカル コンピューター > 信頼されたルート証明機関へ |
| 発行元を検証できない | 信頼ストアの位置が違う、または別の証明書を入れた | ストアを見直す／MSIXと同じフォルダーの.cerを使う |
| アプリの更新で失敗する | Publisherが変わった／別証明書で署名した | 旧版をアンインストール／同一証明書（同一PFX）で署名を継続 |
| 有効期限/時刻に関するエラー | 端末の日時ずれ／証明書期限切れ | 日時同期／証明書を作り直して再署名（運用は固定化推奨） |
運用上の現実解：台数が増えるなら「証明書配布の仕組み」か「CA発行」に寄せる
自己署名証明書は、少人数・少台数のテストには最適です。しかし、利用端末が増えるほど「各PCで信頼させる作業」がボトルネックになります。社内展開の現実解は大きく2つです。
Active Directory環境なら、GPOで証明書を配布して信頼させる
ドメイン参加PCが多いなら、手作業で.cerを入れるのではなく、グループポリシーでコンピューターの証明書ストアへ配布するのが最も安定します。概念としては次の形です。
- コンピューター構成 > ポリシー > Windows の設定 > セキュリティの設定
- 公開キーのポリシー > 信頼されたルート証明機関
- ここに自己署名証明書（.cer）を配布して「全PCで信頼」にする
端末が入れ替わっても自動で適用されるため、MSIX配布の手間が一気に下がります。配布担当と開発担当が分かれている組織でも、手順を標準化しやすいのが強みです。
Intune（Microsoft Endpoint Manager）で配布する
Entra ID（旧Azure AD）参加、もしくはMDMで管理している場合は、Intune側の証明書配布／信頼設定で一括展開が可能です。現場では「アプリ配布」と「証明書配布」をセットにして運用すると、手戻りが減ります。
特に在宅勤務や外部ネットワークで検証する端末が多い場合、GPOよりIntuneの方が運用にフィットすることがあります。
正式なコード署名証明書（CA発行）を使う
社外配布や、端末が社内外に広がる場合は、自己署名のまま運用すると確実に詰みます。一般の認証局から発行されたコード署名証明書でMSIXに署名すれば、配布先に個別の信頼設定を求めずにインストールできる範囲が広がります（もちろん、組織ポリシーやSmartScreen等の影響は別途あり得ます）。
また、社内にAD CS（社内認証局）がある場合は、外部CAを使わずに「社内で信頼されるコード署名証明書」を発行し、ドメインGPOで信頼を配る…という構成も現実的です。外部向けではなく社内向けに閉じるなら、コストと運用のバランスが取りやすい選択肢です。
Visual Studio 2022のPublishでハマらないためのコツ
同じ「証明書エラー」を繰り返さないために、Publish周りで意識しておくと効くポイントをまとめます。
証明書を毎回作り直さない（PFXを固定して使う）
「Publishのたびに新しい自己署名証明書を作る」運用は、短期的には楽ですが、Publisherの揺れや更新失敗の原因になります。テストでも、ある程度継続するなら、署名に使う証明書（PFX）を固定し、チーム内で安全に管理して使い回す方が結果的に早いです。
- 同じアプリを継続的に更新するなら「同じ証明書で署名し続ける」
- 証明書の更新が必要なタイミングは、アプリ側の移行計画（アンインストール含む）とセットで決める
Publish出力フォルダーを“配布物一式”として扱う
配布時は、MSIXだけを単体で渡すのではなく、Publishで出力されたフォルダー（MSIX/MSIXBundle、.cer、依存関係がある場合はそれ一式）をセットで渡すと、受け取り側が迷いません。特にテスト担当が開発者ではない場合、「どの.cerを入れるのか」で詰まりがちです。
インストール前に「まず証明書を入れる」流れを固定する
作業手順として、MSIXを実行してエラーを見てから証明書を入れるよりも、最初から次の順序にしてしまうとスムーズです。
- .cerをローカル コンピューター > 信頼されたルート証明機関へ入れる
- MSIXを実行してインストール
この順序を手順書やチームWikiに固定しておくと、引き継ぎや検証端末の追加が楽になります。
「どの証明書で署名したか」をアプリ側でメモしておく
自己署名証明書は、開発者PCで気軽に作れてしまう分、チーム開発だと“誰がどの証明書で署名した版なのか”が分からなくなりがちです。次のような情報をリリースノートや配布メールに1行入れるだけで、トラブル対応が速くなります。
- 証明書のサブジェクト（例：CN=YourCompany Test Signing）
- 拇印（Thumbprint）の先頭8桁
- アプリのバージョン（MSIXのVersion）
まとめ：自己署名なら「各PCで信頼させる」が正攻法。運用は早めに設計する
.NET MAUI（Windows）アプリをMSIXで別PCに配布したときの「証明書が見つからない／証明書エラー」は、ほとんどが自己署名証明書を配布先PCの正しいストアに入れていないことが原因です。MSIXと同じフォルダーの.cerを、ローカル コンピューターの信頼されたルート証明機関へ入れることで解消できるケースが多いです。
ただし、台数が増えると手作業は破綻します。社内展開ならGPOやIntuneで証明書配布を仕組み化する、社外や大規模展開ならCA発行のコード署名証明書や別配布手段を検討する――このあたりまで含めて設計しておくと、MSIX配布が“毎回の事故”になりません。
コメント