Binance SSL証明書チェーンの照合：DigiCert主チェーンとOCSPステータス実践
Binance SSL証明書チェーン照合の完全実践：openssl s_client 取得、DigiCert と Sectigo 主チェーン検証、OCSP Stapling ステータス判定、Let's Encrypt 警戒ルール、証明書透明性CTログ照合。BiabaCoreがコマンドラインからブラウザまでの二経路SOPを提供します。
Binance SSL証明書チェーンの照合は、2026年の真偽判定5次元の中で「証拠チェーンの基盤」の役割を担います——証明書チェーンに1つでも不一致があれば、ドメインがどれほど本物に見えても通過させてはいけません。BiabaCoreはコマンドライン openssl の取得、ブラウザ鍵アイコンのクリック、DigiCert主チェーン構造、OCSP Stapling 判定、Let's Encrypt 警戒ルール、証明書透明性CTログ検索の6つの工程を完全にまとめました。基本的なコマンドライン能力を持つユーザーであれば5分以内に照合を完了できます。真偽判定の総則は /docs/binance-official-url-2026/ を参照；公式入口は Binance公式サイト または ダウンロードページ からアクセスしてください。
一、Binance証明書チェーン構造の総覧
A：Binanceのメインドメイン binance.com の2026年の証明書チェーンは3段構造：リーフ証明書は DigiCert Global G2 中間CAが発行、中間CAは DigiCert Global Root G2 ルート証明書が発行、ルート証明書はすべての主要OSに組み込まれています。この主チェーンを逸脱する証明書はすべて異常信号です。
3段の証明書チェーン
| 階層 | 名称 | 有効期限 | 署名アルゴリズム |
|---|---|---|---|
| ルート証明書 | DigiCert Global Root G2 | 2038-01-15 まで | SHA256RSA |
| 中間証明書 | DigiCert Global G2 TLS RSA SHA256 2020 CA1 | 2030-03-30 まで | SHA256RSA |
| リーフ証明書 | *.binance.com / binance.com | 通常1年 | SHA256RSA |
予備の発行主体
BiabaCoreは2026年上半期に、少数のBinanceサブドメインが Sectigo RSA Domain Validation Secure Server CA によって発行されていることも観測しました、主に academy.binance.com などのドキュメントサイトで使用されています。binance.com、accounts.binance.com などのコア取引ドメインは依然として DigiCert チェーンで固定です。
証明書 Subject フィールド
- CN: *.binance.com
- O: Binance Holdings Limited
- L: コンプライアンス主体所在地に依拠
- C: KY / MT / AE など（Binanceグループ登録地）
A：Subject の O フィールドは「Binance Holdings Limited」、O フィールドが空欄、個人氏名、無関係会社名の場合はいずれも偽造と判定します。
二、openssl s_client 取得コマンド
A：openssl s_client は最も直接的で信頼できる証明書チェーン取得ツール、Windows/macOS/Linux を横断して利用可能で、取得したデータはオフラインで分析できます。
基本取得コマンド
openssl s_client -connect binance.com:443 -servername binance.com -showcerts < /dev/null
Windows で openssl が入っていない場合、https://slproweb.com/products/Win32OpenSSL.html からダウンロードできます。macOS は LibreSSL が同梱されており、brew install openssl でオリジナルの OpenSSL に置き換えられます。
出力の読み方
コマンド出力には以下が含まれます：
Server certificateセクション：リーフ証明書の PEM エンコードCertificate chainセクション：チェーンの各層Verify return code：チェーン検証結果（0は通過）SSL Sessionセクション：TLSバージョン、暗号スイート
比較用に単一証明書を取得
openssl s_client -connect binance.com:443 -servername binance.com < /dev/null 2>/dev/null | openssl x509 -outform PEM > binance.pem
binance.pem ファイルを取得後、openssl x509 -in binance.pem -text -noout でオフラインで全フィールドを確認できます。
SHA-256 フィンガープリントの取得
openssl x509 -in binance.pem -fingerprint -sha256 -noout
出力されたフィンガープリントを既知の公式サンプルと比較します。BiabaCore情報ライブラリは月次で既知有効証明書フィンガープリントリストを発行しています。
三、DigiCert 主チェーンの検証
A：DigiCert Global Root G2 の SHA-256 フィンガープリントは固定：cb:3c:cb:b7:60:31:e5:e0:13:8f:8d:d3:9a:23:f9:de:47:ff:c3:5e:43:c1:14:4c:ea:27:d4:6a:5a:b1:cb:5f。このフィンガープリントを照合することが、ルート証明書が差し替えられていないことを確認する鍵です。
中間CAフィンガープリント照合表
| 中間CA名 | SHA-256 フィンガープリント先頭8バイト |
|---|---|
| DigiCert Global G2 TLS RSA SHA256 2020 CA1 | 1e:44:3c:2c:14:52:f4:1d |
| DigiCert Global G3 TLS ECC | e8:78:8a:03:87:b8:f3:d3 |
| DigiCert TLS RSA SHA256 2020 CA1 | 3f:66:f9:b3:71:1b:60:d5 |
取得した中間証明書の SHA-256 先頭8バイトが上表のいずれかに一致するはずです。一致しない場合、証明書チェーンが差し替えられています。
チェーン完全性の検証
openssl verify -CAfile /etc/ssl/certs/ca-bundle.crt -untrusted intermediate.pem leaf.pem
出力 OK はチェーン完全を意味します。unable to get local issuer certificate や certificate verify failed はいずれも拒否対象です。
四、OCSP Stapling ステータス判定
A：OCSP Stapling はサーバが能動的に OCSP レスポンスを TLS ハンドシェイクに同梱するメカニズム、2026年時点でBinanceメインサイトは全面的に有効化しています。取得した OCSP レスポンスは Cert Status: good を示すべきです。
OCSP Stapling の取得
openssl s_client -connect binance.com:443 -status < /dev/null 2>/dev/null | grep -A 10 "OCSP response"
期待される出力片：
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Cert Status: good
OCSP ステータスの意味
| ステータス | 意味 | 対処 |
|---|---|---|
| good | 証明書有効 | 通過 |
| revoked | 失効済み | 即拒否 |
| unknown | CAが該当証明書を認識せず | 高度に疑わしい、拒否 |
| OCSPレスポンスなし | サーバが Stapling 未設定 | 手動で二次確認が必要 |
A：取得したレスポンスが revoked または unknown の場合、ドメインとリーフ証明書が正常に見えても、必ず拒否します。攻撃者が失効済みまたは吊るし上げられた正規証明書をリプレイしている可能性があります。
Stapling なし時の独立 OCSP クエリ
openssl ocsp -issuer intermediate.pem -cert leaf.pem -text -url http://ocsp.digicert.com
-url で CA の OCSP エンドポイントを指定する必要があります。DigiCert のエンドポイントは http://ocsp.digicert.com、Sectigo は http://ocsp.sectigo.com です。
五、Let's Encrypt 警戒ルール
A：Binanceメインサイトとコアサブドメインは2026年時点で Let's Encrypt を使用しません、リーフ証明書の Issuer が Let's Encrypt Authority である場合はすべて高度に疑わしいシグナルと見なします。
Let's Encrypt を判定する3フィールド
- Issuer CN に "Let's Encrypt" を含む
- Issuer O が "Let's Encrypt"
- 証明書有効期間が90日（Let's Encrypt の強制上限）
なぜ Let's Encrypt は高度に疑わしいか
Let's Encrypt は無料自動化CAで、任意のドメインが30秒以内に発行可能です。フィッシング站の93%近くが Let's Encrypt を使用（データは /docs/binance-phishing-domain-yearly-stats/ 参照）。Binanceはコンプライアンス取引所として必然的に有料の拡張検証証明書を採用し、無料自動化CAを利用することはありません。
ごく少数の例外
一部の非取引性質のサブドメイン（一回性のマーケティングイベントサブドメインなど）が短期的に Let's Encrypt を使うことがあります。BiabaCoreの推奨：
- コアドメイン（binance.com / accounts.binance.com / api.binance.com）は Let's Encrypt を絶対に許容しない
- 周辺サブドメインで Let's Encrypt が現れた場合、5次元中のASN帰属と組み合わせて二次確認を要求
六、証明書透明性 CT ログ
A：証明書透明性（Certificate Transparency）ログはすべての公開発行SSL証明書が提出必須の公開ログ、誰でも crt.sh や Google CT で特定ドメインの過去に発行された全証明書を検索できます。これは疑わしい証明書を識別するもう一つの独立チャネルです。
crt.sh 検索フロー
- https://crt.sh を開く
binance.comと入力- 返される証明書リストを確認
- 最新の証明書の Issuer が取得したものと一致するか照合
- 発行時刻が合理的なウィンドウ内かを照合
CTログで検出できる攻撃
- 攻撃者が盗んだAPIで正規CAから発行させた偽造証明書
- ドメイン乗っ取り後に短期挿入された自己署名証明書
- 中間者プロキシが臨時発行した証明書
CTログ照合のヒューリスティック
| 観察 | 判定 |
|---|---|
| 取得した証明書のシリアル番号が crt.sh に見つからない | 極高リスク、ローカル偽造の可能性 |
| crt.sh 上の最新証明書と取得したものが一致しない | 高リスク、中間者の可能性 |
| crt.sh 上で特定日に短期証明書が大量発行 | 中リスク、攻撃試行の可能性 |
| 取得した証明書がCTログに数年の履歴あり | 正常 |
七、ブラウザ鍵アイコン照合（コマンドライン不要版）
A：コマンドラインが使えない場合、ブラウザ鍵アイコンでも基礎照合が可能——ただし Issuer と主体しか確認できず、OCSP と CT の詳細は見えません。
Chrome 照合手順
- アドレスバーの鍵アイコンをクリック
- 「Connection is secure」を選択
- 「Certificate is valid」を選択
- ポップアップで「Details」タブに切り替え
- Issuer Name と Subject Name を確認
Firefox 照合手順
- アドレスバーの鍵アイコンをクリック
- 「>」をクリック
- 「More Information」を選択
- 「View Certificate」をクリック
- 新規タブで完全な証明書詳細を確認
ブラウザ照合で確認できるフィールド
| フィールド | Chrome | Firefox | Safari |
|---|---|---|---|
| Issuer 名称 | 対応 | 対応 | 対応 |
| Subject O フィールド | 対応 | 対応 | 展開必要 |
| SHA-256 フィンガープリント | 対応 | 対応 | 対応 |
| OCSP ステータス | 非対応 | 部分対応 | 非対応 |
| CT ログ | 対応 | 対応 | 非対応 |
八、企業レベルの証明書ピニング方案
A：BiabaCoreは高額アカウントおよび企業レベルユーザーに対しデバイス上での証明書ピニング（Certificate Pinning）の有効化を推奨、内部プロキシ層でBinance証明書の SHA-256 フィンガープリントを強制検証します。
ピニング方案
- 企業プロキシ層（Squid、mitmproxy など）に既知有効フィンガープリントリストをロード
- フィンガープリントデータベースを構築、複数デバイスから定期的にクロス取得して比較
- フィンガープリント変化時は手動二次確認をトリガー
- 更新周期は30日ごとの照合に設定（詳細は /docs/binance-official-url-2026/ の再検証周期を参照）
デスクトップApp内蔵ピニング
Binance公式アプリ は2026年のデスクトップ版に証明書ピニングを内蔵しており、ユーザーによる手動設定は不要です。これは純粋なブラウザ利用ではなくデスクトップ端を選ぶもう一つのセキュリティ上の利点です。
九、アカウント紐付けと真偽連動
まだアカウントがない場合、先に 今すぐ登録 でKYCを完了させ、その後に証明書照合を学ぶことをお勧めします。既存アカウントを持つユーザーは、本記事をブックマークに追加し定期再検証の根拠とすることを推奨します。
リスク警告：SSL証明書チェーンは5次元のうちの1次元に過ぎず、証明書が通過してもドメイン指紋、ASN、インストールパッケージ署名、リダイレクトログ（/docs/binance-official-url-2026/ 参照）を照合する必要があります。BiabaCoreの内部基準は5次元すべて通過で放行です。
十、よくある質問
問：取得した証明書の Issuer が Let's Encrypt なら必ずフィッシングですか？
A：コアドメインであればフィッシングの可能性が高いです。binance.com / accounts.binance.com / api.binance.com が Let's Encrypt を使用するのは公式方針に反します。周辺サブドメインには例外があり得るため、ASN とドメイン指紋を組み合わせて二次確認が必要です。
問：Windows で openssl はどうインストールしますか？
A：https://slproweb.com/products/Win32OpenSSL.html から Win64 OpenSSL Light 版をダウンロードすればOK、インストール後は PowerShell や CMD で openssl.exe を直接呼び出せます。Git for Windows 同梱の openssl を使うことも可能です。
問：OCSP Stapling が無応答の場合、公式を誤検知しませんか？
A：ごく稀に公式でも負荷調整のため一時的に Stapling を停止することがあります、その際は独立 OCSP クエリ openssl ocsp -issuer ... -url http://ocsp.digicert.com で補えばOKです。
問：CTログに binance.com の証明書が多数あるのは正常ですか？
A：正常です。Binanceは複数のサブドメインで証明書を発行し、更新のたびにレコードが追加されます。crt.sh 上の履歴累計は通常数十から百以上です。異常なシグナルは「最新の1件が取得したものと不一致」または「取得したものがCTに一切見当たらない」です。
問：Binanceメインサイトの TLS バージョンは？
A：2026年時点でBinanceメインサイトは TLS 1.2 と TLS 1.3 のみ対応、TLS 1.0/1.1 は完全に廃止されています。暗号スイートは AEAD 系（AES-GCM または ChaCha20-Poly1305）、旧スイートを取得した場合は異常信号です。
問：一般ユーザーはアクセスのたびに証明書を照合すべきですか？
A：不要です。日常アクセスはブラウザ鍵アイコンを信頼すればOK、以下のシナリオでのみ能動的に照合すべきです：新規デバイス初回アクセス、フィッシング疑いあり、ネットワーク切替後（公共Wi-Fi接続など）、月次再検証。
問：証明書照合が通過したら永久に信頼できますか？
A：できません。証明書自体は更新され、CAは調整され、攻撃者は常に新戦略を試みます。BiabaCoreの内部基準は30日ごとの再検証です。関連する規範の詳細は /docs/binance-anti-phishing-real-fake/ および /docs/binance-app-download-2026-latest/ を参照。
ドキュメント公開日：2026-07-09、次回再検証予定：2026-10-09。