4-1 封筒と身分証（HTTPS と証明書）
はがきで書いた用件は、配達の途中で誰にでも読めます。封をした封筒なら、途中で読まれず、書き換えられてもすぐ分かります。
いま読んでいるこのサイト（Cloudflare Lab）も、お客さん（利用者）とのやり取りを封筒で行います。ただ、その封筒をやり取りしている相手が本物の窓口かどうかは、封だけでは分かりません。そこで身分証が要ります。
ここでは、封筒、身分証、発行所、期限と確かめ方、二つの区間の順に見ます。
Learning goals
この節でできるようになること
- HTTPS が何を守るかを封筒で説明できる
- 証明書と CA の関係を身分証と発行所で説明できる
- 身分証の期限と、発行所をたどる道を説明できる
- お客さん↔窓口と窓口↔本社で身分証が別だと説明できる
1. 封をした封筒（HTTPS）
Section titled “1. 封をした封筒（HTTPS）”はがきは誰でも読めますが、封筒に入れて封をすれば、開けた跡が残ります。相手にだけ読ませたい手紙は封筒で送ります。
Web では、封をしたやり取りを HTTPS と呼びます。Cloudflare の公式は、SSL/TLS で Web の通信を暗号化し、データの盗み見や改ざんを防ぐと説明しています。
実物では、ブラウザの URL が https:// で始まり、鍵のマークが出ます。Cloudflare Lab の仮の住所 https://cloudflare-lab.osdse.workers.dev も、第 2 章の実測で HTTPS で返っていました。
左のはがきは途中で読めますが、右の封筒は読めず、開ければ跡が残ります。HTTPS は右の封筒です。
つまり、HTTPS は「読まれない・書き換えられない」を封筒で実現する仕組みです。
2. 身分証と発行所（証明書と CA）
Section titled “2. 身分証と発行所（証明書と CA）”封筒を受け取った相手が、本当にその店の窓口かは別の問題です。窓口は身分証を見せ、お客さんはそれを確かめます。
Cloudflare では、この身分証を 証明書（certificate） と呼びます。身分証を発行するのが Certificate Authority（CA＝発行所） で、公式は「信頼された第三者が SSL/TLS 証明書を生成して配る」と説明しています。
実物では、ブラウザや OS が信頼する発行所の一覧（trust store）を持っています。その一覧にある発行所の身分証だけを、ブラウザは本物として扱います。
窓口の身分証には、店名（ドメイン）と発行所の印があります。お客さんは発行所の印を、自分が持つ一覧と照らします。
つまり、証明書は「この窓口はこの店名の本物です」を第三者が保証する身分証です。
3. 身分証の期限と、発行所をたどる道（chain of trust）
Section titled “3. 身分証の期限と、発行所をたどる道（chain of trust）”身分証には期限があります。期限切れの身分証を見せられたら、お客さんは不安になります。
公式は、すべての SSL/TLS 証明書には決まった有効期限（validity period）があり、切れるとブラウザが警告を出すと書いています。さらに、身分証から発行所、その上の発行所へとたどって元締めまで確かめる道を chain of trust（信頼の連鎖） と呼びます。
実物では、確認の深さにも種類があります。Cloudflare が既定で発行するのは Domain Validated（DV）＝「店名の持ち主である」ことを確認した身分証です。会社の実在まで確認する OV や EV もあります。
身分証の印から発行所へ、発行所から元締めへと線がつながっています。途中が切れていれば、その身分証は信じられません。
つまり、身分証は期限内で、発行所の道がつながっているときだけ有効です。
4. 二つの区間の身分証（edge certificate と origin certificate）
Section titled “4. 二つの区間の身分証（edge certificate と origin certificate）”お客さんと窓口の間と、窓口と本社の間は、別の区間です。それぞれに封と身分証があります。
Cloudflare では、お客さんと Cloudflare の間の身分証を edge certificate、Cloudflare と本社（origin server）の間の身分証を origin certificate と呼びます。公式は、edge certificate は Cloudflare が用意してダッシュボードで管理し、origin certificate は本社側で管理すると説明しています。
実物では、Cloudflare Lab は Built on Cloudflare（第 1 章）なので本社が Cloudflare 自身です。だから窓口と本社の区間そのものがなく、edge certificate だけを考えれば済みます。
edge certificate（お客さん ↔ 窓口）
origin certificate（窓口 ↔ 本社）
左の区間はお客さんと窓口、右の区間は窓口と本社です。Cloudflare Lab には右の区間がありません。
つまり、身分証は区間ごとに分けて考えます。
Cloudflare Lab での使われ方
Section titled “Cloudflare Lab での使われ方”ここで紹介した封筒と身分証が、いま読んでいる Cloudflare Lab でどう使われているかを見ます。
Cloudflare Lab は Built on Cloudflare なので、身分証は edge certificate だけです。第 3 章で clf.cloud-labos.com の看板（Custom Domain）を掛けた 2026-08-27 に、その店名の身分証が自動で発行されました。作者は発行所へ申請していません。身分証の中身（発行所・期限・対象の名前）は、次の 4-2 に実物を載せています。
封をした手紙と、封をしていない手紙の両方を出してみると、どちらも返事が来ました（2026-08-27 実測）。
- https で出した手紙
- HTTP/2 200
- http で出した手紙
- HTTP/1.1 200 OK
封あり
封なしでも入れてしまう
封をしていない手紙を、封筒で出し直してもらう設定（Always Use HTTPS）を、まだ入れていないためです。いまは封をしていない手紙でも受け付けてしまいます。この穴は 4-4 で塞ぎます。
つまずきやすいところ
Section titled “つまずきやすいところ”この節のまとめ
Section titled “この節のまとめ”- HTTPS は封をした封筒で、読まれず書き換えられないやり取りです。
- 証明書は窓口の身分証、CA はその発行所で、期限と信頼の連鎖があります。
- 身分証はお客さん↔窓口と窓口↔本社で別で、Cloudflare Lab は前者だけです。
この節で出てきた言葉を、つながりの順に並べると次のようになります。
図のラベル: 封をした封筒 HTTPS / 窓口の身分証 certificate / 発行所 Certificate Authority / 期限と信頼の連鎖 validity・chain of trust / お客さん↔窓口 edge certificate / 窓口↔本社 origin certificate
次の節では、その身分証が無料で自動的に発行される仕組みを見ます。
この節のチェック
© 2026 osdse