ルート証明書の確認について違和感があるので教えてください。

こんにちは、yolo176さん、

ブラウザで見た証明書が「DigiCert」なのに、tcpdumpでSectigo（旧Comodo）系のドメイン（://usertrust.comなど）への通信が発生する理由は、Webサイト自体の証明書ではなく、あなたのデバイス（OSやブラウザ）が内蔵している別の「ルート証明書」や「中間証明書」の有効性を確認（OCSP問い合わせ）しているためです。

これは正常な動作であり、偽装サイトへの誘導やサイバー攻撃ではありません。仕組みの詳細は以下の通りです。

1. なぜ無関係に見えるドメインへ通信するのか？

HTTPS通信を行うとき、ブラウザはWebサイトの証明書（DigiCert）だけではなく、その証明書を保証している「ルート証明書」が今も安全であるか（失効していないか）をリアルタイムに確認します。この仕組みをOCSP（Online Certificate Status Protocol）と呼びます。

• Appleサポートコミュニティの証明書：DigiCertが発行
• 通信先（://usertrust.com）：Sectigo（旧Comodo）が管理する証明書失効確認サーバー

一見無関係ですが、DigiCertの証明書を検証するプロセスのどこかで、Sectigo社が認証しているルート証明書や中間証明書のチェックがバックグラウンドで走ったためにこのDNSクエリが発生しています。

2. CNAMEでCloudflareのドメインが出る理由

://usertrust.comにアクセスした際、すぐにocsp.comodoca.com.cdn.cloudflare.netのCNAME（別名）が返ってきたのは、Sectigo社が自社のOCSPサーバー（失効確認サーバー）の負荷分散と高速化のために、CDN（Content Delivery Network）としてCloudflareを採用しているからです。

世界中からの膨大な数の「証明書チェック」をさばくため、Sectigo社はCloudflareのネットワークを使って応答をキャッシュしています。そのため、DNSを引くとCloudflareのドメインを経由してAレコード（IPアドレス）に starving することになります。

まとめ

• Webサイトの証明書（DigiCert）
• OS/ブラウザが裏で行うルート証明書の有効性確認（Sectigo / USERTRUST）
• その確認サーバーを世界中に高速配信する仕組み（Cloudflare

こんにちは、 yolo176さん、

結論から言うと、Appleサポートコミュニティの「SSL/TLS証明書（DigiCert製）」と、あなたのブラウザが裏で通信した「OCSPサーバー（Sectigo/旧Comodo製）」は、全く別の役割を持つ独立したシステムだからです。

これはサイバー攻撃や異常ではなく、インターネットの暗号通信が正常に行われるための一般的な仕組み（クロスルート設定や外部サービスの検証）によるものです。

なぜこのような一見無関係なドメインが出現するのか、3つのステップで分かりやすく解説します。

1. AppleはDigiCert、OCSPはComodo（Sectigo）な理由

ブラウザで確認した「DigiCert」は、AppleサポートコミュニティというWebサイトの身元を証明する証明書です。

一方、usertrust.com や comodoca.com は、認証局大手の Sectigo（旧Comodo）社 が管理するドメインです。AppleがDigiCertを使っているのに、なぜComodoのサーバーへパケットが飛ぶのかというと、以下の2つの可能性が考えられます。

• 中間・ルート証明書の有効性確認（クロスルート証明書）
• Appleの証明書（DigiCert）をあなたのPCやスマホが検証する際、その証明書の信頼性をたどるルート（信頼のチェーン）の途中に、Sectigo/Comodoのルート証明書（USERTrustなど）が「クロスサイン（相互認証）」の形で関わっている場合があります。そのため、お使いの端末が自動的にSectigo側のサーバーに「このルートは失効していませんか？」と問い合わせにいった可能性があります。
• Webサイトに含まれる「外部コンテンツ」の読み込み
• Appleサポートコミュニティのページ内に、Sectigo（Comodo）製の証明書を使っている外部のCDN、JavaScript、フォント、あるいは画像などが埋め込まれており、Webページを開いた瞬間にブラウザがその別サイトの証明書を検証（OCSP）しに行ったケースです。

2. 「ocsp.」というドメインが示す意味

://usertrust.com というドメインの頭にある「ocsp」は、OCSP（Online Certificate Status Protocol） というプロトコルを指しています。

これは、ブラウザが「今からアクセスするサイトの証明書が、期限内であっても犯罪などに悪用されて途中で失効（キャンセル）されていないか」を、認証局のサーバーにリアルタイムで問い合わせる仕組みです。

tcpdump でこのドメインが見えたということは、あなたのブラウザが「Sectigo（Comodo）系列の証明書」を安全に検証するために、バックグラウンドで正しく仕事をした証拠です。

3. なぜCloudflareのCNAMEやAレコードが出るのか

://usertrust.com を見に行ったら、すぐに ocsp.comodoca.com.cdn.cloudflare.net という Cloudflare（クラウドフレア）のドメインに転送（CNAME）された理由について説明します。

