Cloudflare 03：SSL/TLS ― 2つの区間を暗号化する

Cloudflare を挟むと、暗号の区間は2つになる

Cloudflare を使うときに、いちばん大事な考え方がこれです。Cloudflare はリバースプロキシなので、通信はいったん Cloudflare の拠点で終わり、拠点からオリジンへ新しくつなぎ直します。暗号の区間は2つに分かれます。

ブラウザの鍵マークは、区間1だけを表しています。ブラウザからは、区間2がどうなっているかは見えません。区間2が平文でも、鍵マークは出ます。

だから、Cloudflare の SSL/TLS の設定は、この2つを別々に固めていく作業になります。区間1は Cloudflare がほぼ自動でやってくれます。区間2は、あなたのオリジンの準備が必要です。ここを取り違えると、「鍵マークは出ているのに、実は安全ではない」状態になります。

拠点で一度暗号がほどけることに不安を感じるかもしれません。これはリバースプロキシの仕組み上避けられないことで、だからこそキャッシュや WAF が中身を見て働けます。企業向けには、秘密鍵を Cloudflare に預けない仕組みなども用意されています。

区間1：Universal SSL が証明書を自動で出す

区間1の証明書は、Universal SSL という仕組みで自動的に用意されます。ドメインを Cloudflare に追加し、DNS がオレンジの雲（01号）になっていれば、数分から長くても1日程度で証明書が発行されます。

昔は、証明書を買い、サーバーに入れ、期限が切れる前に更新するのが大仕事でした。更新を忘れてサイトが見られなくなる事故もよくありました。Universal SSL では、この作業がまるごと無くなります。

注意点は対象の範囲です。ワイルドカード *.example.com は、1段だけを対象にします。api.example.com は対象ですが、v2.api.example.com のような2段のサブドメインは対象外で、ブラウザに証明書のエラーが出ます。2段以上が必要なら、有料の Advanced Certificate Manager で証明書を作るか、名前を1段に収めます（v2-api.example.com のように）。

証明書の状態は、管理画面の SSL/TLS → Edge Certificates で確かめられます。

区間2の暗号化モードは4つ

区間2で Cloudflare がオリジンにどうつなぐかは、暗号化モードで決まります。管理画面の SSL/TLS → Overview で選びます。

下に行くほど安全です。目指すのは Full (strict) です。これ以外のモードは、どこかに穴があります。

以前は、ドメインを追加したときの既定が Flexible になることがあり、多くのサイトが知らないうちに区間2を平文で流していました。Cloudflare は2024年から Automatic SSL/TLS という設定を広げています。これは、Cloudflare がオリジンを調べて、そのオリジンが対応できるいちばん安全なモードを自動で選ぶものです。オリジンが正しい証明書を持っていれば Full (strict) に上げ、持っていなければ下げずに今のモードのままにします。

次のページから、Flexible・Full・Full (strict) がそれぞれ何を意味するのかを見ていきます。

Flexible：後ろ半分は暗号化されていない

Flexible は、区間1だけを HTTPS にし、区間2は普通の HTTP（平文）でオリジンにつなぐモードです。

なぜこんなモードがあるのでしょうか。昔は、証明書が有料で、サーバーに入れるのも難しかったからです。「オリジンに証明書を入れられなくても、とりあえず利用者には鍵マークを出したい」という要望に応えるためのモードでした。

でも、このモードには大きな問題があります。

特に1つ目と2つ目の組み合わせが危険です。「安全に見えるけれど、実際は安全ではない」状態は、何も付けていないより悪いとも言えます。

今は、Let's Encrypt のような無料の認証局があり、さらに Cloudflare 自身がオリジン用の無料の証明書（Origin CA。後のページ）を出しています。Flexible を選ぶ理由はもう残っていません。Flexible は使わないと覚えておいてください。

Flexible だと、リダイレクトが無限に回る

Flexible でいちばんよく起きる事故が、リダイレクトの無限ループです。ブラウザには「リダイレクトが多すぎます」（ERR_TOO_MANY_REDIRECTS）と表示され、ページが開きません。

なぜ起きるのか、順番に追ってみます。オリジンは「HTTP で来たら HTTPS に転送する」設定になっているとします。WordPress などでは普通の設定です。

オリジンから見ると、いつも HTTP でリクエストが来るので、何度でも HTTPS への転送を返します。Cloudflare は何度でも HTTP で取りに行きます。どちらも自分の仕事を正しくしているのに、組み合わせるとループになるのです。

直し方は、オリジンに証明書を入れて Full (strict) にすることです。区間2も HTTPS になれば、オリジンは転送を返さなくなります。HTTP から HTTPS への転送は、オリジンではなく Cloudflare の Always Use HTTPS（後のページ）に任せると、二重の転送も避けられます。

Full：暗号化はするが、相手を確かめない

Full は、区間2も HTTPS でつなぎます。これで区間2の中身は暗号化され、途中で読まれなくなります。Flexible よりずっとよいモードです。

ただし、Full はオリジンの証明書を確かめません。期限が切れていても、自分で作った証明書（自己署名）でも、名前が合っていなくても、つないでしまいます。

これが何を意味するか考えてみます。TLS の2つの仕事は「暗号化」と「相手の確認」でした。Full は暗号化だけをして、相手の確認を省いています。もし攻撃者が経路を乗っ取り、偽のオリジンを用意したとしても、Cloudflare はその偽物と暗号化して話し、偽物の返事を利用者に届けてしまいます。

