Visual Studio 2022 17.12 以降で iOS 開発証明書が作れない(bearer token エラー)を直す方法【.NET MAUI】

Visual Studio 2022 を 17.12(17.12.2)以降に更新したら、.NET MAUI の iOS 実機ビルドで証明書の再作成ができず「properly configured and signed bearer token」が出る…という相談が増えています。本記事では原因の考え方と、VS のキャッシュ整理+p12 / mobileprovision の手動インポートで確実に復旧する手順をまとめます。

目次

起きている現象(Visual Studio 2022 17.12 以降)

.NET MAUI(または Xamarin.iOS を使う構成)で iOS 実機向けに署名・配布しようとしたとき、Visual Studio 2022 17.12 以降で次のような症状がまとまって発生することがあります。

  • 期限切れになった iOS 開発証明書(Development / Apple Development) を作り直そうとして、Visual Studio の Tools → Options → Xamarin → Apple Accounts から Create Certificate を押すと、「provide a properly configured and signed bearer token」 が出て失敗する
  • Configure Automatic Provisioning(自動プロビジョニング)も同じ bearer token エラーで止まる
  • Apple Developer Portal(Web)では新しい証明書やプロビジョニングプロファイルが存在するのに、Visual Studio の Signing identity(署名 ID) に新しい開発証明書が出てこない
  • Visual Studio から Mac に接続(Pair to Mac)すると、期限切れの古い開発証明書が Mac のキーチェーンに“復活”したように見える(古いものが勝手に入ってくる/候補に出る)

この状態では、ビルドそのものは通るのに実機配置で署名エラーになったり、Signing identity が選べず先へ進めなかったりと、開発体験が大きく崩れます。特に「Portal にはあるのに VS には見えない」というズレは、原因の切り分けが難しくなりがちです。

「properly configured and signed bearer token」の意味

このエラーは、単に「証明書が無い」ではなく、Visual Studio が Apple 側の API にアクセスして証明書・プロファイルを自動生成/同期する処理が失敗しているサインとして捉えると理解が早いです。

bearer token は、一般に HTTP API 呼び出しで使う認可トークン(JWT など)を指します。Visual Studio の自動プロビジョニングは、Apple ID のサインインだけでなく、API 経由で証明書・デバイス・プロファイルを扱う場面があり、そこでトークンの生成・署名・送信がうまくいかないと「properly configured and signed bearer token」といった文言が出ます。

疑うべきポイント起きやすいこと見え方の例
API キー(p8)やトークン生成まわり期限切れ・失効(revoke)・チーム不一致・権限不足などで API 連携が失敗Create Certificate / Automatic Provisioning が bearer token エラーで止まる
Visual Studio / Xamarin のローカルキャッシュ期限切れ証明書が残り続け、同期時に誤認識するPortal には新しいのに VS に出ない/古い証明書が復活したように見える
証明書とプロファイルの整合性証明書を作り直したのにプロファイルが古いままなど、紐づきが崩れるSigning identity は見えるが Provisioning profile が選べない/実機署名で失敗

つまり、bearer token のエラー自体を無理に“直す”より、証明書とプロファイルを手動で正しい状態に持っていき、VS 側に認識させる方が復旧が速いケースがあります。

まず押さえたい基礎:証明書・プロファイル・キーチェーンの関係

トラブル時は「どこに何が存在しているか」を整理すると迷いが減ります。iOS の署名まわりは部品が多く、どれか 1 つが欠けても Visual Studio の画面上で“見えているのに動かない”が起きます。

要素役割主な保管場所ズレるとどうなる?
開発証明書(Apple Development)実機向けデバッグビルドに署名するMac:キーチェーン/Windows:p12 として取り込みSigning identity に出ない/署名できない
秘密鍵(private key)証明書で署名するために必須Mac:キーチェーン(証明書と鍵がセット)証明書だけ見えても署名できない(エクスポートできない等)
プロビジョニングプロファイル(.mobileprovision)App ID・証明書・端末 UDID を束ね、実機実行を許可するApple Developer Portal/Mac:Provisioning Profiles フォルダ/Windows:Xamarin キャッシュProvisioning profile が選べない/端末に入らない
App ID(Bundle Identifier)アプリの識別子(例:com.example.app)Apple Developer Portalプロファイル作成時に一致せず無効になる
登録デバイスDevelopment / Ad Hoc で動かせる端末Apple Developer Portal端末が含まれず実機インストールで弾かれる

原因の切り分けチェック(最短で「どこがズレているか」を掴む)

次のチェックを上から順に行うと、bearer token エラーを抱えたままでも、復旧の当たりを付けられます。