• 認証局もCDN（Cloudflare）を使って負荷分散している
• 世界中の数億台の端末から「この証明書は有効か？」というOCSPの問い合わせが秒間無数に届くため、認証局（Sectigo/Comodo）の自社サーバーだけではパンクしてしまいます。
• そこでSectigo社は、世界最大手のネットワーク配信代行業者（CDN）である Cloudflare と契約し、問い合わせ処理を肩代わり（キャッシュ）してもらっています。
• そのため、DNS（Aレコード）を解決すると「SectigoがCloudflareのネットワーク上に配置しているOCSPサーバーのIPアドレス」が返ってくるようになっています。

まとめ

1. AppleのWebサイト自体は「DigiCert」の証明書を使っている。
2. しかし、ページ内の外部要素や、証明書の検証ルート（クロスサイン）の関係で、Sectigo（Comodo）の証明書も同時に検証された。

1. その検証のために、ブラウザが自動的に失効確認サーバー（ocsp.usertrust.com）へ通信した。
2. その失効確認サーバーは、負荷を分散するために Cloudflare（cdn.cloudflare.net） のネットワーク上で運用されていた。

インターネットの安全性を守るための「証明書の裏方チェック」が、tcpdump を使ったことで綺麗に可視化された状態です。セキュリティ上の問題は一切ありませんのでご安心ください。

root証明書とそれに基づくバリデーションチェーンの証明書と混乱されてませんか？

例えば、Digicertはroot証明書ですが、ocspとか他のものはDigicertなど他のroot証明書から派生された証明書です。派生された証明書はそのサーバの管理者がDigicertなどのroot証明書発行機関に依頼して作成するもの（root証明書の発行機関の秘密鍵で暗号化された証明書）でroot証明書ではありません。

macOSの同梱されてるroot証明書は以下のサポート記事に書いてます。

Appleオペレーティングシステムで利用できるルート証明書 - Apple サポート (日本)

このサポート記事のTahoeのリンクを開ければ、Tahoeに同梱されてるroot証明書を見ることができます。

なお、証明書は改竄されないように細心の注意で管理されてます。それでも改竄された場合には直ちにその証明書は直ちに無効になり、新しい証明書が発行されます。そしてそれはソフトウェアアップデートなどでエンドユーザに配布されてます。改竄されなくても一定の期間後には更新されてます。なので、決して性善説に基づいた運用がされてるわけではありません。詐欺と欺瞞に満ちたインターネットの世界に性善説など通用しないのは明らかです。

管理者が必要なら、自組織用のroot証明書を発行してmacOSに取り込むこともできます。大学などちょっと大きくて自分たちでroot証明書の維持管理ができるだけのリソースがある組織だと既存のroot証明書を使う経費と比較検討した上で自組織で発行したりしてます。

SSL証明書の認証に関する通信先とocsp情報を得る仕組みは別なので複数の相手になっていても不思議ではないと思います。

こんにちは、

ルート証明書は「通信相手の身元を保証する究極のマスターキー」であり、それがPCやスマホにあらかじめ多数インストールされていることに違和感を覚えるのは非常に鋭い視点です。

具体的にどのような点に違和感を持たれたかによって理由は異なりますが、主に以下の3つの理由が考えられます。

1. なぜ「見知らぬ海外の企業」を信頼するのか

ブラウザには最初から、聞いたこともない外国の認証局（例：GlobalSign、DigiCert、Sectigoなど）のルート証明書が何十枚も入っています。

• 理由： インターネット黎明期から世界中で共通のセキュリティ基準を構築してきた歴史的経緯があるためです。OS（WindowsやiOSなど）やブラウザの開発元が、厳格な国際監査をクリアした認証局を「安全なもの」としてあらかじめリストに組み込んでいます。

2. なぜこんなにたくさん（大量）の証明書が必要なのか

「自分で使うサイトはごく一部なのに、なぜ数百個ものルート証明書が最初から入っているのか」という疑問です。

• 理由： あなたが普段アクセスする可能性のある世界中のあらゆるWebサイト（銀行、ショッピング、行政など）で、使用しているサーバー証明書の発行元（中間認証局）が異なるためです。そのすべてに対応できるように、信頼できるルート証明書のパッケージがOSに丸ごと同梱されています。

3. セキュリティの仕組み上の「構造的な矛盾」

「そもそも、身元不明な相手との安全な通信を担保するための仕組みなのに、端末に最初から入っている証明書が本当に安全だとなぜ言い切れるのか」という根本的な違和感です。

• 理由： まさにその通りで、ルート証明書は「絶対に改ざんされない」という前提の性善説に基づいた絶対的なマスターキーです。過去には、パソコンのメーカー（LenovoのSuperfish事件など）が悪意のあるルート証明書を勝手に追加してしまい、通信の暗号化が骨抜きにされる事件もありました。

まとめ：

あなたが抱いた違和感は、「見ず知らずの他者（認証局）のハンコ（証明書）を、なぜ自分の端末が無条件で信頼する設定になっているのか」 というセキュリティの本質を突くものです。

一方で、これは現在のインターネット社会（TLS/SSL通信）において、世界中の通信を破綻なく成立させるために「あえて全員で特定の認証局を信用する」という妥協の上に成り立っている仕組みでもあります。

もし「特定の証明書が見当たらない」などの具体的なエラーや、「どの証明書を信用すべきか分からない」といった確認作業での違和感であれば、さらに詳細な状況をお知らせください。