Cloudflareは、Keyless SSLのECDSA証明書でTLS 1.3に対応した。RSA証明書の接続はTLS 1.2までのまま ── 担当サイトの証明書の鍵の種類と受け付けるTLSの版を外から確かめる13項目（2026年11月時点）

目次

1. 01 何が書いてあるか — Keyless SSLは、ECDSA証明書ならTLS 1.3、RSA証明書ならTLS 1.2まで
   1. 3つの文書は何を書いているか
   2. この記事で扱わないこと
2. 02 なぜ・背景 — 証明書の鍵の種類は、TLSの版の「前提」になりうる
   1. 接続のはじめに、サーバーは証明書で名乗る
   2. 鍵の種類が変わると、変わりうること
   3. TLS 1.0とTLS 1.1は、使ってはならない版になっている
3. 03 用語 — 出てくる言葉を、先にそろえる
   1. openssl s_clientの、この記事で使う指定
4. 04 型別 — 誰に関係があるか、何が分からないか、どう確かめるか
   1. 🅰 適用範囲 — 今回の更新が直接かかわる人
   2. 🅱 この情報が測っていないこと
   3. 🅲 手順1 — 手元のPCで読んだ証明書を、そのまま信じない
   4. 🅲 手順2 — 証明書の鍵の種類を読む
   5. 🅲 手順3 — TLSの版ごとに、成立するかを見る
   6. 🅲 手順4 — 古い版が断られるかを見る
   7. 🅲 手順5 — RSAだけを提示する相手でつなげるかを見る
   8. 🅲 手順6 — 結果を台帳に1行で残す
5. 05 明日、担当サイトで確認できることチェックリスト
6. 06 代替・他の選択肢 — 鍵の種類と鎖は、選べるところと選べないところがある
   1. 鍵の種類を変える前に、読むもの
   2. Let's Encryptが書く、ECDSAの鎖の選び方
   3. RSAとECDSAを選ぶときの、確かめられる範囲
7. 07 当サイトで確かめたこと — 鍵はECDSA、TLSは1.2と1.3だけ、RSAだけの相手はつなげない
   1. 手元のPCでは、本当の証明書を読めなかった
   2. 証明書の鍵の種類
   3. 証明書の鎖
   4. 受け付けるTLSの版
   5. これから確かめること
8. 08 このテーマは、ここまで — TLSの版と鍵の種類をめぐる記録
   1. 日付つきの流れ
   2. 当サイトの、関連する過去の記事
   3. 今回の記事の位置
9. 09 この記事のまとめ

01 何が書いてあるか — Keyless SSLは、ECDSA証明書ならTLS 1.3、RSA証明書ならTLS 1.2まで

Cloudflareは2026年10月30日、Keyless SSLがECDSA証明書でTLS 1.3に対応した、と更新記録に書いた。要旨はこうである。Keylessの接続でECDSA証明書を使うホスト名は、ゾーン（Cloudflareに登録したドメインの設定のまとまり）でTLS 1.3を有効にしていれば、TLS 1.3でつながる。秘密鍵は、これまでどおり利用者自身の鍵サーバーに残る。一方、RSA証明書を使うKeylessの接続は、TLS 1.2までのままである。

Keyless SSLは、Cloudflareに証明書を使わせながら、秘密鍵を自分の手元に置く仕組みである。この記事を読む人の多くは、これを使っていないと思う。それでも、この更新記録には、Keylessを使わない人にも通じる読み方が1つある。同じ製品の中で、証明書の鍵の種類（RSAかECDSAか）によって、届くTLSの版が変わる場合がある、ということである。自分のサイトの証明書がどちらの鍵か、サーバーがTLSのどの版を受け付けるかを、画面ではなく外からの接続で確かめる手順を、この記事の中心に置く。

3つの文書は何を書いているか

更新記録のほかに、Keyless SSLの文書と、TLS 1.3の設定の文書も開いた。3つの記述を、表にまとめる。

