証明書は作ってもらうものではない。公開鍵に付けてもらう保証書だ

WindowsのWebサーバー（IIS）で証明書を1枚作り、HTTPSに割り当てました。サーバー名は web.ad.local です。同じサーバー、同じ証明書にブラウザーからアクセスしただけなのに、結果は3通りに分かれました。

サーバー自身から https://web.ad.local を開く → 鍵のマークが付いて、問題なくつながる
サーバー自身から https://localhost を開く → 「この接続ではプライバシーが保護されません」
隣のサーバーから https://web.ad.local を開く → 同じ警告。ただし理由は2つ目とは別

証明書は壊れていません。変わったのは、どの名前で呼んだかと、どのマシンが確かめたかだけです。この違いが説明できるかどうかが、証明書を「分かっている」かどうかの分かれ目になります。

証明書については「どこかに頼んで作ってもらい、受け取って入れるもの」だと思われがちです。一部はそのとおりですが、その理解のままだと、上のような結果の違いを説明できません。この記事では、証明書が何を保証するために存在するのかを、公開鍵暗号から順に組み立て直します。最後に、証明書のエラーを見たときにどこから確かめるかを判断の順番としてまとめます。

鍵は必ずペアで生まれ、秘密鍵は使う場所から出さない

出発点は公開鍵暗号です。数学的に結び付いた2つの鍵を、必ずペアで作ります。片方だけを作ることはできません。

公開鍵: 誰に渡してもよい鍵。途中で盗み見られても構わない
秘密鍵: 自分だけが持つ鍵。外へ出した時点で全部が台無しになる

この鍵のペアで作れるのは、「公開鍵は誰に配ってもよいのに、秘密鍵を持つ人にしかできないことがある」という状態です。その使い方は1つではなく、暗号化、デジタル署名、鍵交換など、方式ごとに役割が分かれています。「公開鍵は暗号化する鍵」と決まっているわけではありません。

ここでは、いちばんイメージしやすい暗号化から見ていきます。受け取る人の公開鍵で暗号化したデータは、対応する秘密鍵を持つ人だけが復号できるように作られています。だから、受け取りたい人は公開鍵を配っておき、送る人はその公開鍵で暗号化して送ります。途中で誰かが通信を丸ごと見ていても、秘密鍵を持っていない限り中身は読めません。この使い方は今も現役で、暗号化メール（S/MIMEやOpenPGP）では、本文を暗号化した共通鍵を受信者の公開鍵で暗号化して一緒に送り、受信者は自分の秘密鍵でその共通鍵を取り出してから本文を読みます。

ここから、証明書の話を通して守るべき原則が1つ出てきます。鍵のペアは、それを使う場所で作る。 Webサーバーで使うならWebサーバーの中で作り、秘密鍵はそのサーバーから出さない。技術的には認証局の側で鍵を作ることも、秘密鍵をエクスポートして別のサーバーへ移すこともできますが、秘密鍵が移動するたびに漏れる機会が増えます。証明書で困ったら、まず「秘密鍵は今どこにあるのか」を確かめてください。多くの混乱がそこでほどけます。

鍵を配って暗号化する流れは、理論編の動画の5分あたりから（無料）アニメーションで見られます。誰がどの鍵を持っていて、盗み見ている人の手元に何が残るのかを、登場人物の動きで追えます。

公開鍵暗号は「偽物の公開鍵」を渡されると破られる

この仕組みには弱点があります。通信する2人の間に攻撃者が入り込み、最初の公開鍵の受け渡しから偽物にすり替えることです。中間者攻撃（Man-in-the-Middle）と呼ばれます。

攻撃者は自分で鍵のペアを作り、その公開鍵を「相手の公開鍵です」という顔で渡します。送る側は偽の公開鍵で暗号化し、攻撃者は自分の秘密鍵でそれを読みます。読んだあとで内容を書き換え、今度は本物の公開鍵で暗号化し直して本物の相手へ届けることもできます。両端の2人はどちらも、相手と直接話していると思い込んだままです。

暗号の強さは関係ありません。問題は、受け取った公開鍵が本当に通信したい相手のものかを確かめる手段がないことです。すり替えが起きる様子は同じ動画の13分30秒あたりから図で追えます。

デジタル署名は「誰が作ったか」を確かめる道具で、暗号化ではない

「誰が作ったものか」をデジタルで確かめる手段がデジタル署名です。同じ鍵のペアの、暗号化とは別の使い方です。

署名を作るときは、秘密鍵を使う
署名を確かめるときは、公開鍵を使う

秘密鍵を持っているのは本人だけなので、公開鍵で確かめて正しいと判定される署名が付いていれば、対応する秘密鍵を持つ本人が作ったと言えます。実際にはメッセージ全体ではなく、メッセージから計算したハッシュ値に署名します。ハッシュ値は元のデータが1文字でも変われば大きく変わるので、署名の確認に成功すれば「本人が作った」ことに加えて「途中で書き換えられていない」ことも分かります。

