Skip to content

非公式本サイトは非公式の日本語ドキュメントであり、Cloudflare 公式サイトではありません。最新情報はdevelopers.cloudflare.comをご確認ください。

Cloudflare とオリジンサーバー間の耐量子暗号

最終更新 Markdown で表示Agent セットアップ

このページでは、Cloudflare エッジとオリジンサーバーの間の TLS 接続における耐量子暗号（PQC）を扱います。この接続では、耐量子鍵合意（X25519MLKEM768）と 耐量子署名（Authenticated Origin Pulls および Custom Origin Trust Store 経由の ML-DSA）の両方に対応しています。

公開された TLS エンドポイント上で証明書を管理せずにオリジンを Cloudflare へつなぎたい場合は、耐量子のオリジン接続の別手段として Cloudflare Tunnel もあります。Cloudflare Tunnel は、cloudflared と Cloudflare ネットワークの間の TLS 接続で耐量子鍵合意を使います。この経路では、認証に耐量子署名はまだ使われていません。

耐量子鍵合意

PQC の概要 で説明しているとおり、Cloudflare はハイブリッド鍵合意に対応しています。TLS 1.3 で最も一般的な鍵合意である X25519 と、耐量子の ML-KEM の両方を含みます。

X25519 では、ClientHello ↗ はほぼ常に 1 パケットに収まります。一方、ML-KEM を加えると、ClientHello は通常 2 パケットに分割されます。

オリジンサーバーやその他の中間装置（ルーター、ロードバランサーなど）が、この挙動の変化をどう扱うかが問題になります。TLS 1.3 規格（RFC 8446 ↗）では分割は許容されていますが、プロトコルの硬直化 ↗ や実装バグにより、分割された ClientHello がうまく処理されないことがあります。詳細は ブログ記事 ↗ を参照してください。

Cloudflare からの ClientHello

Cloudflare は Automatic key exchange で、ゾーンのオリジンサーバーが優先する鍵合意を学習します。優先設定はゾーン全体に 1 つ適用されます。選ばれた優先設定が X25519MLKEM768 のとき、接続確立を速くするため、Cloudflare は最初の ClientHello にその鍵シェアを入れます。

Cloudflare は、許可されている他の鍵合意も引き続き提示します。オリジンが別の鍵シェアを必要とする場合は、HelloRetryRequest ↗ で要求できます。再試行はネットワークの往復を 1 回増やしますが、接続は切れません。

セットアップ

Cloudflare ゾーン設定

Automatic key exchange は、既存ゾーンではすべてオンで、新規ゾーンでもデフォルトでオンです。オリジンが従来型と耐量子の両方に対応している場合、Cloudflare は耐量子鍵合意を優先します。

スキャンと優先する鍵シェアの選択は、Automatic key exchange で制御します。コンプライアンス要件は TLS 1.3 接続にだけ適用されます。

Origin Post-Quantum Encryption API は引き続き利用できます。この API へのリクエストは no-op で、ゾーンの耐量子鍵合意の挙動は変わりません。Cloudflare はこの API を非推奨にする予定ですが、廃止日はまだ決まっていません。

オリジンサーバー

オリジンサーバーが耐量子鍵合意を優先することを確認するには、BoringSSL ↗ の bssl ツールを使います。

bssl client -connect <YOUR_ORIGIN>:443 -curves X25519MLKEM768

ハンドシェイク出力の ECDHE curve が X25519MLKEM768 であることを確認します。

耐量子署名

2026 年半ば以降、Cloudflare はオリジン向けの次の 2 機能で ML-DSA ↗ 耐量子署名に対応しています。

どちらも単独でも、組み合わせても使えます。両方を使うと、耐量子鍵合意 に加えて、Cloudflare エッジとオリジンサーバーの間でエンドツーエンドの耐量子認証を確立できます。

要件

  • オリジン上で ML-DSA に対応した TLS ライブラリ。例: OpenSSL ↗ 3.5.0 以降。他の選択肢は PQC の対応状況 を参照してください。
  • 証明書生成用のワークステーション上の OpenSSL ↗ 3.5.0 以降。
  • ML-DSA 署名のために TLS 1.3 をネゴシエートするオリジンサーバー。

ML-DSA 認証局とリーフ証明書を生成する

次のコマンドは、ML-DSA-44 を使い、プライベート認証局とその配下のリーフ証明書を作成します。AOP 用のクライアント証明書で 1 回、COTS のサーバー側も管理する場合はもう 1 回実行します。

# Private ML-DSA-44 CA (30-year validity)
openssl genpkey \
  -algorithm mldsa44 \
  -provparam ml-dsa.output_formats=seed-only \
  -out ca.key
