2026年版：kurutann.comのPQC対応を実測確認｜Nginx・Cloudflare・X25519MLKEM768

2026年8月1日訂正・実測更新

この記事は、一般的なNginx＋Let’s Encryptの導入手順として書かれていた旧版を、 kurutann.comで実際に動いているDocker・Cloudflare構成に合わせて全面的に訂正したものです。 旧版に混入していた生成AI画面のHTML、現在の構成に当てはまらないCertbot・systemd手順、 RFC・MTC・ログ変数の不正確な説明を除去しました。

結論：鍵交換のPQC対応は、すでに利用できる状態です

2026年8月1日の実測結果は次のとおりです。

つまり、Cloudflare EdgeとオリジンNginxの両端がX25519MLKEM768を処理できることは確認済みです。 一方、Cloudflareからオリジンへ到達した個々の接続で何が選ばれたかは、 Nginxの$ssl_curveをログへ追加して初めて接続単位で証明できます。 「対応できる」と「各接続で実際に使った」を分けて扱うのが重要です。

現在のkurutann.comの構成

対応ブラウザ／検証クライアント
  │  TLS 1.3 / X25519MLKEM768
  ▼
Cloudflare Edge
  │  TLS 1.3（Automatic key exchangeの対象）
  ▼
Docker版 Nginx
  │  nginx/1.31.3、OpenSSL 3.5.7
  │  Cloudflare Origin CA証明書
  ▼
Django

公開側でブラウザへ提示される証明書と、Cloudflareからオリジンへ接続するときの証明書は別物です。 現在のオリジン証明書はCloudflare Origin CAです。 Let’s Encrypt証明書へ交換しなくても、TLS 1.3の鍵交換をX25519MLKEM768にできます。

Cloudflare Origin CA証明書は、Cloudflareとオリジン間で使うための証明書です。 一般のブラウザや通常のOS信頼ストアからオリジンへ直接接続すると、信頼されない証明書として検証エラーになります。 これは設計どおりであり、オリジンを直接公開する理由にはなりません。

PQC鍵交換と証明書署名は別です

X25519MLKEM768は、X25519とML-KEM-768の共有秘密を組み合わせるTLS 1.3のハイブリッド鍵交換です。 ML-KEMはNISTのFIPS 203で標準化された鍵カプセル化方式です。 片方の構成要素に将来問題が見つかっても、もう片方が破られていなければ共有秘密を守ることを狙います。

これは、保存された暗号通信を将来復号する「Harvest Now, Decrypt Later」への防御を前進させます。 ただし、証明書認証まで完全に耐量子化したことを意味しません。

RFC 9954についての訂正

RFC 9954は、TLS 1.3で複数の鍵交換方式を組み合わせるための一般的な構成を示す Informational RFCです。RFC自身も、特定の耐量子方式やグループを選定・規定しないと説明しています。

X25519MLKEM768、SecP256r1MLKEM768、SecP384r1MLKEM1024という具体的なグループは、 2026年8月1日時点ではIETFの ECDHE-MLKEM Internet-Draft が定義しています。 したがって「RFC 9954がX25519MLKEM768そのものを規定した」という旧版の表現は不正確でした。

このサイトでLet’s Encryptへ切り替えない理由

PQC鍵交換のためだけに証明書を取り直す必要はありません。証明書の公開鍵方式とTLSの鍵交換グループは独立しています。 RSA証明書でもECDSA証明書でも、サーバーとクライアントが対応していればX25519MLKEM768を利用できます。

• 現在のCloudflare Origin CA証明書でオリジン認証は成立しています。
• Let’s Encryptへ移行すると、Certbot、永続ボリューム、更新フック、コンテナ再読込の運用が追加されます。
• PQC鍵交換の有効化という目的に対して、証明書移行は必要条件ではありません。
• 直接接続用の公開証明書が必要になる別要件が生じた場合に、Let’s Encryptを改めて検討します。

Let’s Encryptが通常の公開証明書で受け付ける鍵は、現時点ではRSAとECDSAです。 ML-DSA証明書は、Certbotだけを改造しても認証局・ブラウザ・証明書エコシステムが対応しなければ一般公開には使えません。