3つの文書を並べて分かるのは、効果の数字がどこにも無いことである。速くなる、安全になる、という書き方は、更新記録にも、Keylessの文書にも見当たらない。この記事も、そうした効果は書かない。書くのは、「どの鍵の種類だと、どのTLSの版まで届く」と文書が書いていることと、それを自分のサイトで確かめる方法である。

この記事で扱わないこと

Keyless SSLの導入の手順、鍵サーバーの作り方、料金は扱わない。文書の背景の記事を開いていないので、鍵サーバーが何をするかの説明も書かない。また、当サイトはCloudflareを使っていない。Cloudflareの画面を見た、設定を変えた、という話は、この記事には出てこない。

02 なぜ・背景 — 証明書の鍵の種類は、TLSの版の「前提」になりうる

接続のはじめに、サーバーは証明書で名乗る

ブラウザがHTTPSのサイトにつなぐとき、最初のやりとりで、サーバーは証明書を見せる。証明書の中には公開鍵が入っていて、その鍵の種類は、大きく分けてRSAとECDSAの2つが広く使われる。サーバーは、秘密鍵を使って、自分がその証明書の持ち主であることを示す署名を作る。この署名の方式を、接続の相手と合意する必要がある。

TLS 1.3の仕様（RFC 8446）の署名の方式を定める節は、ECDSAの方式（ecdsa_secp256r1_sha256など）と、RSAの方式（rsa_pss_rsae_sha256など）を、それぞれ別の名前で定めている。つまり、鍵の種類ごとに、署名の方式の名前が別に決まっている。この記事で筆者が読んだのは、その節の名前の一覧までで、細かい動作の説明は読んでいない。

鍵の種類が変わると、変わりうること

鍵の種類を変えるのは、証明書を取り直す作業である。変わりうるのは、つなげる相手の範囲（古い端末やソフトが、片方の鍵の種類にしか対応していない場合がある）と、サーバーやCDNがその鍵の種類で使えるTLSの版である（筆者の整理）。今回のKeylessの更新記録は、後者の話である。どちらも、画面の説明だけでは、実際につながるかが分からない。外から接続を試して、成立したか、断られたかを見るのが、いちばん確かな見方である。

TLS 1.0とTLS 1.1は、使ってはならない版になっている

TLSの古い版については、RFC 8996が、TLS 1.0とTLS 1.1を「廃止する」文書である。冒頭の要旨は、2つの版を正式に廃止すると書き、本文は、2つの版を使ってはならない（MUST NOT）と書いている。文書の年は2021年と表示されていたが、月は表示されていなかった。この文書は、TLS 1.2以上を最低の版にするよう、いくつもの古い仕様の記述を改めている。

そのため、サーバーがTLS 1.0やTLS 1.1の接続を受け付けるかどうかは、外から試して確かめる価値がある。受け付けないのが、いまの文書に沿った状態だからである（筆者の読み）。

03 用語 — 出てくる言葉を、先にそろえる

openssl s_clientの、この記事で使う指定

-servernameは、接続の最初にドメイン名を伝える指定（SNI）である。-tls1_2と-tls1_3は、使うTLSの版を指定する。-showcertsは、サーバーが見せた証明書を並べる。細かい挙動は、実際につないだ結果だけを根拠にする。

04 型別 — 誰に関係があるか、何が分からないか、どう確かめるか

🅰 適用範囲 — 今回の更新が直接かかわる人

更新記録がかかわるのは、CloudflareでKeyless SSLを使い、ECDSA証明書を出しているホスト名だけである。しかも、ゾーンでTLS 1.3が有効になっている場合に限る。Keylessを使っていないサイトは、この更新で何も変わらない。Cloudflareを使っていないサイトも、同じである。

一方、この記事の手順は、HTTPSのサイトなら誰でも使える。ただし、担当サイトがCDNの上にある場合、外から見える結果は、いちばん手前でTLSを受けている側の答えである（筆者の読み）。

🅱 この情報が測っていないこと

