Payments Apps の mTLS クライアント証明書が更新される

図解 ： Payments Apps 向け mTLS クライアント証明書の更新 Platform Payments Apps API Payments Apps の mTLS クライアント証明書が更新される Shopify が「リクエスト元は本当に Shopify か」を証明するためのクライアント証明書を、2026 年 6 月 15 日から新しいものに切り替える。同じ認証局（CA）で署名されるため、標準的な mTLS 検証をしているアプリには影響なし。独自の証明書検証をしているアプリだけ、6/15 までに対応が必要。 このページの構成 そもそも何が起きるのか（30秒で理解） 仕組み図解 ： mTLS で何を検証しているか 2つの締切 ： タイムライン 自分は対応が必要か ： 判定フロー 対応が必要 / 不要のケース比較 やるべきこと（カスタム検証の場合） 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 そもそも何が起きるのか Payments App は mTLS（相互 TLS）で、「いま叩いてきた相手は本当に Shopify か」をクライアント証明書で確認している。 その Shopify 側のクライアント証明書が 2026 年 6 月 15 日から新しいものに更新される 。新証明書は今までと 同じ認証局（CA）で署名 されるため、標準的な検証なら何もしなくてよい。 標準 mTLS 検証なら ： 影響なし 証明書が信頼する CA のチェーンに連なるかだけを見ているアプリは、CA が同じなので新証明書もそのまま通る。 対応不要 。 カスタム検証なら ： 要対応 証明書の Common Name（CN）など固有フィールドをチェックしているアプリは、 6/15 までに新証明書を受け入れるよう検証ロジックを更新 が必要。 2 仕組み図解 ： mTLS で何を検証しているか mTLS（相互 TLS） とは ： 通常の TLS はサーバの正当性だけを確認するが、mTLS は クライアント側も証明書を提示して相互に身元を確認 する方式。Payments App はこれを使って「叩いてきたのが本物の Shopify か」を検証している。 今回更新されるのは Shopify が提示するクライアント証明書 。署名する CA は変わらないので、CA チェーンを見る標準検証なら新証明書も自動的に信頼される。 3 2つの締切 ： タイムライン 6/15 新証明書の更新が始まる日 この日から Shopify は新しいクライアント証明書を使い始める。カスタム検証をしているアプリは、 この日までに 新証明書を受け入れられるようにしておく必要がある。 7/24 旧証明書が失効する日 現行の証明書はこの日に期限切れになる。無停止のサービス継続のため、それまでに更新が完了している必要がある、というのが今回の変更の理由。 4 自分は対応が必要か ： 判定フロー 5 対応が必要 / 不要のケース比較 項目 標準 mTLS 検証 カスタム証明書検証 検証している内容 証明書が信頼する CA のチェーンに連なるか CN（Common Name）など証明書固有のフィールド 新証明書の影響 影響なし 同じ CA 署名なのでそのまま通る 影響あり 固有フィールドが変わると弾く可能性 必要なアクション なし あり 新証明書を受け入れるよう検証を更新 期限 — 2026年6月15日まで 自分が「標準」か「カスタム」かが曖昧な場合は要確認。 CN や証明書のフィンガープリント等を文字列で突き合わせている処理があれば、それはカスタム検証に該当する。 6 やるべきこと（カスタム検証の場合） ① 検証ロジックを棚卸し アプリが証明書のどのフィールド（CN、SAN、その他固有値）を見て判定しているかを洗い出す。 ② 新証明書を受け入れるよう更新 新しい証明書でも認証が通るよう検証ロジックを修正する。 2026年6月15日まで に反映する。 ③ 証明書詳細を確認 新旧証明書の具体的な値は、changelog がリンクする「certificate details」を参照する（本記事本文には具体値の記載なし）。 ④ 切替前後で疎通を確認 7/24 の旧証明書失効前に、新証明書での認証が想定通り通ることを検証環境で確認しておく。 標準 mTLS 検証（CA チェーンの検証のみ）をしているアプリは、上記いずれの作業も 不要 。新証明書は同じ CA で署名されるため、ライブの Payments App に影響はない。 7 技術者が押さえるべき5つのポイント 1. 更新されるのは「Shopify 側のクライアント証明書」 Payments App が「相手が本物の Shopify か」を確認するために使う証明書が対象。アプリ側のサーバ証明書ではない。 2. CA は変わらない＝チェーン検証は無傷 新証明書は現行と同じ認証局で署名される。トラストストアの CA に対してチェーン検証しているだけなら自動的に信頼される。 3. 壊れるのは CN / 固有フィールドのハードコード CN や証明書固有値を直接突き合わせる検証は、新証明書でその値が変わると認証に失敗しうる。これが唯一の要対応パターン。 4. 締切は2段階 ： 6/15 と 7/24 6/15 ＝ 新証明書の切替開始かつカスタム検証の対応期限。7/24 ＝ 旧証明書の失効日。無停止運用にはこの順序を踏まえて準備する。 5. 具体的な証明書の値は changelog のリンク先で確認 本文は運用上の告知が中心で、CA 名や新旧証明書の具体的なフィールド値は 本記事本文には記載なし 。詳細は記事がリンクする「certificate details」を参照すること。検証ロジックを CN 依存にしている場合は、その値の差分を必ず実物で確認する。 8 業務に活かせる3つのユースケース USE CASE 1 自社 Payments App の「無停止での証明書更新対応」 課題 自社の Payments App が、過去の実装で証明書の CN を直接チェックしている（カスタム検証）。新証明書で CN が変わると 7/24 の失効後に決済が止まりうる。 打ち手 6/15 までに検証ロジックを棚卸しし、新証明書を受け入れるよう更新。あわせて CA チェーン検証ベースへ寄せて将来の更新にも耐えるようにする。 効果 旧証明書失効後も決済処理を無停止で継続。証明書更新のたびの緊急対応を不要にできる。 技術メモ 新旧証明書の具体的なフィールド値は changelog の「certificate details」で確認（本文には記載なし）。検証環境で新証明書の疎通を事前確認する。 USE CASE 2 受託 / 保守先の Payments App 群を横断監査 課題 複数クライアントの Payments App を保守しているが、どれが標準 mTLS でどれがカスタム検証かを把握できていない。6/15 の期限に間に合わないリスク。 打ち手 各アプリの証明書検証コードを横断調査し、 CN や固有フィールドへの依存があるものを抽出。要対応リストを作り 6/15 から逆算して対応計画を立てる。 効果 影響範囲を早期に可視化し、決済断のリスクを事前に潰せる。クライアントへの能動的な告知で信頼を獲得。 技術メモ 標準検証（CA チェーンのみ）のアプリは対応不要と切り分けられるので、工数を要対応分に集中できる。 USE CASE 3 証明書ローテーション耐性の恒久的な作り込み 課題 今回のように CA が同じでも証明書本体が更新されるたびに、CN 固定の検証が壊れて緊急対応が発生してしまう構造。 打ち手 CN / フィンガープリント固定の検証をやめ、CA トラストストアに対するチェーン検証を標準とする方針へ恒久移行する。 効果 将来の証明書更新でコード変更が不要になり、運用の属人性と障害リスクを継続的に下げられる。 技術メモ 固有フィールドでの追加制約が業務上必要な場合は、更新頻度の低い項目を選ぶか、設定値として外出しして即時切替できる設計にする。 9 提案で使える1行サマリ 「Shopify が Payments App 向けに使う mTLS クライアント証明書を 2026/6/15 から更新（旧証明書は 7/24 失効）。 同じ CA で署名されるので標準 mTLS 検証のアプリは対応不要。 CN など証明書固有フィールドを見るカスタム検証だけ、6/15 までに更新が必要。」 source ： shopify.dev / changelog / mtls-client-certificate-renewal-for-payments-apps Developer Changelog ／ 公開日 ： 2026-04-13