チェック確認方法OK ならNG なら
Portal で開発証明書が有効かApple Developer Portal の Certificates で期限・状態を確認次は VS 側の見え方を疑う証明書を作り直す(Portal 側で作成)
Mac のキーチェーンに秘密鍵付きで存在するかキーチェーンアクセスの「マイ証明書」で証明書の左に矢印(鍵)があるかp12 に書き出せる可能性が高い証明書の再発行(CSR からやり直し)や、鍵を持つ Mac を探す
新しいプロビジョニングプロファイルをダウンロードできるかProfiles で iOS App Development を新規作成→DownloadVS への手動取り込みで復旧しやすいApp ID / デバイス / 証明書の紐づきを見直す
VS の Signing identity に “古いもの” だけ出るかプロジェクトの iOS → Bundle Signing を開くキャッシュ掃除+再インポートで改善することが多いアカウント切替・チーム不一致・ビルドホストの鍵問題も疑う

解決の全体像:2 つのアプローチ

今回のように「VS 側の Create Certificate が bearer token で失敗し続ける」「Portal にはあるのに VS に出ない」という状況では、解決策は大きく 2 ルートに分かれます。

  • ルートA:bearer token の原因(Apple API 連携)を正して自動プロビジョニングを復活させる
    API キー(p8)の作り直し・権限やチームの見直し・VS への再登録を行い、VS から自動作成できる状態に戻す。
  • ルートB:VS のキャッシュを整理し、証明書(p12)とプロファイル(mobileprovision)を手動インポートして“見える状態”にする
    自動化が壊れていても、手動で整合の取れた組み合わせを VS に認識させれば実機ビルドは再開できる。

急いで開発を再開したい場合は、まず ルートB の方が成功率が高く、手戻りが少ないです。自動化(ルートA)は復旧後に落ち着いて取り組む、という順番が現実的です。

ルートA:自動プロビジョニングを復活させたい場合の要点

bearer token エラーが出ている場合、Visual Studio が Apple の API に対して正しい認証情報を作れない状態です。環境によって原因は分岐しますが、チェックの観点は共通しています。

  • API キー(.p8) が失効・削除されていないか(チーム側で revoke された等)
  • API キーを作った チーム(Team) が、VS で選択している Apple アカウントのチームと一致しているか
  • API キーに紐づく 権限(Role) が足りているか(証明書・プロファイルを操作できないと失敗)
  • 組織の プロキシ/SSL インスペクション によってトークン送信や通信がブロックされていないか
  • Windows / Mac の 時刻が大きくズレていないか(JWT は時間ズレに弱い)

ここを直すと自動作成が戻ることがあります。ただし、すでに「Portal には正しい証明書がある」「手動で p12 が作れる」状況なら、次のルートBで開発を先に前へ進めるのが得策です。

ルートB:VS のキャッシュ整理+手動インポートで復旧する(おすすめ)

このルートの狙いはシンプルです。

  • Visual Studio が握っている 期限切れ証明書のキャッシュ を消して混乱を止める
  • Mac 側で正しい証明書(秘密鍵付き)を p12 として書き出し、VS に Import Certificate で取り込む
  • 証明書と一致する 開発用プロビジョニングプロファイル(mobileprovision) を用意し、VS が参照する場所へ置く
  • プロジェクトで Signing identity / Provisioning profile を明示的に選び直す

以降は「失敗しにくい順番」で具体的に進めます。

Windows 側:期限切れ証明書のキャッシュを整理する

まずは Visual Studio(Xamarin / MAUI)が持っているローカルキャッシュを整理します。ここに古い証明書が残っていると、VS がそれを優先して表示したり、Mac 接続時に古い証明書情報を押し戻したりして、症状がループしがちです。

代表的な場所(ユーザーごとに存在します):

C:\Users\(あなたのユーザー名)\AppData\Local\Xamarin\iOS\Provisioning\Certificates
対象フォルダ/ファイル中身削除の狙い
…\Provisioning\Certificates\*.p12VS が取り込んだ証明書(秘密鍵込み)の実体期限切れや不要な証明書を VS から“見えない”状態にする
…\Provisioning\Certificates\*.passp12 に付けたパスワード情報p12 とセットで残り続けるのを防ぐ

作業のコツ:

  • いきなり削除が不安なら、まずは別フォルダに退避(バックアップ)してから削除します。
  • 「何が期限切れか分からない」場合、Portal 側の証明書名・期限を見ながら整理します。迷うなら“開発用”だけに絞って掃除し、配布用(Distribution)は触らない方が安全です。
  • 削除後は Visual Studio を一度終了し、再起動してから次の手順へ進みます。

Mac 側:有効な開発証明書を p12 で書き出す