Cloudflareの更新記録は、いくつものことを書いていない。TLS 1.3になったことで、接続の速さがどう変わるかは書かれていない。何件のホスト名が対象かも書かれていない。ゾーンでTLS 1.3が既定でオンかどうかも、TLS 1.3の設定の文書は書いていなかった。更新記録は、Keylessの制限の節へ案内するだけで、制限の節の2文以外の条件は示していない。

この記事も、測っていないことがある。Keyless SSLを実際に使った経験はない。Cloudflareの画面で設定を見たこともない。当サイトの訪問者のうち、RSAだけに対応する端末の割合は、アクセスの記録から数えていない。

🅲 手順1 — 手元のPCで読んだ証明書を、そのまま信じない

最初の注意は、手元のPCでの確かめ方である。筆者が手元のPC（Windows）のopensslで当サイトの証明書を読むと、発行元がウイルス対策ソフトの名前になっていた。ウイルス対策ソフトが、通信の間に入って、証明書を作り直して見せていたのである。このとき、証明書の鍵の種類もウイルス対策ソフトの作ったものになるため、サイトの本当の証明書を読めたことにならない。

見分け方は、発行元の行（Issuer）を見ることである。担当サイトの証明書を出した認証局の名前ではなく、ウイルス対策ソフトや社内の機器の名前が出たら、別の場所からやり直す。筆者は、当サイトのサーバーの上から、当サイトの公開のドメイン名に向けて接続し直した。この方法で読んだ結果は、サーバーの外の公開の入口に向けた接続である。ただし、同じサーバーの中から出した接続なので、外の別の場所から見た結果と、同じとは限らない（筆者の読み）。

🅲 手順2 — 証明書の鍵の種類を読む

次のコマンドは、ドメイン名の部分を担当サイトのものに替えて使う。証明書を読み、鍵の種類、署名の方式、発行元、有効期間の行だけを残す。

HOST=example.com
openssl s_client -connect "$HOST":443 -servername "$HOST" </dev/null 2>/dev/null \
  | openssl x509 -noout -text \
  | grep -E "Public Key Algorithm|Public-Key|Signature Algorithm|Issuer:|Not (Before|After)"

ECDSAなら「id-ecPublicKey」と曲線の名前が出る。RSAなら「rsaEncryption」と鍵の長さが出るのが通例である。「Not After」は、証明書の有効期限である。

🅲 手順3 — TLSの版ごとに、成立するかを見る

TLS 1.3とTLS 1.2を、それぞれ指定して接続する。成立すれば、出力に「New, TLSv1.3」や「New, TLSv1.2」の行が出る。

openssl s_client -connect "$HOST":443 -servername "$HOST" -tls1_3 </dev/null 2>&1 | grep -E "New,|alert|error:"
openssl s_client -connect "$HOST":443 -servername "$HOST" -tls1_2 </dev/null 2>&1 | grep -E "New,|alert|error:"

🅲 手順4 — 古い版が断られるかを見る

TLS 1.0とTLS 1.1は、手元のopensslが試す前にあきらめる場合がある。その場合は、セキュリティレベルを下げる指定を付けて、サーバーまで届かせる。

openssl s_client -connect "$HOST":443 -servername "$HOST" -tls1_1 -cipher 'ALL@SECLEVEL=0' </dev/null 2>&1 | grep -E "New,|alert|error:"

サーバーが断ると、「alert protocol version」（訳: 通信の版が合わない、という警告）と出る。断られたのか、手元でやめたのかを、メッセージの文面で区別する。「no protocols available」は手元でやめた印で、サーバーの答えではない。

🅲 手順5 — RSAだけを提示する相手でつなげるかを見る

証明書がECDSAだけのサイトに、RSAの方式だけを出せる相手がつなぐと、どうなるかを試せる。署名の方式をRSAに限る指定と、RSAの証明書を使う暗号の組み合わせに限る指定の2つを、それぞれ試す。

openssl s_client -connect "$HOST":443 -servername "$HOST" -tls1_2 -sigalgs 'RSA+SHA256' </dev/null 2>&1 | grep -E "New,|alert|error:"
openssl s_client -connect "$HOST":443 -servername "$HOST" -tls1_2 -cipher 'ECDHE-RSA-AES128-GCM-SHA256' </dev/null 2>&1 | grep -E "New,|alert|error:"

