決済アプリのmTLS証明書更新【2026年6月】

8月 16, 2026

PAYMENTS APPS

決済アプリのmTLS証明書更新
2026年6月15日対応ガイド

標準検証なら対応不要 / カスタム検証は6月15日までに修正必須

Shopifyは2026年6月15日より、Payments Appがリクエスト発信元をShopifyと確認するために使用するmTLSクライアント証明書を更新します。新証明書は現行と同じ認証局（CA）によって署名されているため、標準的なmTLS検証を使用している場合は何も対応不要です。一方、証明書のCN（Common Name）などの個別フィールドを独自ロジックで検証しているアプリは、2026年6月15日までに検証ロジックの更新が必要です。

1変更の背景と全体像

2対応要否の判断フロー

3業務・開発で活かせるユースケース

課題: セキュリティ強化目的で証明書のCN値を独自コードでハードコードチェックしており、このまま6月15日を迎えると新証明書を拒否して決済が止まる恐れがある。
打ち手: CN等の固定値チェックを削除し、CAによる署名チェックのみに切り替える。または新証明書の詳細（公式ドキュメントの「certificate details」参照）をもとに許容する値を更新する。
効果: 証明書更新のたびに改修が発生するリスクを排除でき、長期的な保守コストを削減できる。
技術メモ: 公式は標準mTLS検証（CA署名確認）への移行を推奨。CA自体は変わらないため、信頼チェーン検証のみなら無修正で通過する。

課題: 複数のPayments Appを運営するパートナーが、影響範囲を素早く特定できず、どのアプリを優先的に確認すべきか判断できない。
打ち手: mTLS検証コードが含まれるアプリ一覧を棚卸しし、CN・SANなど証明書固有フィールドを参照している箇所をgrepや静的解析で洗い出す。
効果: 修正が必要なアプリとそうでないアプリを明確に分類でき、6月15日の期限に向けた開発リソースを適切に配分できる。
技術メモ: 検索キーワード例: `getSubjectDN`, `getCN`, `subject.commonName`, `peer_certificate` など言語・フレームワーク依存のAPI名で検索するとヒットしやすい。

課題: 新証明書への切替後に問題が発生した場合、本番決済への影響を最小化しながら迅速に原因を特定したい。
打ち手: 6月15日以降のmTLSハンドシェイクエラーをアラートで検知できるよう、サーバーログや監視ツールに証明書関連エラー（TLS handshake failed等）の通知設定を事前に追加しておく。
効果: 万一エラーが発生してもリアルタイムで検知でき、決済停止時間を最小化できる。
技術メモ: 元記事には具体的なロールバック手順の記載なし。問題発生時はShopify Partnersサポートへ速やかに連絡することを推奨。

4技術者が押さえておくべきポイント

項目	内容	対応要否
対象	Payments Appのみ（通常のStorefront/Admin APIには言及なし）	—
切替日	2026年6月15日（新証明書の使用開始）	カスタム検証者は期限
現行証明書失効	2026年7月24日	それまでに対応完了必須
CA（認証局）の変更	なし。新旧ともに同一CAが署名	標準検証なら影響なし
カスタム検証の定義	CN・その他証明書固有フィールドを独自ロジックでチェックしている場合	要対応（6/15まで）
詳細証明書情報	公式ドキュメントの「certificate details」ページに記載あり	カスタム検証者は要確認
Liquid / テーマへの影響	記載なし（バックエンドのPayments Appに限定した変更）	—