Shopify が「リクエスト元は本当に Shopify か」を証明するためのクライアント証明書を、2026 年 6 月 15 日から新しいものに切り替える。同じ認証局（CA）で署名されるため、標準的な mTLS 検証をしているアプリには影響なし。独自の証明書検証をしているアプリだけ、6/15 までに対応が必要。
証明書が信頼する CA のチェーンに連なるかだけを見ているアプリは、CA が同じなので新証明書もそのまま通る。対応不要。
証明書の Common Name（CN）など固有フィールドをチェックしているアプリは、6/15 までに新証明書を受け入れるよう検証ロジックを更新が必要。
この日から Shopify は新しいクライアント証明書を使い始める。カスタム検証をしているアプリは、この日までに新証明書を受け入れられるようにしておく必要がある。
現行の証明書はこの日に期限切れになる。無停止のサービス継続のため、それまでに更新が完了している必要がある、というのが今回の変更の理由。
| 項目 | 標準 mTLS 検証 | カスタム証明書検証 |
|---|---|---|
| 検証している内容 | 証明書が信頼する CA のチェーンに連なるか | CN（Common Name）など証明書固有のフィールド |
| 新証明書の影響 | 影響なし 同じ CA 署名なのでそのまま通る | 影響あり 固有フィールドが変わると弾く可能性 |
| 必要なアクション | なし | あり 新証明書を受け入れるよう検証を更新 |
| 期限 | — | 2026年6月15日まで |
CN や証明書のフィンガープリント等を文字列で突き合わせている処理があれば、それはカスタム検証に該当する。アプリが証明書のどのフィールド（CN、SAN、その他固有値）を見て判定しているかを洗い出す。
新しい証明書でも認証が通るよう検証ロジックを修正する。2026年6月15日までに反映する。
新旧証明書の具体的な値は、changelog がリンクする「certificate details」を参照する（本記事本文には具体値の記載なし）。
7/24 の旧証明書失効前に、新証明書での認証が想定通り通ることを検証環境で確認しておく。
Payments App が「相手が本物の Shopify か」を確認するために使う証明書が対象。アプリ側のサーバ証明書ではない。
新証明書は現行と同じ認証局で署名される。トラストストアの CA に対してチェーン検証しているだけなら自動的に信頼される。
CN や証明書固有値を直接突き合わせる検証は、新証明書でその値が変わると認証に失敗しうる。これが唯一の要対応パターン。
6/15 ＝ 新証明書の切替開始かつカスタム検証の対応期限。7/24 ＝ 旧証明書の失効日。無停止運用にはこの順序を踏まえて準備する。
本文は運用上の告知が中心で、CA 名や新旧証明書の具体的なフィールド値は本記事本文には記載なし。詳細は記事がリンクする「certificate details」を参照すること。検証ロジックを CN 依存にしている場合は、その値の差分を必ず実物で確認する。
CN や固有フィールドへの依存があるものを抽出。要対応リストを作り 6/15 から逆算して対応計画を立てる。