成立しなければ、「handshake failure」（訳: 接続の交渉の失敗）という警告が出る。これは、相手がRSAしか出せないとき、そのサイトにはつなげないことを意味する。逆に、RSAの証明書も用意しているサイトなら、成立する。

🅲 手順6 — 結果を台帳に1行で残す

5つの試しの結果は、「成立」「断られた」「未確認」の3つの言葉で、台帳に1行ずつ書く。TLS 1.3とTLS 1.2が成立し、TLS 1.1が断られていれば、文書の勧めに沿った状態と読める。TLS 1.1が成立したら、設定を見直す材料になる。RSAだけを出す相手で成立しなければ、RSAしか出せない相手はそのサイトにつなげない、と読む（筆者の案）。

05 明日、担当サイトで確認できることチェックリスト

以下は、担当サイトの証明書の鍵の種類と、受け付けるTLSの版を、外からの接続で確かめて台帳に書く13項目である。1〜2番目は公式の文書の読み取り、3〜4番目は担当サイトの一覧づくりと運用者への確認、5〜11番目は接続の試し、12〜13番目は発行元の行の確認と記録の書き方である。1項目は5分以内でできる。チェックの状態は、お使いのブラウザに保存され、サーバーには送られない。

• Cloudflareの更新記録（2026年10月30日付）を開き、ECDSA証明書とRSA証明書で届くTLSの版が違う2つの文を、メモ帳に書き写す
• Keyless SSLの文書の制限の節を開き、書かれた2つの文と、ページの最終更新日（10月30日）をメモ帳に書き写す
• 担当サイトの一覧を開き、Cloudflareを使うサイトと使わないサイトに印を付けて、それぞれ何件かを数える
• Cloudflareを使うサイトについて、Keyless SSLを使っているかを運用者に1通のメッセージで聞き、返事を一覧の列に書く
• 担当サイトのうち1つのドメイン名を選び、手順2のコマンドで証明書の鍵の種類（RSAかECDSAか）を読んで、一覧に書く
• 同じドメイン名にTLS 1.3を指定して接続し、「New, TLSv1.3」が出たかを、成立か不成立かで一覧に書く
• 同じドメイン名にTLS 1.2を指定して接続し、成立か不成立かを一覧に書く
• 同じドメイン名にTLS 1.1を、セキュリティレベルを下げる指定を付けて試し、断られたか受け付けたかを一覧に書く
• 「no protocols available」と出た試しは、サーバーの答えではないので、結果の欄に「未確認」と書き、指定を変えて1回だけやり直す
• -showcertsで証明書の並びを出し、何枚が見えるかと、各段の鍵の種類を、一覧の別の列に書き写す
• 手順2で読んだ「Not After」から、有効期限までの日数を数えて、一覧に書く
• 発行元の行が、ウイルス対策ソフトや社内の機器の名前になっていないかを見て、なっていたら別の場所からやり直す印を付ける
• 試した日、試した場所（どの機械からか）、opensslの版を、一覧の末尾に1行で書く

06 代替・他の選択肢 — 鍵の種類と鎖は、選べるところと選べないところがある

鍵の種類を変える前に、読むもの

証明書の鍵の種類を変える判断は、サイトの運営者だけでは決まらないことが多い。ホスティング会社やCDNの文書に、対応している鍵の種類が書かれているからである。Cloudflareの更新記録のように、鍵の種類によって届くTLSの版が違う、と文書が書く場合がある。判断の前に、使っている会社の文書の「制限」「注意事項」の節を開く。節の名前は会社によって違うが、探す言葉は「ECDSA」「RSA」「TLS 1.3」の3つで足りる。

Let's Encryptが書く、ECDSAの鎖の選び方

証明書をLet's Encryptから受けている場合は、鍵の種類のほかに、鎖の選び方も関係する。Let's Encryptの証明書の説明（2026年7月8日更新）は、ECDSAの証明書の鎖の選択肢を3つ書いている。