注意が2つあります。1つは、署名は暗号化ではないことです。署名を付けても中身は読めるままで、隠したいなら別に暗号化が要ります。もう1つは、「秘密鍵で暗号化したものを公開鍵で戻すのが署名」という説明をよく見かけますが、これはRSAという方式でだけ成り立つたとえで、署名の方式全般には当てはまりません。「秘密鍵で作り、公開鍵で確かめる」と覚えておけば十分です。

ハッシュ値に署名して確かめる流れは、動画の23分50秒あたりで1ステップずつ動きます。

署名があっても、確かめる鍵が偽物なら意味がない

では、署名を使えば中間者攻撃は防げるのでしょうか。防げません。 署名を確かめるには相手の公開鍵が要ります。その公開鍵を最初の段階で偽物にすり替えられていたら、攻撃者の署名を攻撃者の公開鍵で確かめて「成功」と判定してしまいます。

偽物の公開鍵を本物だと信じた時点で、その先の仕組みがどれだけ正しく動いても負けです。必要なのは、この公開鍵はこの人のものだということを、公開鍵の外から保証してくれる存在です。

証明書は、公開鍵に第三者の署名を付けた保証書

その保証をするのが認証局（CA）です。そして、認証局が保証した結果が証明書です。

流れはこうなります。

自分のサーバーで鍵のペアを作る（秘密鍵はここから出さない）
公開鍵と「自分は誰か（どの名前で使うか）」を認証局に送る。これが証明書署名要求（CSR）
認証局は申請者が本物かを確かめ、公開鍵と名前をまとめたものに認証局の秘密鍵で署名して返す
返ってきた証明書を、手元の秘密鍵と組み合わせて使う

冒頭の「作ってもらうもの」という理解がずれているのは、ここです。認証局が作っているのは鍵ではなく署名です。 鍵のペアはこちらで作り、公開鍵に「この公開鍵はこの名前の持ち主のものだ」というお墨付きを付けてもらう。証明書とは、その公開鍵と名前の対応関係に対する保証書です。

受け取る側は、証明書に付いた署名を認証局の公開鍵で確かめます。攻撃者は偽の公開鍵入りの証明書を作れますが、認証局の秘密鍵を持っていないので、本物の認証局の署名は作れません。自分で作った偽の認証局の署名しか付けられず、受け取る側は「自分が信頼している認証局の署名ではない」と気づけます。偽の証明書が弾かれる場面は、動画の32分30秒あたりから図で確かめられます。

信頼は解決されたのではなく、認証局へ先送りされている

ここで一歩引いて見ると、問題が消えたわけではないことに気づきます。「受け取った公開鍵を信じてよいか」という問いが、「その認証局を信じてよいか」に置き換わっただけです。認証局の秘密鍵が盗まれれば、あるいは偽の認証局を「信頼する」側に入れてしまえば、同じ攻撃が通ります。

この先送りを止める仕組みが2つあります。

認証局の階層: 証明書に署名した認証局（中間CA）の証明書にも、さらに上の認証局の署名が付いています。たどっていった一番上がルートCAで、ルートCAの証明書だけは自分で自分に署名しています
信頼の起点の一覧: どのルートCAを信じるかは、OSやブラウザーが最初から持っている一覧で決まります。Windowsなら証明書ストアの「信頼されたルート証明機関」です

つまり、HTTPSでエラーが出ずにつながるのは、サーバーの証明書から署名をたどっていくと、手元の一覧にあるルートCAにたどり着けたからです。証明書の信頼性は証明書の中身ではなく、確かめる側が何を信頼しているかで決まります。

だから、信頼の一覧に何を入れるかは重大な判断です。自分で作って自分で署名した証明書（いわゆるオレオレ証明書）を、エラーを消すために「信頼されたルート証明機関」へ入れる操作は、検証環境ではよく行われます。けれども仕組みから見れば、それはそのマシンにとっての信頼の起点を1つ増やす操作です。自作の認証局のルート証明書を入れた場合はなおさらで、その認証局の秘密鍵を持つ人は、そのマシンに対してどんな名前の証明書でも正当なものとして発行できるようになります。入れたなら、検証が終わったら外す。組織で使うなら、社内の認証局を立ててルート証明書をグループポリシーで配る。軽く扱ってよい操作ではありません。

証明書に書いてあるのは、公開鍵と名前だけではない

証明書には、公開鍵と署名のほかにも、確かめる側が照らし合わせる項目が入っています。

名前: どの名前のサーバーで使ってよいか。今のブラウザーは**サブジェクト代替名（SAN）**の一覧を見ます。古い説明にある「発行先（Common Name）に名前が入っていればよい」は、現在のブラウザーでは通りません
用途: サーバー認証用か、クライアント認証用か、署名用か。鍵の使い方（キー使用法）も含めて、用途に合わない証明書は拒否されます
有効期限: 期間の外なら無効です
失効: 期限内でも、秘密鍵の漏洩やサーバーの廃止で失効させられます。確かめる側は証明書失効リスト（CRL）などで、失効していないかを確認します

冒頭の3つの結果を説明する

ここまでで、冒頭の結果が説明できます。IISで作った証明書は自己署名です。発行者も発行先も web.ad.local 自身で、証明のパスは1段しかありません。