Full が役に立つのは、移行の途中です。例えば、オリジンに自己署名の証明書しか無い状態から、正式な証明書を入れるまでの間に使います。Flexible から Full に上げるだけでも、盗み見は防げるようになります。

ただし、Full にすると、オリジンが 443番で HTTPS を話せない場合はつながらなくなります（525 などのエラー）。オリジンの準備を確かめてから切り替えてください。

Full (strict)：暗号化して、相手も確かめる

Full (strict) は、区間2を HTTPS でつなぎ、さらにオリジンの証明書が有効かどうかを確かめます。確かめるのは次の点です。

これで、2つの区間の両方で「暗号化」と「相手の確認」がそろいます。これが正しい状態です。

オリジンに入れる証明書は、2種類から選べます。

オリジンを Cloudflare 以外からも直接使う予定があるなら前者、Cloudflare の後ろ専用なら後者が手軽です。

証明書に問題があると、Full (strict) では 526（無効な証明書）のエラーが出ます。これは Cloudflare の障害ではなく、「オリジンの証明書がおかしいので、つながないで止めた」という、守りが正しく働いた結果です。

Origin CA 証明書：オリジン専用の無料の証明書

Origin CA 証明書は、Cloudflare が発行する、オリジンに入れるための証明書です。管理画面の SSL/TLS → Origin Server で作れます。

期限を長くできるので、「証明書の更新を忘れてサイトが止まる」心配がほぼ無くなります。一方で、ブラウザは信頼しないので、Cloudflare を通さずにオリジンへ直接つなぐと証明書のエラーになります。オレンジの雲の後ろ専用の証明書と考えてください。

作ると、証明書と秘密鍵が表示されます。秘密鍵はこのとき一度しか表示されないので、その場で保存してください。あとはサーバーに設定します。nginx なら次のようになります。

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/ssl/cf-origin.pem;
    ssl_certificate_key /etc/ssl/cf-origin.key;
}

設定したら、暗号化モードを Full (strict) に切り替えます。期限を長くしても、秘密鍵が漏れたら作り直す必要がある点は、ほかの証明書と同じです。

導入：オリジンに証明書を入れ、Full (strict) に

HTTPS をきちんと整える手順です。順番が大事で、オリジンの準備が先、モードの切り替えが後です。

3で Automatic SSL/TLS を使っている場合、Cloudflare はオリジンを調べて、対応できる一番安全なモードを選びます。変更はいきなり全部の通信に当てず、少しずつ広げて問題が無いかを見ながら進め、安全ではない方向には変えません。手で決めたいときは Custom に切り替えて、自分でモードを選べます。

切り替えたら、curl -I https://example.com で 200 が返るか、エラー番号が出ないかを確かめます。525 は「オリジンと TLS の握手ができない」、526 は「オリジンの証明書が無効」です。どちらも区間2の問題なので、オリジン側を見直します。

区間1を固める：常時 HTTPS・HSTS・最低 TLS

区間2を固めたら、区間1の仕上げです。管理画面の SSL/TLS → Edge Certificates に、次の設定が並んでいます。

HSTS は、応答に次のようなヘッダーを付ける設定です。

Strict-Transport-Security: max-age=31536000; includeSubDomains

これを受け取ったブラウザは、指定の期間、そのドメインに最初から HTTPS でしかつながなくなります。Always Use HTTPS の転送では、最初の1回だけは HTTP で送ってしまいますが、HSTS ならその1回も無くせます。

ただし HSTS は取り消しが難しい設定です。ブラウザが覚えている間は、HTTPS にできない名前を作ると開けなくなります。includeSubDomains を付けると、すべてのサブドメインに効きます。最初は短い期間で試し、問題が無いことを確かめてから延ばしてください。

TLS 1.0 と 1.1 は古く弱いので、主要なブラウザはすでに使っていません。最低を 1.2 にすれば、ほとんどの利用者に影響せず安全になります。

料金と制限

HTTPS の基本は、すべて無料プランでそろいます。

Advanced Certificate Manager は、Universal SSL では足りないときの追加の製品です。*.api.example.com のような多段のワイルドカードを含む証明書を作ったり、認証局や有効期限を選んだりできます。1つの証明書に含められる名前の数などに上限があります。

自分で買った証明書（例えば EV 証明書）を使いたい場合は、上位のプランでカスタム証明書としてアップロードできます。

多くのサイトは、Universal SSL と Origin CA の組み合わせで十分です。

※2026年9月時点の情報です。料金・提供プランは変わるので、公式で確かめてください。

よくある落とし穴

SSL/TLS のトラブルは、エラー番号で見分けられることが多いです。

もう1つ、見落としやすい点があります。Full (strict) にしても、攻撃者が Cloudflare を迂回してオリジンに直接つなぐことは防げません。01号で見たとおり、オリジンの番号が漏れていれば直接届きます。

これを塞ぐには、オリジンが Cloudflare からの接続だけを受け付けるようにします。方法は、Cloudflare だけが持つクライアント証明書で確かめる Authenticated Origin Pulls、Cloudflare の番号の範囲だけを許すファイアウォール、そして受け口そのものを無くす Tunnel（15号）です。

他の号とのつながり

CAA レコード（01号）は、「このドメインの証明書を発行してよい認証局」を指定する行です。自分で CAA を書いている場合、Cloudflare が使う認証局を許していないと、Universal SSL の発行や更新が失敗します。Cloudflare の DNS を使っていれば、必要な認証局を自動で足してくれる仕組みもありますが、CAA を触ったときは Edge Certificates の状態を確かめてください。