説明のページは、別の鎖を選ぶには、証明書を取るソフトの文書を見るよう案内していて、例としてCertbotの--preferred-chainを挙げている。鎖の長さは、接続のときにサーバーが見せる証明書の数に関係する。ただし、鎖の長さが接続の速さにどう効くかは、説明のページには書かれていないので、この記事も書かない。

RSAとECDSAを選ぶときの、確かめられる範囲

鍵の種類の優劣を示す根拠は、この記事で開いた文書のどこにも無かった。確かめられるのは2つに絞られる。ECDSAだけにすると、RSAしか出せない相手がつなげなくなるかを、手順5で試せる。RSAだけにする場合は、使う会社の文書に版の制限が無いかを探せる（Keylessの例では、TLS 1.2まで）。どちらも、訪問者の何割に当たるかは、自社のアクセスの記録を見ないと分からない。

07 当サイトで確かめたこと — 鍵はECDSA、TLSは1.2と1.3だけ、RSAだけの相手はつなげない

2026年11月2日に、当サイトのドメイン名（website.usersupports.com）に向けて、この記事の手順を1回ずつ試した。当サイトはCloudflareを使っていない（耐量子の鍵交換は、CDNの画面が無くても確かめられる ── Cloudflareが見える化した項目を、自社サイトの接続で確認する14項目（2026年10月時点）にも書いた）ので、Keyless SSLは使っていない。確かめたのは、外に見える入口の答えだけで、サーバーの設定の中身は読んでいない。

手元のPCでは、本当の証明書を読めなかった

手元のパソコンでは、ウイルス対策ソフトが通信の間に入り、本物の証明書を読めなかった。証明書を読むと、鍵はECDSAだったが、発行元の行はウイルス対策ソフトの名前だった。当サイトの本当の証明書ではない。そこで、当サイトのサーバーの上から、同じドメイン名に向けて接続し直した。以下は、その結果である。

証明書の鍵の種類

• 公開鍵の方式: id-ecPublicKey（ECDSA）、256ビット、曲線はprime256v1
• 署名の方式: ecdsa-with-SHA384
• 発行元: Let's Encrypt（中間の証明書の名前はYE2）
• 有効期間: 2026年9月19日から2026年12月18日まで（90日間）。11月2日から12月18日まで46日

期限は12月18日である。更新がいつ行われるかは、この記事では確かめていない。更新の日数の決め方は、Let's Encryptの証明書は2027年2月10日から標準で64日になる ── 更新の設定の「日数の決め打ち」とARI対応を確かめる13項目（2026年10月時点）に書かれている。

証明書の鎖

サーバーが見せた証明書は4枚だった。1枚目が当サイトの証明書（ECDSA、256ビット）、2枚目がYE2（ECDSA、384ビット）、3枚目がRoot YE（ECDSA、384ビット）、4枚目がISRG Root X2（ECDSA、384ビット）である。Let's Encryptの説明が書く、ECDSAの既定の鎖（YEを経由してX2、X1と続く）と、並びが合っている。

ここで気づくのは、4枚目のISRG Root X2の証明書だけ、署名の方式がRSA（sha256WithRSAEncryption）だったことである。鍵はECDSAでも、この1枚は、RSAの鍵を持つISRG Root X1が署名している。「鎖がすべてECDSA」と書きたくなるが、署名まで見ると、1段だけRSAがまじっている。鍵の種類を台帳に書くときは、サーバーの証明書の鍵と、鎖の署名を別の列にすると、こうした混在が見える。

受け付けるTLSの版

TLS 1.1とTLS 1.0は、最初、レベルを下げる指定が無い状態で試すと、「no protocols available」と出た。これは手元のopensslがあきらめたもので、サーバーの答えではない。指定を付けてやり直すと、サーバーから断られた。ここで区別を付けなかったら、「断られた」とは言えなかった。

RSAだけを出せる相手がつなげない、という結果から、当サイトはRSAの証明書を出す構成ではない、と読める（筆者の読み）。この構成の影響が、訪問者のうちどれだけに及ぶかは、アクセスの記録から数えていない。

これから確かめること