MTCは署名アルゴリズムの名前ではありません

MTC（Merkle Tree Certificates）は、従来のX.509証明書を単純にML-DSAへ置き換える名称ではなく、 Merkle Treeを使う新しい証明書配布・検証の設計です。 ML-DSAやSLH-DSAのような署名アルゴリズムと、MTCという証明書アーキテクチャを同じ列に並べてはいけません。

Let’s Encryptは2026年6月の計画で、2026年後半にMTCのステージングを始める方針を示しています。 これは将来の検証対象であり、現在の公開サイトへ即時導入する設定ではありません。

Nginxで明示的なグループ指定を追加しない理由

現在のNginx設定にはssl_ecdh_curveの固定リストがなく、OpenSSLの自動選択を利用しています。 実測でX25519MLKEM768とX25519の両方が成功しているため、目的はすでに満たされています。

# 必要なら意図を明示できるが、現状は変更不要
ssl_ecdh_curve auto;

旧版にあった次のような固定リストは、このサイトの推奨設定から外しました。

ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1:secp384r1;

OpenSSL 3.5のTLSグループ設定には、単純な列挙だけでなくtupleやKeyShareの選択規則があります。 固定リストを書いただけで、すべてのクライアント・すべての接続に対して意図した優先順位になるとは限りません。 現行のautoで必要な交渉が成立しているなら、互換性を狭める変更は行わず、実測を優先します。

2026年8月1日に使った確認方法

1. Nginxが実際にリンクしているOpenSSLを確認

docker exec noujyuku-nginx nginx -V

主要な実測結果は次のとおりでした。

nginx version: nginx/1.31.3
built with OpenSSL 3.5.7 9 Jun 2026

OS上のopenssl versionだけでは、Nginxがどのライブラリでビルドされたかは分かりません。 nginx -Vの結果を確認します。

2. 公開側のCloudflare Edgeを確認

openssl s_client \
  -connect kurutann.com:443 \
  -servername kurutann.com \
  -tls1_3 \
  -groups X25519MLKEM768 \
  -brief

実測では次が確認できました。

Protocol version: TLSv1.3
Negotiated TLS1.3 group: X25519MLKEM768
Verification: OK

3. オリジンNginxの対応能力を確認

公式Alpine版Nginxコンテナにはopensslコマンドが入っていないため、 VPSホストからローカルの443番へ接続して確認しました。

openssl s_client \
  -connect 127.0.0.1:443 \
  -servername kurutann.com \
  -tls1_3 \
  -groups X25519MLKEM768 \
  -brief

実測では次が確認できました。

Protocol version: TLSv1.3
Peer certificate: CloudFlare Origin Certificate
Negotiated TLS1.3 group: X25519MLKEM768

この直接確認ではCloudflare Origin CAが通常の公開信頼ストアに入っていないため、証明書検証エラーが表示されます。 鍵交換の対応確認と、公開Web PKIとしての証明書検証を混同しないでください。

4. フォールバックを確認

openssl s_client \
  -connect 127.0.0.1:443 \
  -servername kurutann.com \
  -tls1_3 \
  -groups X25519 \
  -brief

X25519だけを提示した接続も成功しました。PQC非対応クライアントを切り捨てず、 対応クライアントではハイブリッド方式を使える状態です。

Cloudflareからオリジンへの選択

CloudflareのAutomatic key exchangeは全プランで利用でき、既存ゾーンでは有効、新規ゾーンでは既定で有効です。 Cloudflareはアクティブなオリジンをおよそ24時間ごとに検査し、古典方式とPQC方式の両方に対応していれば X25519MLKEM768を優先し、1％から段階的に100％へ展開すると説明しています。

kurutann.comのオリジンがX25519MLKEM768へ応答できることは確認済みです。 ただし、本記事ではCloudflare管理画面の設定値や各接続の選択結果を推測で「確認済み」としません。 次のログをメンテナンス時間帯に追加し、実通信で最終確認します。

鍵交換グループを正しくログへ残す

Nginxのrealipモジュールでreal_ip_header CF-Connecting-IP;を使うと、 $remote_addrは訪問者のIPへ置き換わります。 Cloudflare側の接続元アドレスを残したい場合は$realip_remote_addrも記録します。