次に、Mac のキーチェーンアクセスから 有効な開発証明書 を p12 で書き出します。ここで重要なのは、証明書単体ではなく「秘密鍵付き」で書き出すことです。秘密鍵が無い p12 は署名に使えず、VS に出ても実機ビルドで詰まります。

  1. Mac で キーチェーンアクセス を開く
  2. 左側で「ログイン」キーチェーンを選び、カテゴリは 「マイ証明書」(My Certificates)を開く
  3. 一覧から Apple Development(または iPhone Developer)と表示される、目的の証明書を探す
    ポイント:証明書の左に開閉できる矢印があり、展開すると秘密鍵がぶら下がっていれば“秘密鍵付き”です。
  4. 対象の証明書を右クリック → 書き出し(Export)
  5. 形式は .p12 を選び、必ずパスワードを設定して保存

p12 は秘密鍵を含むため取り扱いに注意してください。開発チーム内で共有する場合も、保管場所・パスワード管理・不要になったら破棄するなど、最低限のルールを決めておくと安全です。

Visual Studio:p12 を Import Certificate で取り込む

Windows へ p12 をコピーしたら、Visual Studio で Apple アカウントの詳細画面から取り込みます。

  1. Visual Studio で Tools → Options → Xamarin → Apple Accounts
  2. 対象の Apple アカウントを選び、View Details を開く
  3. Import Certificate を選択し、先ほどの .p12 を指定
  4. p12 作成時に設定したパスワードを入力して取り込む

取り込み後、Visual Studio が保持するキャッシュ(先ほどの Certificates フォルダ)に p12 が配置され、iOS の署名候補として扱える状態になります。うまく一覧に反映されない場合は、いったん Visual Studio を再起動するか、Apple Accounts の詳細画面を開き直して再確認します。

Apple Developer Portal:証明書と一致する開発プロファイルを作り直す

証明書を更新した直後や、過去にプロファイルを整理した直後は、プロビジョニングプロファイルが古い証明書を参照したままになりがちです。Portal 側で「いま有効な証明書」を選んだ開発プロファイルを新規作成しておくと、VS の Bundle Signing で迷いません。

  1. Apple Developer Portal の Profiles で iOS App Development(開発用)を新規作成
  2. 対象の App ID を選択(ワイルドカード App ID を運用している場合はそれでも可)
  3. 先ほど用意した 開発証明書 を選択
  4. 実機デバッグする デバイス(UDID 登録済み)を選択
  5. 作成して Download(.mobileprovision を取得)

ここで作るのは「Development」プロファイルです。Ad Hoc や App Store 用プロファイルを選ぶと、Signing identity の種類が合わずに詰まるので注意してください。

Windows 側:mobileprovision を VS が見る場所に配置する

ダウンロードした .mobileprovision を Windows に持ってきて、Xamarin のプロビジョニングキャッシュに置きます。環境によって Profiles フォルダ配下に入ることがあります。

配置先の例目的メモ
…\AppData\Local\Xamarin\iOS\Provisioning\VS がプロファイルを検出する基点環境により自動で Profiles 配下へ整理されます
…\AppData\Local\Xamarin\iOS\Provisioning\Profilesプロファイル専用フォルダ見当たらなければ上位 Provisioning 直下へ置いても構いません

配置後も VS 側に出ない場合は、いったん Visual Studio を再起動し、次の Bundle Signing 画面で選択肢が増えているか確認します。

プロジェクト:iOS の署名設定(Bundle Signing)を選び直す

最後に、プロジェクトの iOS 署名設定で、いま取り込んだ証明書とプロファイルを明示的に選びます。

  1. 対象プロジェクトを右クリック → プロパティ
  2. iOS → Bundle Signing
  3. Signing identity(署名 ID) に、インポートした開発証明書(Apple Development)を選択
  4. Provisioning profile に、Portal からダウンロードした開発用プロファイルを選択
  5. 保存して、実機ビルド&配置を試す

この段階で「Signing identity は見えるが Provisioning profile が空」なら、プロファイルが正しい場所に置けていないか、プロファイルの中身(App ID / 証明書 / 端末)が現在の構成と一致していない可能性が高いです。

古い(期限切れ)証明書が Mac 側に“復活”して見える理由

Visual Studio と Mac(ビルドホスト)は、接続時に証明書やプロファイルの情報を同期します。ここで Windows 側に古い p12 が残っていると、VS がそれを“正”として扱い、Mac 側へ再度取り込ませようとする挙動に見えることがあります。

その結果、Mac のキーチェーンで「さっき消したはずの期限切れ証明書がまた出てきた」「候補に古いものが混じる」といった混乱が起きます。今回のルートBで最初に Windows 側キャッシュ(Certificates の *.p12 / *.pass)を整理するのは、このループを止める意味合いも大きいです。

配布用(Distribution)証明書に影響はある?

