コンテンツにスキップ

電子署名・証明書・ルート証明書の仕組み(印鑑でたとえる)

最終確認: 2026-10-26
SWG(SSL/TLS検査)に戻る

30秒で復習

  • 電子署名=印鑑を押すこと。 秘密鍵で署名し、公開鍵で本物か確かめる。
  • 秘密鍵=実印(自分だけが持つ。人に渡さない)、公開鍵=印影の見本(誰に配ってもよい)。
  • 証明書=印鑑証明書。 「この公開鍵(印影)は、このサイト(この人)のものです」と認証局(CA)が署名して保証した書類。
  • 認証局(CA)=役所。 本人確認をして、証明書に署名する。
  • ルート証明書=役所そのものの信用の出発点。 OSやブラウザに最初から入っているので、そこから信頼をたどれる。
  • 中間CA=役所の出張所。ルートが直接署名せず、中間CAに任せて、大事な実印(ルートの秘密鍵)を金庫にしまっておく。
  • アクセスする側(ブラウザ)は、サーバーの証明書を受け取ったら、「署名をたどってルートに着くか・ドメイン名が合うか・期限内か・失効していないか」を確認し、さらに「本当に秘密鍵を持っているか」も確かめる。
  • HTTPS通信やSSL/TLS検査(SWG)、ZTNAなどの土台。

全体像:役所で印鑑証明書をもらうイメージ

役所(認証局=CA) 公印=ルート証明書 サーバー(あなた) 実印=秘密鍵を持つ ブラウザ(取引先) 役所の公印を知っている ① 印鑑証明書を発行 (証明書) ② 証明書を見せる +実印(秘密鍵)で署名 ③ 役所の公印を 確かめて信用
  • ① 役所(CA)が、本人確認をして印鑑証明書(証明書)を出す。
  • ② あなた(サーバー)が、印鑑証明書を見せて、実印(秘密鍵)で署名する。
  • ③ 取引先(ブラウザ)は、役所の公印を知っているので、証明書を信用できる。

質問:電子署名と証明書は、何をしているのか?

答え: 「この書類は本人が作り、途中で書き換えられていない」(署名)と、「その本人の鍵は確かにこの人のものだ」(証明書)を、第三者が保証する仕組み。

1. 電子署名=実印を押して、印影を照合する

送る人 受け取る人 書類 (契約書など) 秘密鍵で署名 =実印を押す 署名つき書類 (押印済み) 公開鍵で検証 =印影を照合 本人だけが持つ 誰に配ってもよい
印鑑の世界 デジタルの世界
実印 秘密鍵(本人だけが持つ)
印影の見本(登録された印影) 公開鍵(誰でも見られる)
書類に実印を押す 書類の内容から計算した値を秘密鍵で署名する
印影を見本と照合する 公開鍵で署名を検証する
  • 検証が通れば「秘密鍵を持つ本人が署名した」と「署名後に内容が書き換えられていない」の2つが分かる。

印鑑との違い

印鑑は同じ印影を何度も押せるが、電子署名は書類の中身ごとに違う値になる。1文字でも書き換えると検証が失敗するので、押印より改ざんに強い。

2. 証明書=印鑑証明書(誰の印影かを役所が保証する)

公開鍵だけを渡されても、「それが本当にその人のものか」は分からない。偽物の公開鍵を渡して、なりすますこともできる。そこで認証局(CA)が、公開鍵と持ち主の情報を一緒に署名する。これが証明書。

印鑑証明書に書いてあること 証明書に書いてあること
印影 公開鍵
氏名・住所 ドメイン名・組織名(例:example.com)
発行した役所の公印 CAの署名
有効期限 有効期限

3. 証明書ができるまで(役所に署名してもらう)

申請者(サイト運営者) ① 鍵のペアを作る 秘密鍵=実印は手元に保管 ⑤ 証明書を受け取り サーバーに設置 認証局(CA)=役所 ③ 本人(ドメイン)を確認 窓口で身元チェック ④ CAの秘密鍵で署名 役所の公印を押す ② 申請書(CSR)を送る 公開鍵+名前(秘密鍵は送らない) 証明書を発行 公開鍵+名前+CAの署名
  1. 申請者が鍵のペア(秘密鍵と公開鍵)を作る。秘密鍵は外に出さない
  2. CSR(証明書署名要求)に公開鍵と名前を書いてCAに送る(=印鑑登録の申請書)
  3. CAが申請者を確認する(例:そのドメインを本当に管理しているか)
  4. CAが自分の秘密鍵で署名して、証明書を作る
  5. 申請者は証明書をサーバーに設置し、アクセスした人に渡す

4. 信頼の連鎖とルート証明書