サーバー自身から web.ad.local: IISは自己署名の証明書を作るとき、そのサーバーの「信頼されたルート証明機関」にも入れます。信頼の起点にたどり着け、名前もSANと一致するので通ります
サーバー自身から localhost: 信頼の起点にはたどり着けますが、証明書のSANには web.ad.local しか入っていません。同じIPアドレスに届いていても、呼んだ名前が証明書の名前と違うので警告が出ます
隣のサーバーから web.ad.local: 名前は合っています。しかし隣のサーバーの「信頼されたルート証明機関」には、この自己署名の証明書が入っていません。信頼の起点にたどり着けないので警告が出ます

名前が違うのか、信頼の起点が違うのか。警告の画面は似ていても、原因は別物です。IISの画面でSANと証明のパスを確かめる場面はIIS編の動画の7分あたり（無料）、localhost でエラーになる理由を証明書の中身から読み解く場面は11分あたり、隣のサーバーで警告が出てから証明書をルートへ入れて消えるまでは12分40秒あたりからで見られます。証明書のどの欄を見ればよいかは、画面で一度追うと覚えやすくなります。

なお、この手軽な自己署名の証明書は、2024年の時点で最新のChromeとEdgeでは、警告を承知で進もうとしても ERR_SSL_KEY_USAGE_INCOMPATIBLE で表示できなくなっていました。ブラウザーが鍵の用途をより厳しく確かめるようになったためです。その実際の画面はAD CS編の動画の3分あたり（無料）で見られます。

証明書のエラーを見たら、確かめる順番

ブラウザーのエラー表示に出るコードは、上で見た「確かめる項目」のどれで落ちたかを教えてくれます。Chrome・Edgeの代表的なものを、確かめる順に並べます。

確かめること	落ちたときの主なコード	まず見る場所
信頼しているルートCAまで署名をたどれるか	`ERR_CERT_AUTHORITY_INVALID`	証明のパス。途中の中間CA証明書がサーバーから送られているか、ルートがクライアントの信頼の一覧にあるか
呼んだ名前が証明書に書かれているか	`ERR_CERT_COMMON_NAME_INVALID`	証明書のSAN。アクセスに使ったURLのホスト名が入っているか
用途が合っているか	`ERR_SSL_KEY_USAGE_INCOMPATIBLE`	キー使用法・拡張キー使用法。サーバー認証用のテンプレートで発行されたか
期限内か	`ERR_CERT_DATE_INVALID`	有効期限と、クライアント側の時計
失効していないか	`ERR_CERT_REVOKED`	認証局の失効情報。失効させた覚えがあるか

判断の基準は1つです。証明書そのものより先に、確かめる側から見て何が足りないのかを考える。 同じ証明書が、あるマシンでは通り、別のマシンでは通らない。これは故障ではなく、信頼の一覧と呼んだ名前が違うという、仕組みどおりの結果です。

ADの認証局で発行し直してもなお ERR_CERT_COMMON_NAME_INVALID が出て、SANを入れるために認証局側の設定から直していく実例は、AD CS編の42分30秒あたりからで見られます。正しく動いている公開サイトの証明書を開き、「サブジェクトの別名」と見比べる場面（44分40秒あたり）は、自分の環境で調べるときの手本になります。

補足: 通信そのものを暗号化しているのは証明書の鍵ではない

冒頭の暗号化の例だけを見ると、HTTPSの通信は全部公開鍵で暗号化されているように思えます。実際は違います。公開鍵暗号は計算が重いので、通信の本体は、両者が同じ鍵を使う共通鍵暗号で暗号化します。

現在主流のTLS 1.3では、その共通鍵は通信のたびに鍵交換の手順で両者が合意して作ります。サーバーの証明書と秘密鍵が担うのは、その手順の中で「自分は証明書に書かれた名前の、本物のサーバーだ」と署名で示すことです。証明書は暗号化の道具というより、相手が本物かを確かめる道具だと捉えるほうが実態に合っています。

期限はこれからどんどん短くなる

最後に、運用に直結する現況です。インターネットで信頼される公開のTLS証明書は、ブラウザーと認証局の業界団体（CA/Browser Forum）の決定で、最大有効期間が段階的に短くなっています。

適用開始	最大有効期間
2026年3月15日	200日
2027年3月15日	100日
2029年3月15日	47日

2026年9月の今、新しく発行される公開証明書は最長でも200日です。来年には100日になります。年1回の更新はすでに成り立たず、47日になれば手作業では回りません。更新を自動化する前提で設計しておく必要があります。

まとめ

証明書は「作ってもらうもの」ではない。鍵は自分で作り、公開鍵と名前の対応に認証局の署名をもらう
公開鍵暗号も署名も、偽の公開鍵を信じた時点で破られる。証明書はそれを防ぐための保証書
信頼は解決されたのではなく、ルートCAへ先送りされている。何を「信頼されたルート証明機関」に入れるかは重大な判断
エラーは「信頼の起点・名前・用途・期限・失効」のどれで落ちたかで読む。確かめる側から見て何が足りないかを先に考える
公開証明書の期限は短くなり続ける。更新は自動化が前提