ディジタル証明書とは？ SSL/TLS・信頼の連鎖・失効までやさしく図解

公開: 2026年7月　カテゴリ: セキュリティ入門

HTTPSの🔒、期限切れの警告、自己署名の警告……「証明書」まわりは登場人物が多く、"誰が誰を保証するのか"が絡むので理解しづらい分野です。この記事では、ディジタル証明書の役割から、公開鍵と秘密鍵の使い分け、信頼の連鎖、有効期限、失効、自己署名の警告、HTTPS以外の用途までを、図解でひととおり整理します。手を動かすなら証明書チェーン検証の可視化と SSL/TLSの可視化も合わせてどうぞ。

ディジタル証明書とは — インターネット上の「身分証」

ディジタル証明書は、「このドメイン（サーバー）の持ち主は確かにこの人です」を第三者が保証する電子的な身分証です。Webで使うサーバー証明書には、対象のドメイン名・サーバーの公開鍵・有効期限・発行者などが記載され、認証局（CA：Certificate Authority）の署名が付いています。ブラウザはこの証明書を検証して、「本物のサーバーか」「盗聴されない鍵を安全に共有できるか」を確かめます。

公開鍵と秘密鍵 — 「暗号化」と「署名」で使い方が逆

証明書を理解する前提が、公開鍵暗号（非対称暗号）です。ペアになった「公開鍵（みんなに配る）」と「秘密鍵（自分だけが持つ）」を使い、片方でかけたものは、もう片方でしか開けません。ここで最大の混同ポイントが「どの場面で誰の鍵を使うか」です。

目的	かける側が使う鍵	開く／検証する側が使う鍵	守れるもの
暗号化（内容を秘密に）	受信者の公開鍵で暗号化	受信者の秘密鍵で復号	盗聴されない（機密性）
ディジタル署名（本物と証明）	送信者の秘密鍵で署名	送信者の公開鍵で検証	なりすまし・改ざん防止

覚え方は「暗号化は"相手"の公開鍵、署名は"自分"の秘密鍵」。証明書の「CAの署名」は、CAが自分の秘密鍵で署名し、検証する側はCAの公開鍵で確かめます。TLSで実際に鍵が受け渡される流れは SSL/TLSの可視化で1ステップずつ追えます。

信頼の連鎖（チェーン・オブ・トラスト）

「そのCAの署名は本物か？」は、どう確かめるのでしょうか。実は証明書は1枚では完結せず、サーバー証明書は中間CAが署名し、中間CAはルートCAが署名する連鎖になっています。ブラウザはこの署名を下からたどり、端末やブラウザに最初から組み込まれた「ルートCA」（＝信頼の起点）まで到達できれば、「正しく発行された本物」と判断します。

図1: サーバー証明書←中間CA←ルートCA。ルートCAは自己署名でも「信頼ストアにある」から信頼される

ここが最重要の混同ポイントです。ルートCAの証明書も“自己署名”ですが、信頼されるのはそれが端末の信頼ストアに登録済みだから。逆に、どこの信頼ストアにも無い証明書が自分で自分に署名しても（＝ただの自己署名証明書）、起点にたどり着けず信頼されません。「自己署名かどうか」ではなく「信頼ストアにあるかどうか」が信頼の分かれ目です。

証明書の中身と、ブラウザが確認する4つのこと

サーバー証明書には主に、発行先のドメイン名（SAN）・発行者・有効期限・サーバーの公開鍵・CAの署名が入っています。ブラウザは受け取った証明書について、次の4点を上から順に確認し、1つでも失敗した時点で中断して警告します。

チェック	内容	失敗時のChrome表示例
信頼の連鎖	署名をたどって信頼ストアのルートCAまで届くか	NET::ERR_CERT_AUTHORITY_INVALID
有効期限	現在日時が有効期間内か	NET::ERR_CERT_DATE_INVALID
ドメイン名(SAN)	証明書のSANとアクセス先のホスト名が一致するか	NET::ERR_CERT_COMMON_NAME_INVALID
失効の有無	CAが無効化(revoke)していないか	NET::ERR_CERT_REVOKED

この4つを実際に切り替えて「なぜ警告が出るか」を見られるのが証明書チェーン検証の可視化です。

ドメイン名は「SAN」で判定される（CNは使われない）

昔は証明書のコモンネーム(CN)でドメインを表しましたが、現在の主要ブラウザはCNを無視し、SAN（Subject Alternative Name）だけで一致を判定します。1枚の証明書に example.com と www.example.com のように複数ドメインを載せられるのもSANの働きです。アクセスしたホスト名がSANのどれとも一致しなければ、証明書が本物でも「別サイト用」として拒否されます。