次の2つは、まだ実施していない。1つ目は、12月18日の期限の前後に、証明書が更新されても、鍵の種類（ECDSA）と鎖の並びが変わらないかを、同じ手順で読み直すことである。2つ目は、アクセスの記録に、TLSの版を残す設定が無いかを調べ、無ければ、RSAだけの相手がつなげないことの影響を数える方法を決めることである。結果は、この記事の末尾に、日付つきで書き足す。

このほか、当サイトが証明書の信頼の経路を確かめた記録は認証局の中間証明書8枚の秘密鍵が漏れた週、当サイトのサーバーの中からつなぐ通信は、漏れた証明書を通していた ── AIの知らせを自分で測り直して、塞いだ記録にある。外へ出る通信と入ってくる通信は別の話だが、サーバーの上から自分の入口を確かめるという手順は、共通している。

08 このテーマは、ここまで — TLSの版と鍵の種類をめぐる記録

日付つきの流れ

• 2018年8月: TLS 1.3の仕様、RFC 8446が出た。署名の方式を、ECDSAとRSAなどで別々に定めている。
• 2021年: RFC 8996が、TLS 1.0とTLS 1.1を廃止した（月は、読んだページには表示されていなかった）。
• 2026年10月30日: CloudflareがKeyless SSLのECDSA証明書でのTLS 1.3対応を更新記録に書き、Keyless SSLの文書も同じ日に更新された。
• 2026年11月2日: この記事のために、文書を開き、当サイトの入口を外から読んだ。

RFC 8446は、いまではRFC 9846に置き換えられたと、ページに表示されていた。仕様の文書そのものも、書き換わっている。

当サイトの、関連する過去の記事

• 耐量子の鍵交換は、CDNの画面が無くても確かめられる ── Cloudflareが見える化した項目を、自社サイトの接続で確認する14項目（2026年10月時点）: 同じ入口に、ブラウザの開発者ツールで接続し、鍵交換の名前を読んだ記録。この記事は、証明書の鍵の種類とTLSの版を、opensslで読んだ。
• 認証局eMudhraの中間証明書8枚の秘密鍵が漏れた。テスト用サイトによればブラウザは遮断済みで、残るのはブラウザの外の通信 ── 自社と担当サイトの信頼の経路を確かめる13項目（2026年10月時点）: 証明書の信頼の経路を数えた記録。
• HTTPSは「ごく軽い」順位の信号として始まり、いまの文書は正規URLに選ぶ条件を書く ── http→httpsの転送で確かめる13項目（2026年10月時点）: HTTPSの入口を、転送で確かめた記録。
• PHPの2件の脆弱性が悪用リストに載り、期限は10月29日だった ── 期限の日に当サイトで確かめた4つと、自分の記事の言い過ぎ、期限を自分のサイトの期限に読み替える方法: 公式の文書を、期限の日に当サイトで確かめ直した記録。

今回の記事の位置

これまでの記事は、証明書の信頼や、更新の日数に重きがあった。今回は、鍵の種類と、受け付けるTLSの版という、接続の入口の姿を外から読む記事である。担当サイトの一覧の作り方は、PHPの修正版が出た日に「どのサイトが当たるか」を数分で答えるには、担当サイトの一覧が要る ── 台帳の8列を埋めて確かめる13項目（2026年10月時点）にある。この一覧に、「鍵の種類」と「TLSの版」の列を足すと、今回の確認が台帳の中で続けられる。

🔧 WEBサイト総合分析・レポートツール — 公開ページの状態をまとめて確認するは、公開ページを見るための入口になる。このツールが、TLSの版や鍵の種類まで読むかは、この記事では確かめていない。使う前に、ツールのページの説明を読んでほしい。

🔧 WEBサイトの外からできるセキュリティ対策監査ツール（要ログイン） — 外から見える設定の点検に使うは、ツールの紹介文によれば、SSL/TLSの包括分析として、証明書・プロトコル・暗号スイートを調べる。この記事の手順は、手元のopensslで読む形なので、ツールの結果と見比べるときの材料にできる。