SSL/TLS（Universal SSL）

解決する課題

• TLS証明書を外部認証局から購入・更新する手間とコストをなくしたい
• 証明書の有効期限切れによるサイト停止・警告表示を避けたい
• オリジンサーバーの構成やTLS対応状況に応じて、暗号化の強度を柔軟に選びたい
• 複数のサブドメインやワイルドカードに対して、証明書配布を一元的に自動化したい
• オリジンとCloudflare間の通信も暗号化し、経路全体でのなりすまし・盗聴リスクを抑えたい

Cloudflareの SSL/TLS（Universal SSL）は、ドメインをCloudflareのネームサーバーに向けるだけでエッジ証明書を自動発行し、ブラウザとCloudflare間のHTTPS通信を標準で有効化するマネージド機能です。証明書のライフサイクル管理（発行・更新・失効）をCloudflareが引き受け、オリジンとの間の暗号化方式は暗号化モードで選択できます。

主要概念と用語

• Universal SSL（ユニバーサルSSL）: ドメイン追加時に自動発行される共有型のエッジ証明書。多くのプランで追加費用なく有効化される基本機能
• エッジ証明書: ブラウザ（クライアント）とCloudflareのエッジサーバー間のTLS終端に使われる証明書
• オリジン証明書（Origin CA）: Cloudflareのオリジン認証局が発行する、Cloudflareとオリジンサーバー間の通信専用の証明書
• 暗号化モード: オリジンとの通信方式を決める設定。Off（無効）、Flexible（ブラウザ―Cloudflare間のみ暗号化）、Full（両区間暗号化、オリジン証明書は自己署名可）、**Full (strict)（両区間暗号化、オリジン証明書を検証）**の段階がある
• Advanced Certificate Manager（ACM）: 証明書の発行局選択やホスト名カバレッジなど、証明書運用を高度にカスタマイズできる上位機能
• Certificate Transparency（CT）: 発行された証明書を公開ログに記録する仕組み。不正発行の検知に使われる
• HSTS（HTTP Strict Transport Security）: ブラウザに対して常にHTTPSで接続するよう指示するレスポンスヘッダー設定
• TLS 1.3 / 最小TLSバージョン: エッジで許可する暗号化プロトコルのバージョンを制御する設定
• mTLS（相互TLS）: クライアント証明書によりクライアント側も検証する、双方向の認証方式

仕様・制限・クォータ

• Universal SSLは、ドメインをCloudflareに追加すると自動的に発行対象になり、通常は追加の申請作業を必要としない
• カバーする範囲はゾーン（ルートドメイン）と直下のワイルドカード（1階層分のサブドメイン）が基本で、複数階層にまたがるサブドメインを含めたい場合はAdvanced Certificate Managerでのホスト名指定が必要になる
• 証明書の発行局は複数のパートナー認証局から選ばれ、状況に応じて自動的に切り替わることがある
• 暗号化モードは**Off／Flexible／Full／Full (strict)**の順で保護レベルが高まり、Full (strict)ではオリジン証明書の有効性検証が行われる
• 独自ドメインの証明書を発行するには、DNSまたはHTTPによる所有権検証が必要で、検証が通らない間は発行が保留される
• 対応TLSバージョンや暗号スイートの範囲、証明書の同時カバー数などの詳細な上限は変動するため、最新の公式ドキュメントで確認する

内部の仕組み

Universal SSLの中核は、ドメイン追加時に走る自動発行フローです。ドメインがCloudflareのネームサーバーに委任されると、Cloudflareは複数の認証局と連携してドメインの所有権を検証し、共有型のエッジ証明書に対象ホスト名を追加、あるいは専用の証明書を発行します。発行された証明書は世界中のエッジサーバーに配布され、有効期限が近づくと自動的に更新されます。証明書の発行はCertificate Transparencyログに記録され、第三者が不正発行を検知できるようになっています。

暗号化モードは、Cloudflareが受け取ったリクエストをオリジンへ転送する際の挙動を決めます。Flexibleではオリジンへの転送がHTTPになり、Full系ではHTTPSで転送されます。Full (strict)では、オリジン証明書が信頼された認証局から発行されているか、有効期限内かを検証し、検証に失敗するとエラーを返します。オリジン側で公的証明書を用意しにくい場合は、Cloudflareのオリジン認証局が発行するオリジン証明書をオリジンサーバーに設置することで、Full (strict)を維持しながら運用コストを抑えられます。

設計パターン / ベストプラクティス

• 新規ドメイン追加後は、まず**Full (strict)**を目標に設定し、オリジン側のTLS対応を整える
• オリジンに公的証明書を用意しづらい場合はオリジン証明書を発行してオリジンに設置し、Full (strict)を維持する
• 常時HTTPS化のため、HTTPからHTTPSへの自動リダイレクト設定とHSTSを組み合わせる
• 複数階層のサブドメインを公開する構成では、標準のUniversal SSLのカバー範囲を確認し、不足する場合はAdvanced Certificate Managerでホスト名を追加する
• 最小TLSバージョンを引き上げ、古い暗号スイートを無効化して、脆弱なクライアントとの互換性より安全性を優先する構成にする
• API連携やパートナー間通信など高信頼が必要な経路には、mTLSでクライアント証明書検証を追加する

運用・監視

• ドメインごとの暗号化モードが意図した設定になっているかを定期的に確認する
• 証明書の発行状況や有効期限は管理画面やAPIから確認でき、独自証明書をインポートしている場合は期限管理を自前で行う必要がある
• Certificate Transparencyログを利用して、自ドメインに対する意図しない証明書発行がないかを監視する
• オリジン証明書を使っている場合、Cloudflare側の検証失敗（Full (strict)でのエラー）が発生していないかログで確認する
• TLSバージョンや暗号スイートの利用状況を可視化し、非推奨プロトコルへの依存が残っていないかを追跡する

コスト

具体的な料金体系や対象プランは変動するため、最新情報は公式の料金ページで確認してください。基本方針として、標準のUniversal SSLで多くのユースケースをカバーし、複雑なホスト名構成や発行局要件がある場合のみ上位機能を検討するとコストを抑えやすくなります。

セキュリティ

• ブラウザ―エッジ間の通信を自動的にTLSで保護し、平文HTTPでの露出を防ぐ
• **Full (strict)**を選ぶことで、エッジ―オリジン間もなりすまし防止を含めて保護できる
• Certificate Transparencyにより、自ドメインに対する不正・意図しない証明書発行を検知しやすくなる
• 最小TLSバージョンの引き上げと脆弱な暗号スイートの無効化で、既知の脆弱性を悪用した攻撃面を減らせる
• 高信頼な経路にはmTLSを組み合わせ、サーバー証明書だけでなくクライアント証明書による検証も行える

関連サービス・比較

ハンズオン / CLI例

# 1. ゾーンのSSL/TLS暗号化モードを確認
wrangler ssl-tls status --zone example.com

# 2. 暗号化モードをFull (strict) に変更
wrangler ssl-tls set --zone example.com --mode full-strict

# 3. Universal SSL証明書の発行状況を確認
wrangler ssl-tls certificate list --zone example.com

# 4. HSTSなど推奨設定の適用状況を確認
wrangler ssl-tls settings get --zone example.com --setting hsts