「Apple Accounts を消すと配布用証明書やプロファイルも消えるのでは?」という不安はよくあります。結論から言うと、Portal 上の証明書が消えるわけではありません。ただしローカルに取り込んでいた p12 を削除すると、当然ながら Visual Studio からは参照できなくなります。

運用上の安全策としては次の考え方が現実的です。

  • 今回の復旧では、まず 開発用(Development)に絞って キャッシュを整理する
  • 配布用(Distribution)p12 は触らない/削除する場合は 必ずバックアップ を取る
  • 「何がどれか分からない」状態なら、先に Portal 側の名前と期限を整理し、後からローカルを合わせる

よくある落とし穴(ここで詰まる人が多い)

  • p12 を書き出したのに VS で署名できない
    キーチェーンで「秘密鍵付き」の証明書を選べていない可能性があります。マイ証明書で鍵がぶら下がっているものを選び直してください。
  • プロファイルを置いたのに VS に出ない
    配置先が違う、または VS のキャッシュが更新されていないことがあります。VS 再起動、Profiles 配下の確認、そしてプロファイル自体が Development であることを再確認します。
  • Bundle Identifier が一致していない
    プロジェクトの Bundle Identifier(例:com.example.app)と、Portal の App ID が一致していないとプロファイルが無効になります。ワイルドカード運用でも、想定どおりマッチしているか確認します。
  • 端末がプロファイルに含まれていない
    新しい iPhone に変えた直後などは UDID 登録が漏れがちです。Portal の Devices と Profile の選択デバイスを見直します。
  • チームが違う
    同じ Apple ID でも複数チームに所属していると、Portal で作った証明書と VS が見ているチームがズレます。Apple Accounts のチーム表示や、Portal の Team で揃えてください。
  • “開発用”と“配布用”の取り違え
    Development 証明書には Development プロファイル、Distribution 証明書には Ad Hoc / App Store など、種類を合わせる必要があります。

それでも直らない場合の追加チェック

ルートBをやっても VS に反映されない・ビルドが不安定、というときは、周辺要因が絡んでいる可能性があります。次を上から順に確認してください。

追加チェックやること狙い
Visual Studio の MAUI / iOS ワークロード更新Visual Studio Installer で .NET MAUI / iOS 関連を更新・修復17.12 系の更新で依存関係がズレた場合の回復
Mac 側の Xcode / コマンドラインツールXcode の更新、起動してライセンス同意、Command Line Tools 設定確認ビルドホスト側の署名・ビルド基盤を整える
Mac のプロファイルキャッシュ不要な Provisioning Profiles を整理(必要なら再ダウンロード)Mac 側に古いプロファイルが大量に残っていると誤認識が増える
時刻同期Windows / Mac の時刻を自動同期にするJWT や署名の検証で時間ズレが原因になるのを防ぐ
ネットワーク(VPN/プロキシ)一時的に迂回して再試行、または例外設定を検討Apple の API への通信が遮断されるケースの切り分け

それでも bearer token エラーを根本から解消したい場合は、ルートAとして API キー(p8)を新規に作って Visual Studio 側のアカウント情報を更新する、あるいは Visual Studio から Apple アカウントをいったん削除して再追加する、という選択肢が残ります。開発を止めないためにも、まずは手動インポートで実機ビルドを復旧させてから、落ち着いて自動化を取り戻す流れがおすすめです。

再発防止のコツ(運用を少し変えるだけで楽になる)

  • p12 とパスワードを安全に保管:証明書更新時の復旧が早くなります(権限管理された保管場所に限定)。
  • 証明書・プロファイルの命名を揃える:チーム内で「どれが開発用か」が一目で分かると、更新時に迷いません。
  • プロファイルは証明書更新のたびに作り直す前提で考える:古い組み合わせが残ると VS 側の候補が増え、選択ミスが起きやすくなります。
  • 不要な期限切れ証明書は Portal / ローカル双方で整理:VS のキャッシュ問題が絡む場合も、母集団を減らすほど安定します。

まとめ

Visual Studio 2022 17.12 以降で iOS 開発証明書の作成が bearer token エラーになる場合、原因は「Apple の API 連携」か「Visual Studio(Xamarin)のキャッシュ」か、またはその両方が絡んでいることが多いです。Portal と Mac では正しいのに VS に出てこないときほど、期限切れキャッシュを消し、p12 と mobileprovision を手動で取り込んで整合を取り直す方法が強力です。

一度この手順で復旧できれば、以後は「証明書を更新したらプロファイルも作り直し、VS 側には必要なものだけを取り込む」という運用で、同種のトラブルをかなり減らせます。まずは開発を止めないことを優先し、確実に動く組み合わせを VS に認識させてください。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次