イベントレポート
Internet Week 2025
SSL/TLSサーバー証明書の有効期間が398日→47日に短縮へ。サイト管理者はどうすればいい？
「耐量子計算機暗号」移行によるDNSSECへの影響は？ 毎年恒例「DNS DAY」の話題から
2025年12月23日 10:55
「Internet Week 2025」において、DNS（Domain Name System）に関する話題を集めたプログラム「DNS DAY」が11月26日に開催された。本レポートでは、その盛り沢山の話題の中から、恒例となっているセッション「DNS Update」のほか、「SSL/TLSサーバー証明書の最長有効期間の短縮」と「耐量子計算機暗号（PQC：Post-Quantum Cryptography）移行によるDNSSECへの影響」という2つの話題を取り上げる。
なお、暗号関係の話題の理解には、関連する専門用語・知識に関する理解が必要である。そうした用語・知識になじみのない読者にも内容をご理解いただくため、本レポートでは関連する知識や背景などを先に解説した後、筆者が大事だと感じた部分を重点的に取り上げるかたちで解説を進めることとした。そのため、発表スライドの一部を発表順から入れ替えている箇所があるが、その点についてはあらかじめご承知いただきたい。
［目次］
SSL/TLSサーバー証明書の有効期間の段階的な短縮が決定、管理の自動化を推奨
最初に、セコム株式会社の伊藤忠彦氏による「WebPKIの最新動向と今後の見通し」の発表から、SSL/TLSサーバー証明書（以降、単に「サーバー証明書」と略す）の最長有効期間短縮に関する話題を取り上げる。本件に関するポイントは、以下の通りである。
- サーバー証明書の最長有効期間が段階的に短縮される
- 最長有効期間は2029年3月には47日に短縮され、月次の更新が想定されている
- 有効期間の短縮に確実に対応するためには、自動化への対応が必須となる
サーバー証明書は、「申請者がそのドメイン名の利用権を有していること」や「申請者の組織が実在していること」を証明し、「証明書が設定されたWebサイトとの通信の暗号化」を実現する、インターネットを安全に利用するうえで必須のアイテムである。多くの一般利用者は、Webサイトとの通信をHTTPS化する際に必要なものだと思っているのではないだろうか。
そのサーバー証明書の最長有効期間が、段階的に短縮されることが決定した（図1）。今年（2025年）4月にサーバー証明書を発行する認証局（CA：Certificate Authority）と、サーバー証明書を認証に利用するブラウザーベンダーで構成される業界団体であるCA/Browserフォーラム（The Certification Authority/Browser Forum）において、サーバー証明書の有効期間の段階的な短縮に関する投票が行われ、賛成多数で（反対票はなかったが、5つの認証局が投票を棄権した）可決されたためだ[*1]。
CA/Browserフォーラムの発足以来、サーバー証明書の最長有効期間は段階的に短縮され、現在は398日になっている。それが3つの段階を経て、さらに47日まで短縮される。CA/Browserフォーラムに本件を提案したAppleの担当者からは47日の根拠として「1カ月の最長日数（31日）＋1カ月の半分（15日）＋1日の余裕」が示されており、月次での更新が想定されている。
今回の提案はインターネットを「より安全に」するためのものであるが、従来は年次であったサーバー証明書の更新が月次になるということは、サーバー証明書を発行する側にもWebサイトを運用する管理者にとっても、現在の仕組みに手を入れる必要が出てくることになる。なお、図1で「証明書有効期間」の右にある「DCV再利用可能期間」は、ドメイン名権限確認（DCV：Domain Control Validation）[*2]の再利用期間も今回の最長有効期間の短縮に合わせて短縮されることを示している（この期間は、サーバー証明書を期間内に再発行する際に意味を持つことになる）。
サーバー証明書のDCVについては、これに加え、電話や電子メールによる確認手法が、段階的に廃止されることが決まっている（OV証明書における組織の実在性確認では、電話による方法も引き続き有効であることに注意されたい）。2025年7月15日以降にWHOISのコンタクト情報に記載された電子メールアドレスをDCVの情報源として用いることが禁止されたことを覚えている読者もいらっしゃると思うが、その後、電子メールを使用したDCVそのものが、2028年3月までに段階的に廃止されることがCA/Browserフォーラムの投票により決定したのである（図2）。
認証局のDCVにおけるDNSSECの取り扱いも変更される。伊藤氏によると、これまではDNSSEC検証に失敗する状態であっても（認証局側がDNSSEC検証をオフにした状態でDCVを確認できれば）認証局の判断で証明書を発行できたが、2026年3月以降は「そのドメイン名でDNSSECが適切に設定されていること」、すなわち申請者が自分のドメイン名をDNSSECに対応させた場合、DNSSECが適切に設定されていないと、認証局は証明書を発行できなくなる（図3）。言い換えれば、証明書発行時の認証局におけるDNSSEC検証が必須になるため、申請者が自分のドメイン名をDNSSECに対応させた場合の認証局のDCVが厳格化される、ということを示している。
業界団体であるCA/Browserフォーラムの決定には、全ての認証局が遵守を求められる。今回の最長有効期間の短縮には主要ブラウザーベンダーであるGoogle、Microsoft、Apple、Mozillaが全て賛成票を投じており、実施期限までの対応が事実上、必須となっている。Internet Week 2025後の情報として、無料で使用できることから人気の高いLet's Encryptを運営するInternet Security Research Group（ISRG）が12月2日に、同社が発行する証明書の有効期間を2028年までに45日間に短縮するという発表[*3]を行ったことを付け加えておく。
伊藤氏は、「これらの決定は自動化を推し進め、サーバー証明書のより安全な運用を実現するためのものである」と述べ、そのほかにも、サーバー証明書にクライアント認証（clientAuth）の用途（EKU）を含めることを禁止すること（図4）や、失効検証や大量失効に関する話題を説明した（図5～図7）。
伊藤氏のもう1つの話題、「PQC移行の見通し」については本レポートでは紹介しないが、興味深いスライドがあったので、ここで紹介しておく（図8）。
このスライドにあるグラフは、サーバーに届いたQUICのリクエストを分析したものとのことであるが、非常に短い期間でQUICのバージョンが上がっていることが視覚的に理解できる。ChromeブラウザーにおけるQUICの実装はOSではなくユーザーランド[*4]で行われているということもあるが、それにしても早い。このスピード感で対応できるのであれば、Googleなどのブラウザーベンダーがサーバー証明書の最長期間短縮への対応も可能であると考えることもできるかもしれない。
さて、では、証明書を必要とする管理者や認証局はどうすればよいのであろうか。その答えは、図1で示したスライドの一番下に書かれていること、そのものであろう（図1を再掲）。すなわち、サーバー証明書の更新を含む、証明書の管理を自動化することである。
ではどうやって、という点については本レポートの範囲を超えるので、参照ポイントのみを紹介しておく。少し前の記事になるが、「Internet Week 2017」で行われ、DNSとサーバー証明書の関係について取り上げた株式会社日本レジストリサービス（JPRS）による「ランチのおともにDNS」のレポート[*5]と、その際に使用されたPDF[*6]をご覧になるのが良いと思う。
ここでのポイントは、証明書の自動更新を実現するためには「自動証明書管理環境（ACME：Automatic Certificate Management Environment）」[*7]への対応が重要であるという点である。ACME（アクミー）は、その名の通り証明書の管理を自動化するためのプロトコルである。こちらの資料は概要のみであるため、仕組みを理解した後、さらに必要な資料を探し、理解を深めることが重要である。
[*1]…… Voting Period Begins: SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods
https://groups.google.com/a/groups.cabforum.org/g/servercert-wg/c/bvWh5RN6tYI
[*2]…… サーバー証明書の発行手続きにおいて、証明書を発行する対象のドメイン名が実際にその証明書の申請者によって管理されていることの確認。サーバー証明書を発行する認証局が実施し、証明書の発行前に対象のドメイン名の権限を確認するという重要な役割を担う。
[*3]…… Decreasing Certificate Lifetimes to 45 Days
https://letsencrypt.org/2025/12/02/from-90-to-45
[*4]…… ユーザーランドとは、OSの中で中核となるカーネル（Kernel）の外にあるソフトウェア領域のこと。一般ユーザーの権限で操作できる領域であることから、そう呼ばれる。代表的なものに、シェルやコマンドがある。
[*5]…… 変化するDNSとサーバー証明書の関係～「ランチのおともにDNS」より
https://internet.watch.impress.co.jp/docs/event/1095814.html
[*6]…… 向き合おう、DNSとサーバー証明書～DNSとサーバー証明書の最近の関係を踏まえ、DNS運用者がすべきこと～ランチのおともにDNS
https://jprs.jp/tech/material/iw2017-lunch-L3-01.pdf
[*7]…… ACMEについて
https://jprs.jp/pubcert/about/ACME/
耐量子計算機暗号（PQC）移行は、DNSインフラのキャパシティ耐性への挑戦である
次に、耐量子計算機暗号（PQC）移行によるDNSSECへの影響の話題を、GMOコネクト株式会社の菅野哲（かんの さとる）氏による「耐量子計算機暗号（PQC）暗号移行と『暗号の2030年問題』：DNSの現状と未来」の発表から取り上げる。本件に関するポイントは、以下の通りである。
- 実用的な量子計算機の登場により、現在の公開鍵暗号方式で使われているアルゴリズムの安全性が脅かされる可能性が高くなっている
- 暗号アルゴリズムの安全性については、米国のNIST（後述）による基準が事実上のスタンダードとなっている
- NISTは、現在主流となっている暗号アルゴリズムが危殆化（保護の対象が危険にさらされること）する時期を、2030年ごろと予想している
- 現行の暗号アルゴリズムが危殆化する前に、耐量子計算機暗号（PQC）に移行することが重要になる
- その際、DNSSECにおいてDNSデータの肥大化や計算量の増加といった課題が発生する。こうした課題にどのように向き合うかが、DNS関係者にとって特に重要になる
DNSSECには「公開鍵暗号方式」と呼ばれる暗号技術が使われている。現在、広く使われる公開鍵暗号の安全性は、素因数分解や離散対数問題などの計算困難性（既知の最良手法でも現実的な時間では解けないという仮定）に基づいている。DNSSECではこの特性を、「DNSSEC署名を作成できるのはそのゾーンの秘密鍵を持つ者、つまり、そのゾーンの管理者のみであり、それ以外の者は署名を作成できない」という点に利用している。
一方、計算機の性能の向上や新しい攻撃・解読アルゴリズムの開発により、暗号アルゴリズムの安全性は時代とともに変化する。そのため、さまざまな専門組織や機関がアルゴリズムの安全性を評価し、利用のガイドラインの見直しを行っている。
現在、DNSSECで広く用いられている署名アルゴリズムには、合成数𝑁=𝑝𝑞（大きな2つの素数の積）の素因数分解が困難であること（および関連するRSA問題の困難性）に基づくRSAと、楕円曲線暗号（ECC）の署名方式で、楕円曲線上の離散対数問題（ECDLP）の困難性に基づくECDSAがある。
アルゴリズムや使用する鍵ペアの鍵長の安全性については、各国・各地域の関係団体が評価結果を発表している。中でも、米国立標準技術研究所（NIST：National Institute of Standards and Technology）が作成・公開する基準は広く信頼されており、事実上の標準となっている。
本題に入るが、「暗号の2030年問題」は、2030年ごろに実用的な量子計算機が登場し、現在主流となっている公開鍵暗号方式であるRSAやECCが効率的に解読できるようになることで、それらを用いた暗号や電子署名の安全性が脅かされる可能性があるというものである。「誤り訂正機能を有する量子ゲート型量子計算機（CRQC：Cryptographically Relevant Quantum Computer）」の登場と、米国の数学者ピーター・ショア氏が考案した「ショアのアルゴリズム（Shor's algorithm）」と呼ばれる素因数分解問題を効率的に解くアルゴリズムが登場したことで、現実の問題として認識されるようになった。
RSAやECCといった現代の暗号方式の安全性は数学的な特性、つまり計算困難性に基づいている。それが実用的な時間で解読されてしまうとなれば、それらの暗号方式の安全性が、根本的なところで脅かされることになる。
菅野氏は、暗号の2030年問題には「128bit安全な暗号への移行」と「PQCへの移行」という2つの側面があるとした。1つ目は、現在利用されている112bit安全な暗号を、計算機の性能の向上や新しい攻撃・解読アルゴリズムへの対策として128bit安全な暗号に移行することである。RSAであれば鍵長を長くした「RSA-3072」や「RSA-4096」への移行がそれに相当するが、RSA-3072やRSA-4096では鍵や署名のサイズが大きくなるため、実用上の問題が生じる。また、CRQCの登場により現行暗号が容易に解読されてしまうため、2つ目の量子計算機でも解読できないとされているPQCへの移行が、対応策として浮上している（図9）。
では、CRQCによる現行の暗号方式への影響はどのように評価されているのであろうか。図10で示したスライドの中央やや下側に赤枠で示された部分を見てほしい。RSAやDSA/ECDSAの現行暗号に対する脅威は「非常に大きい」となっている[*8]。
[*8]…… 写真では、DSA/ECDSAの暗号に対する部分は空欄のように見えるかもしれないが、実際のスライドでは1つの枠となっている。
Moscaの定理によれば、暗号が安全であるためには、「暗号方式の移行にかかる期間」と「データの寿命／保護期間」の合計が「脅威が現実化するまでの期間」より短い必要がある。もし、脅威が現実化する時期が早く訪れると暗号が脅威にさらされる期間が発生し、長期間に及ぶ可能性がある（図11）。現時点での予想は、2035年前後であるということである（図12、図13）。
ソフトウェアのデプロイをした経験があれば、ある技術が世の中に普及していくためには長い年月がかかることをよく知っていると思う。菅野氏のスライド（図14）は一例だが、CRQCによる現行暗号への影響に対応するための時間は決して多くないのは確かであろう。
図15は、米国の国家安全保障局（NSA：National Security Agency）によるPQCへの移行計画であるが、早め早めの対応を進めているのが見て取れる。これは、攻撃者がHNDL（Harvest Now, Decrypt Later）と呼ばれる「（暗号化されたデータを）今のうちに収集し、あとで解読する」という攻撃手法を使うことが予想されており、その脅威に対応するためのものでもある。
続く図16は、NISTが標準化を進めているPQCアルゴリズム「FIPS（Federal Information Processing Standards）」に関するまとめである。本レポートでは個々の説明は行わないが、FIPS 203は公開鍵暗号方式、FIPS 204～206は電子署名で使われることが想定されている。菅野氏は、FIPSには格子暗号（Lattice-based Cryptography）を採用したものが多いと述べている。
DNS関係者にとって特に重要なのは、ここからであろう。図17は、PQCアルゴリズムとそのデータサイズを比較したものである。128bit安全相当の強度だが、いずれもそれなりに大きなサイズとなっている。図18にまとめられているが、DNSのデータサイズが大きくなると、IPフラグメンテーションの問題によるUDPを使うことの限界や、大きな応答をDNSリフレクター攻撃などのDDoS攻撃に利用されるなどの問題が頭をもたげることになる。もちろん、DNSSEC署名や署名検証のための計算量の増大も考慮しなければならない。
図20は、公開情報をベースにリソースの観点から比較をしたもので、帯域やストレージやキャッシュ、CPUの負荷が軒並み上昇している。つまるところ、PQCへの移行は図21にあるように、DNSインフラのキャパシティ耐性への挑戦であり、DNSの在り方そのものをも問うものであるということになる。DNS関係者はそれに向き合い、備えなければいけない。今後の動向を注視すべきであろう。
DNS Update――DELEG RRの標準化作業の進め方が決まる
恒例の「DNS Update」。最初の報告は、慶應義塾大学／WIDEプロジェクトの加藤朗氏による「Root DNS Update」である。
加藤氏からは、現時点でのルートサーバーのサイト数[*9]が1558となり、さらに増えたこと（2024年11月時点では1528であった）、IP Anycastが適用されており、1地点が消滅しても大きな影響がないこと、Mルートサーバーの現在などについての説明が行われた（図22）。
また、来年（2026年）10月11日にルートゾーンのKSKロールオーバーが予定されていることが、あらためて説明された。DNS関係者は、自分が管理しているフルサービスリゾルバーの状態やサーバーソフトウェアがRFC 5011[*10]によるトラストアンカーの自動更新をサポートしているかといったことなどを再度確認しておいてほしい。
[*9]…… サーバーの数ではないことに注意。
[*10]…… RFC 5011「DNSセキュリティ拡張（DNSSEC）におけるトラストアンカーの自動更新」（JPRSによる日本語翻訳）
https://jprs.jp/tech/material/rfc/RFC5011-ja.txt
続いて、JPRSの池田和樹氏による「JP DNS Update」では、jpゾーンを管理するJP DNSの状況に関する報告が行われた。
池田氏からは、JPドメイン名の登録数は増加傾向が続いており、JP DNSへのクエリ数の伸び率も増加していること（図23、図24）、総クエリ数に対するIPv6で到達したクエリ数の比率は、ここ数年30％程度の状態が続いていること（図25）、G.DNS.JPグローバルノードのJPRS関西拠点が追加されたこと（図26）などが伝えられた。
一般社団法人日本ネットワークインフォメーションセンター（JPNIC）の塩沢啓氏による「逆引きDNS Update」では、逆引きDNSにおけるlame delegationの改善に関する報告が行われた。
lame delegationは、DNSにおいて委任先の権威DNSサーバーが委任されたゾーンの情報を適切に返さない状態を示す用語である。塩沢氏からは、「皆さまのご協力のおかげでlame delegationの割合は、おおむね0.2％から0.3％の範囲にとどまっている」ことなどが報告された（図27）。
JPRSの藤原和典氏による「IETF Update」では、IETFにおけるDNS関連WGの動向や話題に関する報告が行われた（図28）。今回はその中から、DNSの委任を再設計するDELEGリソースレコード（RR）に関する話題を取り上げる。
藤原氏は、DELEG RRに対する期待は大きいが、現状のドメイン名登録モデルを壊さないことも重要であるとし、IETF 122において、複数の提案のうちIETF 118 Hackathonで誕生した最初のDELEG案に近いものが選定されたことが説明された。そして、今後の標準化作業の進め方として、まず従来の委任の置き換え・併存を実現する基本部分の標準化作業を進め、DELEGならではの機能の追加はその後にすることが合意されたことが示された（図29）。
興味深いというか、個人的に良かったと感じるのが「in-domainの委任である場合はIPアドレスのみを指定（サーバー名を書いてはいけない）」「sibling domain、unrelatedの委任である場合には委任先のサーバー名のみを指定（IPアドレス＝グルーレコードの排除）」という仕様になる見込みになったことである（図30）。「NS方式からの改良は、親ゾーンにあるDELEG RRに署名できることと、親子ともにNS RR、A/AAAA RRがあることの解消のみである」とのことであるが、委任において委任先の権威サーバーのIPアドレスが必要になる条件が、明確で分かりやすくなる見込みであることは、素直にありがたいと思う。他の項目も含む、藤原氏によるまとめ（図31）も紹介しておく。
NTTドコモビジネス株式会社の小坂良太氏による「フルサービスリゾルバーUpdate」では、OCNのフルサービスリゾルバーに到達するクエリとレスポンスを分析した結果が報告された。
長期的な傾向としてクエリ数の伸びは継続中であるが、昨年と比べて緩やかになったということである（図32）。そのクエリにおけるクエリタイプの割合だが、やはりA、AAAA、HTTPSの各RRが大半（合計すると約97.5％）を占める（図33）。ただし、その中でもA RRのクエリの増加率が高く、小坂氏は「PCやスマホ以外の（IPv6非対応かつHTTPSレコードを利用しない）端末、例えばIoT機器が増加したからではないか」と推測しているとのことであった（図34）。A、AAAA、HTTPS以外のクエリタイプについては、ANYタイプのクエリ数が2倍に増加していることから、サイバー攻撃に使われている可能性があると考えているとのことであった（図35）。なお、IPv4/IPv6のトラフィックの割合は2017年からのIPoEサービス提供に伴いIPv6の割合が急増し、現在ではIPoE（IPv6）のDNSクエリの割合は70％を超えていることも示された（図36）。
また、今回、ユーザーからのクエリに対するレスポンスをレスポンスコード（RCODE）ごとに集計してみたところ、エラーがないNOERROR（NODATA含む）が92％を占める一方、指定されたドメイン名が存在しないことを示すNXDOMAINが6％程度あったとのことである（図37）。悪用も含め、第三者が何らかの理由でドメイン名をスキャンする場合もあることから、NXDOMAIN応答がある程度発生することは不思議ではないが、全体の6％はやや多い気もする。数は少ないが、サーバー側の理由で名前解決に失敗したことを示すSERVFAILと、DNSパケットのフォーマットに異常があることを示すFORMERRが昨年と比べ、3倍ほどに増加しているとのことであった。このような生きた統計情報は、見ていて面白いと感じる（図38、図39）。
DNS Updateの最後を務めたJPRSの高松百合氏による「ドメイン名Update」では、gTLDを含むドメイン名全般に関する報告が行われた。
gTLDの登録数については1億8790万から1億8980万と少し増えたが、相変わらず「.com」ドメインの登録数が圧倒的である（図40、図41）。トップ10については10位に変動があり、「.xyz」が返り咲いている（図42、図43）。ただし、注目したいのはその更新率である。なんと、22.2％とのことで、いくら何でも低すぎるのではないだろうか。つまり、.xyzでは多数のドメイン名が「使い捨て」されていることになり、かなり悩ましいところである。
高松氏の発表にはそのほかにも話題が多いが、本レポートの最後として、.comのレジストラ向け提供料金に関する動向を取り上げる（図44、図45）。詳細はスライドを見てもらえば分かると思うが、2024年12月1日付でICANNはVerisignとの.comレジストリ契約を2030年までの6年間というかたちで更新した。この契約更新によって、今後の.comの提供料金については、2025年と2026年は値上げできないが、2027年から2030年の間は毎年7％以内での値上げが可能となっている。
イベントに参加するメリットは大きい
今回のレポートは、暗号技術という現在のインターネットに欠かせない要素についての話題を丁寧に解説することを心掛けた。伊藤氏と菅野氏の資料は盛り沢山で、どこをどう取り上げるかについて悩んだほどである。長々としたレポートとなってしまったが、お読みいただけたことに感謝したい。
また、今回取り上げなかったNTTドコモビジネス株式会社による2つの発表、「サブドメインテイクオーバーの仕組みと実践的な対策について」と「続・ドメイン名終活 ～使い終わったドメイン名１年の観測分析から見えたリスクと対策～」もとても興味深かった。特にドメイン名の終活については、大きい組織だから問題になることと、大きい組織だからできることの両面性がある。逆に見ると、小さくて風通しが良い組織なら、この部分やあの部分は改善できるのではないかと感じる部分もある。ただ聞くだけでなく、自分が使っている環境を想定して考えてみると面白いと思う。
いつも最後に述べているが、DNS DAYの会場で参加していると周囲のリアクションが見られるし、知り合いの参加者がいればその内容について雑談できたりもするので、いろいろと得られるものが多い。加えて、参加者特典として、話者が使った資料にすぐにアクセスできるというのはとてもありがたい。暗号に興味を持った方、サーバー証明書やDNSSECの管理運用に関係する方は、伊藤氏と菅野氏の資料をよく読んでいただくことをお勧めする。今回も、筆者自身あらためて確認できたことも多く、とてもためになった取材となった。話者の皆さまに感謝したいと思う。