ブラウザは、証明書に署名したCAのことは知らなくてもよい。署名をたどって、最初から信用しているCAに着けばOKとする。

ルートCA(ルート証明書) 自分で自分に署名=役所そのもの 署名 中間CA(中間証明書) 役所の出張所。日常の署名はここがやる 署名 サーバー証明書 example.com の印鑑証明書 端末の信頼ストア ルートの一覧 ブラウザは 下から上へたどり、 金庫に入っている ルートに着けば信用
  • ルート証明書は、署名で保証されているのではなく、最初から端末に入っているから信用される。 信用の出発点。
  • 中間CAを挟むのは、ルートの秘密鍵(最も大事な実印)を普段は金庫(オフライン)にしまっておくため。
  • 途中の中間証明書が欠けると、たどれずにエラーになる。サーバーは中間証明書も一緒に渡すのが普通。
印鑑の世界 デジタルの世界
市区町村の役所 認証局(CA)
役所の公印そのもの ルート証明書
出張所・窓口 中間CA
印鑑登録の申請書 CSR
印鑑証明書 サーバー証明書
印鑑証明書の有効期限 証明書の有効期限(期限切れでエラー)
実印の紛失届 失効(秘密鍵が漏れたら証明書を無効にする)
自分で作った「私は本人です」という書類 自己署名証明書(誰も保証していない。検証用など)

アクセスする側は、サーバーの証明書をどう確認するのか?

ブラウザがHTTPSのサイトを開くとき、サーバーから証明書(と中間証明書)を受け取る。ここからの確認が、窓口で印鑑証明書を受け取って確かめる作業にあたる。

ブラウザ(確認する側) サーバー ① example.com につなぎたい ② 証明書(+中間証明書)を渡す ③ ブラウザが証明書を確認する ・署名をたどって、信頼ストアのルートに着くか ・証明書のドメイン名が、開いているサイトと一致するか ・有効期限内か ・失効していないか(失効情報を確認) どれか1つでも外れると、警告を出して接続を止める ④ 「本当に持ち主か」を確かめる(秘密鍵で署名させる) ⑤ 署名を返す → 証明書の公開鍵で検証OKなら、暗号化通信を開始

③ 証明書の確認(印鑑証明書を受け取って確かめる)

確認すること 印鑑証明書でいうと 外れたとき
署名をたどってルートに着くか。サーバー証明書の署名を中間CAの公開鍵で、中間証明書の署名をルートの公開鍵で検証する 公印が、本当にその役所のものか確かめる 信頼できないCAの証明書として警告
ドメイン名が一致するか(証明書のドメイン名と、開いているURL) 氏名・住所が、目の前の人と合っているか 別のサイトの証明書として警告
有効期限内か 発行から3か月以内かなどの期限 期限切れとして警告
失効していないか 紛失届が出ていないか役所に問い合わせる 失効済みとして警告(実際の確認方法は、OCSPやCRLなどCAの公開する失効情報)

④⑤ 証明書の持ち主かどうかの確認(本人かどうかの確認)

証明書は誰でも見られる書類なので、コピーを持ってきても、証明書だけでは本物の持ち主か分からない。印鑑証明書だけ持ってきても、実印がなければ契約できないのと同じ。

  • ブラウザは証明書の公開鍵で検証できる署名を、サーバーに求める
  • 正しい署名を作れるのは秘密鍵(実印)を持つサーバーだけ
  • 検証に成功してはじめて、「証明書どおりのサーバーだ」と分かる。そのあとで、通信を暗号化する鍵を安全に作る

鍵の置き場所が大事

証明書をコピーされても被害は小さいが、秘密鍵が漏れると、なりすましができてしまう。その場合は、証明書を失効させて作り直す。

警告が出る典型例

警告の原因 ありがちな場面
署名をたどれない(信頼できないCA) 自己署名証明書、社内CAのルートが端末に入っていない
中間証明書が足りない サーバーに中間証明書を設置し忘れた
ドメイン名が一致しない 別のドメイン用の証明書を使っている
期限切れ 更新を忘れた
失効している 秘密鍵が漏れて、CAが無効にした
端末の日付がずれている 期限の判定が狂う

自分の仕事とのつながり

  • SSL/TLS検査(SWG):通信の途中で復号するため、SWGが「にせの証明書」を作って返す。端末が警告を出さないよう、社内CAのルート証明書を端末に配っておく。
  • ZTNA・端末認証:端末のクライアント証明書で「会社が発行した端末か」を確認する使い方がある(印鑑証明書を端末が持つイメージ)。
  • Microsoft 365:メールの電子署名(S/MIME)でも同じ仕組みを使う。

確認したいこと

  • SSL/TLS検査で使うルート証明書を、どの方法で全端末に配布するか
  • 証明書の期限切れや失効を、どう監視するか