CAは何を保証している？ — DV・OV・EV

認証局が確認する“厳しさ”には段階があり、証明書は3タイプに分かれます。いずれも暗号強度は同じで、違うのは「何を確認したか（＝どこまで信用の裏付けがあるか）」です。

種類	確認する内容	使われ方
DV（ドメイン認証）	そのドメインの管理権のみ	個人サイト・多くのサイト（Let's Encrypt等）
OV（組織認証）	ドメイン＋運営組織の実在	企業サイト
EV（拡張認証）	組織を最も厳格に審査	金融機関など（かつてのアドレスバー社名表示）

有効期限と自動更新

証明書には有効期限があり、切れると（連鎖や署名が正しくても）警告になります。無料CAのLet's Encrypt は有効期間が90日と短いため、自動更新して運用するのが前提です。「証明書の期限切れでサイトが見られない」という障害は、この自動更新が止まっているのが原因のことが多いです。近年はサーバー証明書全体の有効期間を短くする流れが進んでいます。

失効（revoke）— 期限前に無効化する仕組み

秘密鍵が漏れたなど「期限内でも信用できなくなった」場合、CAは証明書を失効(revoke)できます。ブラウザはその情報を次の方法で確認します。

図2: 失効の確認。CRL＝一覧をまとめて配布、OCSP＝1枚ずつ即問い合わせ。ステープリングで高速化

自己署名証明書はなぜ警告が出るのか

自己署名証明書は「自分で自分の身分証を発行」した状態で、第三者（信頼されたCA）の裏付けがありません。信頼の連鎖をたどっても信頼ストアの起点に届かないため、ブラウザは NET::ERR_CERT_AUTHORITY_INVALID を出します。社内・開発環境などで意図的に使う場合は、その証明書（またはローカル認証局）を端末の信頼ストアに手動で登録すれば、その端末では警告が消えます——これは前述の「信頼ストアにあるかどうかがすべて」の裏返しです。

証明書はHTTPS以外でも使われる

「証明書＝HTTPS」と思われがちですが、同じ公開鍵＋署名のしくみは、身元の証明・改ざん検出のためにさまざまな場面で使われています。

用途	何を証明するか
サーバー証明書（HTTPS）	Webサーバー（ドメイン）が本物であること
クライアント証明書（相互TLS）	接続してくる利用者・端末が正規であること
コードサイニング証明書	ソフトウェアの発行元と、改ざんされていないこと
S/MIME証明書	メールの送信者と、改ざんされていないこと
文書署名（PDF等）	文書の作成者と、内容が変更されていないこと

基本情報技術者試験ではこう出る

「ディジタル証明書を発行するのは（→認証局CA）」「ルート証明書の役割」「証明書が無効と判断される条件（期限切れ・ドメイン不一致・信頼の連鎖をたどれない）」が定番です。失効の確認方法（CRL・OCSP）、そして“暗号化は受信者の公開鍵で・署名は送信者の秘密鍵で”という鍵の対応関係は特に頻出かつ混同しやすいので、上の表で整理しておきましょう。

よくある質問

Q. 証明書があれば絶対に安全？
A. 証明書が保証するのは主に「通信相手のドメインが本物」「盗聴・改ざんされない」ことです。そのサイト自体が悪意を持っていないことは保証しません（フィッシングサイトも正規の証明書を取得できます）。🔒はあくまで「通信路の安全」の印です。

Q. 中間CAをはさむのはなぜ？
A. 最重要のルートCAの秘密鍵を厳重に守り、日常の発行は中間CAに任せるためです。万一中間CAに問題が起きても、その中間CAだけを失効させれば済み、ルートCAは守られます（被害の局所化）。

Q. 無料の証明書は安全性が低い？
A. いいえ。Let's Encrypt などの無料証明書も暗号強度は有料と同じで、確認レベルがDV（ドメイン認証）である点が違うだけです。多くのサイトで標準的に使われています。

まとめ

証明書は「ドメインの持ち主をCAが保証する電子的な身分証」。核心は信頼の連鎖（サーバー証明書←中間CA←ルートCA）と、ルートCAは"信頼ストアにあるから"信頼されるという点です。ブラウザは連鎖・期限・ドメイン(SAN)・失効の4点を順に確認し、1つでも欠ければ警告します。鍵は「暗号化は相手の公開鍵、署名は自分の秘密鍵」。ここを押さえれば、証明書まわりはぐっと見通せます。

🔎 動かして確かめる：証明書チェーン検証の可視化で「正常／期限切れ／ドメイン不一致／自己署名／失効」を切り替えて警告の理由を体感、SSL/TLSの可視化でハンドシェイクと「証明書のやり取りは毎回起きる？」を確認できます。