Salesforce管理者や、情シス担当の方へ。
先日、Salesforceから「【重要】ルート証明書の変更に向けた準備のお願い」という、ちょっとドキッとするタイトルのメールが届きませんでしたか？
「証明書？ ルート？ チェーン？ 2月5日までに準備しろって言われても…何すればいいの！？」と焦っている方もいるかもしれません。
でも安心してください。大半のユーザーにとっては「何もしなくてOK」な案件です。
ただし、一部のシステム連携には「落とし穴」があります。
この記事では、専門用語をできるだけ使わずに「何が起きるのか」と「誰が何をチェックすべきか」をリスト形式でまとめました。
2026年2月5日、Salesforceがセキュリティ上の「身分証明書」を新しいものに切り替えます。
空港の入国審査をイメージしてください。
今回起きるのは、Salesforceが「新しい発行元（DigiCert G2）のパスポート」に切り替えるということです。
もし、あなたのシステム（審査官）が「えっ、この発行元知らないんだけど！怪しいから通さない！」となってしまうと、連携エラーが起きてしまいます。
これを防ぐために、「この新しい発行元も信頼していいよ」とシステムに教えてあげる必要があります。
基本的には、PCのブラウザ（ChromeやEdge）でSalesforceを見ているだけの人は何もしなくて大丈夫です（自動で更新されるため）。
要注意なのは「システム連携（API接続）」をしている場合です。
以下のリストを情シス担当や開発ベンダーに投げて確認してもらいましょう。
社内のサーバーやAWS上のシステムから、Salesforceにデータを送ったり取ってきたりしていませんか？
特にJavaを使っている場合は要注意です。
チェックポイント: Javaのバージョンを確認！
※その他の言語でも、古い環境だと証明書が入っていない可能性があります。
これはエンジニア向けの確認事項ですが、一番の落とし穴です。
セキュリティを厳しくしすぎて、「特定の古い証明書と完全に一致しないと通信させない（Pinning設定）」というコードを書いていませんか？
チェックポイント:
🔍 調査対象のコード例 もしこのようなコードが見つかった場合、Salesforceの証明書が切り替わった瞬間に接続エラーが発生します。
例1：Java (標準的な実装) カスタムの TrustManager を実装し、その中でサーバーから送られてきた証明書のハッシュ値を計算して、事前に登録したハッシュ値と比較しているパターンです。 // 危険な実装例：特定のハッシュ値としか接続しない設定
private static final String EXPECTED_CERT_HASH = "A1:B2:C3:D4:E5:F6:78:90:A1:B2:C3:D4:E5:F6:78:90:A1:B2:C3:D4:E5:F6:78:90:A1:B2:C3:D4"; // ← これが「指紋」の埋め込み
// ... (中略) ...
@Override public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException { // サーバーから提示された証明書(chain[0])のハッシュを計算 String serverCertHash = getThumbprint(chain[0]);
// 事前に埋め込んだハッシュ値と一致するか確認 if (!EXPECTED_CERT_HASH.equalsIgnoreCase(serverCertHash)) { // 一致しなければエラーにする（これが接続障害の原因になります） throw new CertificateException("Certificate pinning failure! Server certificate not trusted."); }}
例2：Java / Android (OkHttp ライブラリを使用) モダンなJavaアプリケーションやAndroidアプリでよく使われる OkHttp という通信ライブラリでは、設定で簡単にピニングができてしまいます。 // 危険な実装例：CertificatePinner を使った設定
String hostname = "your-instance.salesforce.com"; CertificatePinner certificatePinner = new CertificatePinner.Builder() // ↓ ここに特定の証明書のハッシュ値が埋め込まれている .add(hostname, "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=") .build();
OkHttpClient client = new OkHttpClient.Builder() .certificatePinner(certificatePinner) .build();
例3：Node.js (httpsモジュールなど) Node.jsでも、接続オプションでサーバーの同一性確認ロジックを上書きし、ハッシュ値を比較している場合があります。 // 危険な実装例：checkServerIdentity でハッシュを比較
const https = require('https'); const crypto = require('crypto');
// ↓ 埋め込まれたハッシュ値 const PINNED_FINGERPRINT = 'A1:B2:C3:D4:E5:F6:78:90:A1:B2:C3:D4:E5:F6:78:90:A1:B2:C3:D4:E5:F6:78:90:A1:B2:C3:D4';
const options = { hostname: 'your-instance.salesforce.com', port: 443, method: 'GET', checkServerIdentity: function (host, cert) { // サーバー証明書のフィンガープリントを取得 const fingerprint = cert.fingerprint256;
// 埋め込んだ値と一致するか確認 if (fingerprint !== PINNED_FINGERPRINT) { // 一致しなければエラー（接続障害） throw new Error('Certificate pinning failed!'); } // ホスト名の検証は標準に任せる return tls.checkServerIdentity(host, cert);} };
// ... https.request(options, ...) で接続
「一度作ったら壊れるまで動かす」精神で、10年以上アップデートしていないサーバー（Windows Server 2008など）や、極端に古いLinuxなどが連携に関わっていませんか？
チェックポイント:
あなたが非エンジニア（管理者・利用部門）なら、以下のメッセージをコピーして、IT担当者や開発ベンダーに送るだけでOKです。
「ルート証明書の変更」は、インターネットの世界では定期的に行われる「道路の舗装工事」みたいなものです。
ちゃんと整備された車（最新のブラウザやJava）に乗っていれば気づきもしませんが、整備不良の車（古いシステム）だと段差で止まってしまいます。
2月5日に「あれ、連携動かない！？」とパニックにならないよう、今のうちに「Javaのバージョン」と「ピニング設定」だけは確認しておきましょう！