log_format tls_observed
  'client=$remote_addr peer=$realip_remote_addr '
  'cf_ray=$http_cf_ray tls=$ssl_protocol cipher=$ssl_cipher '
  'group=$ssl_curve request="$request" status=$status';

• $remote_addr：realip処理後の訪問者IP
• $realip_remote_addr：realip処理前のCloudflare接続元IP
• $http_cf_ray：Cloudflareのリクエスト識別子
• $ssl_curve：実際にネゴシエートされたTLSグループ

旧版のように$remote_addrだけを記録してCloudflare側アドレスも確認できる、という説明は誤りでした。

Docker構成ではsystemd・Certbot手順をそのまま使わない

このサイトのNginxはDockerコンテナで動作しています。そのため、旧版の次の手順は現在の構成へ直接適用できません。

• systemctl reload nginx
• ホストOSのdnf update nginxだけでコンテナNginxを更新すること
• /etc/letsencryptを前提にしたCertbot更新フック
• /var/www/letsencryptを前提にしたHTTP-01設定

bind mountされたNginx設定を変更する場合は、リポジトリ側を正本として編集し、 nginx -tで検証したうえでコンテナ再作成を含む反映計画が必要です。 reloadだけで安全に反映できると決めつけてはいけません。

今回変更したもの・変更していないもの

• 変更したもの：この記事の本文、抜粋、SEO・OG情報
• 変更していないもの：Nginx設定、証明書、Cloudflare設定、Docker構成
• 実施していないもの：OS・OpenSSL・Nginxのパッケージ更新
• 実施していないもの：ホストまたはコンテナの再起動

本文訂正時点では再起動可能なメンテナンス枠が確保されていないため、 パッケージ更新と再起動は実施していません。 この記事の反映に、Nginx設定変更や再起動は必要ありません。

現時点の推奨構成

Cloudflareの公開証明書
+ TLS 1.3
+ 対応クライアントではX25519MLKEM768
+ 古典方式へのフォールバック
+ Cloudflare Automatic key exchange
+ Cloudflare Origin CA証明書
+ nginx/1.31.3 built with OpenSSL 3.5.7
+ OpenSSLの自動グループ選択

この構成は、証明書運用を増やさずに鍵交換の耐量子性を前進させます。 今後の作業は、メンテナンス枠で$ssl_curveログを追加してCloudflare→オリジンの実接続を観測し、 別枠でパッケージ更新と再起動を行うことです。

FAQ

Let’s Encrypt証明書へ変更する必要はありますか

ありません。PQC鍵交換のためだけなら、現在のCloudflare Origin CA証明書を維持できます。

RSA証明書でもX25519MLKEM768を使えますか

使えます。証明書の公開鍵方式とTLS 1.3の鍵交換グループは別です。

対応していない端末は接続できなくなりますか

古典方式のフォールバックを残しているため、今回の実測ではX25519だけを提示した接続も成功しました。

公開側がX25519MLKEM768なら、オリジン側も自動的に同じですか

自動的に同じだとは断定できません。二つは別のTLS接続です。 オリジンの対応能力は確認済みで、Cloudflareには自動選択機能がありますが、各接続の最終確認には$ssl_curveログを使います。

完全な耐量子HTTPSになりましたか

いいえ。今回は鍵交換部分のハイブリッド化です。公開証明書の認証やWeb PKI全体の耐量子移行は別の課題です。

一次資料

• NIST FIPS 203：ML-KEM
• NIST FIPS 204：ML-DSA
• RFC 9954：Hybrid Key Exchange in TLS 1.3
• IETF：Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3
• OpenSSL 3.5 Series Release Notes
• OpenSSL 3.5：TLS group configuration
• NGINX公式：Post-Quantum Cryptography with NGINX
• NGINX ngx_http_ssl_module
• Cloudflare：Automatic key exchange to origins
• Cloudflare：Post-quantum cryptography to origins
• Let’s Encrypt Integration Guide
• Let’s Encrypt：Our plan for post-quantum cryptography

確認日：2026年8月1日。仕様・実装・サービス設定は更新されるため、導入時には上記一次資料と実測結果を再確認してください。