2025 年 10 月 07 日
AlmaLinux 10 でPQC（耐量子計算機暗号）をお試し（その４）
― post-quantum（耐量子）TLS サーバー証明書をお試し ―
post-quantum TLS サーバー証明書の試行
今回「その４」では、PQC 署名アルゴリズムの１つである ML-DSA（Module-Lattice Digital Signature Algorithm）を使った自己署名の TLS サーバー証明書を作って使ってみます。現行「認証」用の TLS サーバー証明書には RSA 暗号や楕円暗号が使われていますが、ここに PQC を使うお試しとなります。
ベースの環境は、前回と同じく、AlmaLinux 10 に crypto-policies-pq-preview パッケージをインストールし、PQC を試すためにサブポリシー TEST-PQ を設定した環境です。
まずは以下のとおり、ML-DSA65 の鍵生成を行い、併せてそれに紐づく自己署名証明書を作成します
（一部、■■■で伏せています）。
$ openssl req \
-x509 \
-newkey mldsa65 \
-keyout localhost-mldsa.key \
-subj "/C=JP/L=Tokyo/O=Cybertrust Japan Co Ltd/CN=■■■.■■■.cybertrust.co.jp" \
-addext "subjectAltName = DNS:■■■.■■■.cybertrust.co.jp" \
-addext "basicConstraints = critical,CA:false" \
-days 365 \
-nodes \
-out localhost-mldsa.crt
$ cat localhost-mldsa.key
-----BEGIN PRIVATE KEY-----
MIIXeAIBADALBglghkgBZQMEAxIEghdkBIIXYILUlp3Aj/5SdVcaLY+6uQVMpvfu
D/ONXDNXUvl55DI48rRMdVfx5NO0O3mfjDwQQHfBMnxDYgifmnkrdksZGVNi6l08
（略）
sA4IcAIMJhk3FW4FoQLsaEtBx8EQnppJvnMeEMIhoXOZVkI8n+2VauayjxsNyrGr
YkUzzbF38iOriBjC8Lq8/1VLUKNpVc2qd9ECVlK4U7EK08N9f22SXzawZUwPo3FR
SCsnEN7zF6NJl6wL
-----END PRIVATE KEY-----
$ cat localhost-mldsa.crt
-----BEGIN CERTIFICATE-----
MIIWcjCCCW+gAwIBAgIUf/uhCjiOJz9JhlFZjtR3I1ynN/UwCwYJYIZIAWUDBAMS
MHIxCzAJBgNVBAYTAkpQMQ4wDAYDVQQHDAVUb2t5bzEgMB4GA1UECgwXQ3liZXJ0
（略）
L5qAQ+FC74i82+SO2xCcsdF2hzL8m8AgRGDBJyO5GithogOZDWLJko4Z6SYRKwc1
8UpdD0NqpTzqok9YU7TuTCqZ5KVpiI+EkBAVT2uIleT3CRVsktcEWl2MmZ+z2wIc
H1ZacXSWrsonXXF6i5OY1z9ilbvnAAAAAAAAAAAAAAAIDRUfJyw=
-----END CERTIFICATE-----
以下のような post-quantum TLS サーバー証明書ができました（一部、■■■で伏せています）。
$ openssl x509 -text -noout -in localhost-mldsa.crt
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
7f:fb:a1: （略） :a7:37:f5
Signature Algorithm: mldsa65
Issuer: C=JP, L=Tokyo, O=Cybertrust Japan Co Ltd, CN=■■■.■■■.cybertrust.co.jp
Validity
Not Before: Sep （略） 2025 GMT
Not After : Sep （略） 2026 GMT
Subject: C=JP, L=Tokyo, O=Cybertrust Japan Co Ltd, CN=■■■.■■■.cybertrust.co.jp
Subject Public Key Info:
Public Key Algorithm: mldsa65
mldsa65 public key:
PQ key material:
82:d4:96:9d:c0:8f:fe:52:75:57:1a:2d:8f:ba:b9:
05:4c:a6:f7:ee:0f:f3:8d:5c:33:57:52:f9:79:e4:
（略）
52:b8:53:b1:0a:d3:c3:7d:7f:6d:92:5f:36:b0:65:
4c:0f:a3:71:51:48:2b:27:10:de:f3:17:a3:49:97:
ac:0b
X509v3 extensions:
X509v3 Subject Key Identifier:
51:70:0B: （略） :42:8B:F8:1B
X509v3 Authority Key Identifier:
51:70:0B: （略） :8B:F8:1B
X509v3 Subject Alternative Name:
DNS:■■■.■■■.cybertrust.co.jp
X509v3 Basic Constraints: critical
CA:FALSE
Signature Algorithm: mldsa65
Signature Value:
af:b8:8b:59:4f:25:df:66:f6:eb:61:8c:fa:81:99:d0:4a:4b:
5b:78:97:ef:1f:18:6b:72:b7:49:03:89:1d:d4:17:ff:2e:6e:
（略）
6c:92:d7:04:5a:5d:8c:99:9f:b3:db:02:1c:1f:56:5a:71:74:
96:ae:ca:27:5d:71:7a:8b:93:98:d7:3f:62:95:bb:e7:00:00:
00:00:00:00:00:00:00:00:00:08:0d:15:1f:27:2c
上記とは別途、既存の RSA を用いた証明書も作成しておきます。
$ openssl req \
-x509 \
-newkey rsa:2048 \
-keyout localhost-rsa.key \
-subj "/C=JP/L=Tokyo/O=Cybertrust Japan Co Ltd/CN=■■■.■■■.cybertrust.co.jp" \
-addext "subjectAltName = DNS:■■■.■■■.cybertrust.co.jp" \
-addext "basicConstraints = critical,CA:false" \
-days 365 \
-nodes \
-out localhost-rsa.crt
準備ができたので、openssl s_server コマンド（web サーバーを起動）と openssl s_client コマンド（ブラウザ接続に該当）を使い、同一の AlmaLinux 10 上ではありますが、post-quantum TLS サーバー証明書による「認証」および、その２やその３に記載した「ハイブリッド鍵交換」(X25519MLKEM768) を用いた TLS 1.3 接続を試します。
$ openssl s_server -cert localhost-mldsa.crt -key localhost-mldsa.key \ -dcert localhost-rsa.crt -dkey localhost-rsa.key >/dev/null & $ openssl s_client -connect localhost:4433 -servername ■■■.■■■.cybertrust.co.jp \ -CAfile localhost-mldsa.crt </dev/null （略） --- Certificate chain 0 s:C=JP, L=Tokyo, O=Cybertrust Japan Co Ltd, CN=■■■.■■■.cybertrust.co.jp i:C=JP, L=Tokyo, O=Cybertrust Japan Co Ltd, CN=■■■.■■■.cybertrust.co.jp a:PKEY: UNDEF, 192 (bit); sigalg: mldsa65 v:NotBefore: Sep （略） : 2025 GMT; NotAfter: Sep （略） 2026 GMT --- （略） Peer signature type: mldsa65 Negotiated TLS1.3 group: X25519MLKEM768 （略） --- DONE
上のとおり、sigalg: mldsa65 とある post-quantum TLS サーバー証明書が用いられ、併せて、鍵交換：X25519MLKEM768 で、web サーバー - ブラウザ間が接続されました。
ちなみに、openssl s_server コマンド側（web サーバー）はそのまま、openssl s_client コマンド（ブラウザ接続）において、署名アルゴリズムとして従来の RSA_PSS を指定して接続すると以下となります。
$ openssl s_client -connect localhost:4433 -servername ■■■.■■■.cybertrust.co.jp \ -sigalgs 'rsa_pss_pss_sha256:rsa_pss_rsae_sha256' </dev/null （略） --- Certificate chain 0 s:C=JP, L=Tokyo, O=Cybertrust Japan Co Ltd, CN=■■■.■■■.cybertrust.co.jp i:C=JP, L=Tokyo, O=Cybertrust Japan Co Ltd, CN=■■■.■■■.cybertrust.co.jp a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Sep （略） 2025 GMT; NotAfter: Sep （略） 2026 GMT --- （略） Peer signature type: RSA-PSS Negotiated TLS1.3 group: X25519MLKEM768 （略） DONE
上のように、鍵交換はハイブリッド（X25519MLKEM768）のままですが、認証については sigalg: RSA-SHA256 とある従来 RSA の証明書が用いられて接続されました。
Apache httpd での RSA 証明書と PQC 証明書の同時設定
前述の試行は openssl を TLS サーバーとして稼働させていますが、Apache httpd も、既存暗号については RSA と ECDSA 両方の鍵・サーバー証明書を同時に設定できることから、試しに Apache httpd において RSA と PQC 両方の設定を行ってみることにしました。
設定ファイル ssl.conf（/etc/httpd/conf.d/ssl.conf）を編集し、RSA と PQC(ML-DSA65) 両方の鍵ファイルと証明書ファイルを併記して設定します。併せて、上で作成した鍵・証明書ファイルを該当のディレクトリに配置します。
# PEM encoded certificate. SSLCertificateFile /etc/pki/tls/certs/localhost-rsa.crt SSLCertificateFile /etc/pki/tls/certs/localhost-mldsa.crt # Server Private Key: SSLCertificateKeyFile /etc/pki/tls/private/localhost-rsa.key SSLCertificateKeyFile /etc/pki/tls/private/localhost-mldsa.key
Apache httpd を起動。
# systemctl start httpd # systemctl status httpd ●httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; preset: disabled) Active: active (running) since ・・・ （略） ・・・
正常に起動できました。
openssl s_client コマンド（ブラウザ接続に該当）で接続。
$ openssl s_client -connect localhost:443 -servername ■■■.■■■.cybertrust.co.jp \ -CAfile localhost-mldsa.crt </dev/null （略） --- Certificate chain 0 s:C=JP, L=Tokyo, O=Cybertrust Japan Co Ltd, CN=■■■.■■■.cybertrust.co.jp i:C=JP, L=Tokyo, O=Cybertrust Japan Co Ltd, CN=■■■.■■■.cybertrust.co.jp a:PKEY: UNDEF, 192 (bit); sigalg: mldsa65 v:NotBefore: Sep （略） 2025 GMT; NotAfter: Sep （略） 2026 GMT --- （略） Peer signature type: mldsa65 Negotiated TLS1.3 group: X25519MLKEM768 （略）
openssl s_server の時同様に、Apache httpd においても、sigalg: mldsa65 とある post-quantum TLS サーバー証明書が用いられ、併せて、鍵交換：X25519MLKEM768 で接続されることが確認できました。
また、Apache httpd はそのままに、openssl s_client コマンド（ブラウザ接続に該当）において、署名アルゴリズムとして従来の RSA_PSS を指定して接続すると以下となります。
$ openssl s_client -connect localhost:443 -servername ■■■.■■■.cybertrust.co.jp \ -sigalgs 'rsa_pss_pss_sha256:rsa_pss_rsae_sha256' </dev/null （略） --- Certificate chain 0 s:C=JP, L=Tokyo, O=Cybertrust Japan Co Ltd, CN=■■■.■■■.cybertrust.co.jp i:C=JP, L=Tokyo, O=Cybertrust Japan Co Ltd, CN=■■■.■■■.cybertrust.co.jp a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Sep （略） 2025 GMT; NotAfter: Sep （略） 2026 GMT （略） Peer signature type: RSA-PSS Negotiated TLS1.3 group: X25519MLKEM768 （略）
鍵交換はハイブリッド（X25519MLKEM768）のままですが、認証については sigalg: RSA-SHA256 とある従来 RSA の証明書が用いられて接続されることが確認できました。
最後に、RSA と PQC 両方の鍵・証明書を設定した上記 AlmaLinux 10 上の Apache に対し、Windows PC 上の Google Chrome ブラウザで接続を試しました。ちなみに、Google Chrome ブラウザは、ご存じの通り、ハイブリッド鍵交換は対応していますが、PQC 対応証明書は現状認識できません。
証明書が自己署名のため、
マークが表示されていますが、鍵交換は、ハイブリッド鍵交換（X25519MLKEM768）が使われ、また認証に関しては、従来 RSA 側の証明書が使われて、既存の Google Chrome ブラウザでも（PQC も設定された Apache サーバーに）接続できることが今回試せました。
現時点ではテクノロジープレビュー版なので将来の可能性というレベルではありますが、既存暗号（RSA や楕円）と PQC とが混在する過渡期の環境において、鍵交換については HNDL 攻撃への対策としてハイブリッド鍵交換 (X25519MLKEM768) が用いられつつ、認証については、クライアント環境（ブラウザ等）が解釈できるほうのアルゴリズムを用いた証明書（PQC 対応証明書か既存の RSA 等の証明書か）が用いられて認証を行うというイメージが垣間見えたのではないかと思います。
パブリックな PQC 対応商用証明書
パブリックな証明書の要件を定める業界団体である CAB フォーラムでも、PQC について議論が進んでいます。特に S/MIME に関しては、PQC 対応の要件が徐々に整いつつありますが、実用化に向けてはまだ多くのステップが必要です。例えば、認証局の鍵管理を担う HSM（ハードウェアセキュリティモジュール）については、PQC 対応を含めた FIPS 140-3 レベル 3 を正式に取得している製品は、現時点ではまだ存在しないのではないかと思います。PQC を扱える OS やアプリケーションの普及もこれからの課題です。これらが普及し、PQC 対応のパブリック証明書が利用できるようになるまでには、もう少し時間がかかかりそうです。
AlmaLinux 10 での PQC お試しはここまでとなります。
最後に少し宣伝となりますが、サイバートラスト R&D センターでは、PQC に関わる動向 watch や各種試行などを行っています。PQC にも対応した、証明書の内容確認用のツール「PQC 対応 TLS サーバー証明書サポートツール（ベータ版）」や、テスト用の PQC 証明書もご提供しています。IT 環境全体が PQC レディーになるにはまだ多少時間を要するものと想像しますが、その中で質問・相談事項などございましたら、お気軽にお問い合わせください（問合せ先：pqctrial@cybertrust.co.jp）。
関連 Web サイト
この記事の著者
「R&D センター」は、2022 年 4 月 1 日に立ち上げられた研究開発部門です。
サイバートラストは、お客様のサービスの信頼性を支えるプラットフォーマーとして、先々のプラットフォームや社会制度、他がどのように変化するのかを考えています。
さまざまな IoT 機器が普及し、OSS や AI やブロックチェーンが活用され、量子コンピュータが発達する一方で、それらによる新たなセキュリティリスクも生じると想像される未来においても、引き続き、安心・安全な社会を実現するため、サイバートラストが果たす役割を含め、研究開発を進めています。
* AlmaLinux は、The AlmaLinux OS Foundation の商標です。
* Linux は、Linus Torvalds 氏の日本およびその他の国における登録商標または商標です。
* Red Hat、Red Hat Enterprise Linux は、米国およびその他の国における Red Hat, Inc. およびその子会社の商標または登録商標です。
* その他、記載されている会社名、製品名、サービス名は、当社または各社、各団体の商標もしくは登録商標です。
* サイバートラストは、AlmaLinux OS Foundation に日本企業初のプラチナスポンサーとして参画する AlmaLinux OS の公式ディストリビューターですが、本ブログは当社の R&D チームで試行した結果の共有であり、AlmaLinux OS に関わる公式サポート情報ではなく、また、AlmaLinux OS Foundation の公式見解でもありません。併せて、本ブログはテクノロジープレビューパッケージを試したものであるため、機能的に完成していない可能性があり、本番用途への展開には適しません。