openssl req -new -x509 \
  -key ca.key \
  -out ca.crt \
  -days 10950 \
  -subj "/CN=ML-DSA Origin CA"

# Leaf certificate signed by the CA (15-year validity)
openssl genpkey \
  -algorithm mldsa44 \
  -provparam ml-dsa.output_formats=seed-only \
  -out leaf.key
openssl req -new \
  -key leaf.key \
  -out leaf.csr \
  -subj "/CN=origin.example.com" \
  -addext basicConstraints=CA:FALSE \
  -addext keyUsage=digitalSignature \
  -addext subjectAltName=DNS:origin.example.com
openssl x509 -req \
  -in leaf.csr \
  -CA ca.crt -CAkey ca.key \
  -CAcreateserial \
  -out leaf.crt \
  -days 5475 \
  -copy_extensions copy

-provparam ml-dsa.output_formats=seed-only フラグは必須です。秘密鍵を展開済み秘密鍵ではなく、FIPS 204 の seed 形式で書き出します。Cloudflare が現在アップロードで受け付けるのは、この形式だけです。

生成した証明書を確認します。

openssl x509 -in leaf.crt -noout -subject -issuer -dates -ext subjectAltName

ML-DSA クライアント証明書で Authenticated Origin Pulls を設定する

ML-DSA クライアント証明書は、ゾーン単位 と ホスト名単位 の両方の AOP で使えます。ML-DSA 認証局とリーフ証明書を生成する の手順で CA とリーフ証明書を作り、設定する範囲のセットアップガイドに従ってください。グローバル AOP は Cloudflare 提供の証明書を使い、設定は変更できません。

オリジンサーバー側では、先に生成した ML-DSA CA 証明書（ca.crt）をインストールし、Cloudflare が提示するクライアント証明書を TLS サーバーが検証できるようにします。nginx では次のようになります。

ssl_client_certificate /etc/ssl/cloudflare-aop-ca.crt;
ssl_verify_client      on;

オリジン側の設定の全体は、オリジンサーバー向け AOP セットアップガイド を参照してください。

ML-DSA CA で Custom Origin Trust Store を設定する

先に生成した ML-DSA CA 証明書（ca.crt）を Custom Origin Trust Store のエントリとしてアップロードします。すると Full (strict) 暗号化モード では、その CA にチェーンするオリジンサーバー証明書を Cloudflare が信頼します。

オリジンサーバー側では、ML-DSA リーフ証明書とその秘密鍵を TLS サーバー証明書として提示します。

ssl_certificate     /etc/ssl/origin-mldsa.pem;
ssl_certificate_key /etc/ssl/origin-mldsa.key;
ssl_protocols       TLSv1.3;

エンドツーエンドで確認する

AOP と COTS を設定したら、ML-DSA 対応のホストから耐量子オリジンハンドシェイクを確認できます。たとえば OpenSSL 3.5.0 以降のマシンからオリジンへ直接接続し、ハンドシェイクが ML-DSA を使っていることを確認します。

openssl s_client \
  -connect origin.example.com:443 \
  -servername origin.example.com \
  -CAfile ca.crt \
  -cert leaf.crt \
  -key leaf.key \
  -brief

出力に Signature type: mldsa44 と Negotiated TLS1.3 group: X25519MLKEM768 が表示されるはずです。

ダウングレードを防ぐ

認証する側が ML-DSA 証明書を提示するだけでは不十分です。耐量子認証を実際に得るには、検証する側 が従来型（非耐量子）の証明書を拒否する必要があります。検証側が従来型証明書をまだ受け入れると、その従来型鍵を侵害した攻撃者が 経路上攻撃 ↗ でピアになりすませます。耐量子の保護が無効になるダウングレードです。

  • Custom Origin Trust Store（COTS）: アップロードする認証局は ML-DSA だけにしてください。トラストストアに ML-DSA CA と並べて従来型 CA を残すと、Cloudflare は従来型 CA にチェーンするオリジン証明書も受け入れ、接続がダウングレードされる余地が残ります。COTS CA のアップロードは、そのゾーンのデフォルト公開信頼 CA をすでに置き換えるので（上記の注意を参照）、アップロードする CA はすべて耐量子にしてください。
  • Authenticated Origin Pulls（AOP）: オリジンサーバーで ML-DSA クライアント証明書を必須にし、従来型のクライアント証明書を拒否するよう設定します。Cloudflare が ML-DSA 証明書を提示しても、オリジンが従来型証明書の接続を認証してしまうと意味がありません。

役に立ちましたか？