ハクソク

世界を動かす技術を、日本語で。

IPアドレス証明書の発行準備をする

334日前原文(community.letsencrypt.org)

概要

Let's Encryptが IPアドレスSAN証明書 発行の準備を進行中。 現時点では shortlivedプロファイル （有効期間6日）のみで提供予定。 当面は 許可リスト（allowlist）限定 運用を継続。 一般公開や 許可リスト申請 の受付は未定。 テスト用証明書と サンプルサイト も公開済み。

Let's EncryptのIPアドレスSAN証明書発行準備状況

  • Let's Encryptが IPアドレスSAN（Subject Alternative Name） を含む証明書の発行準備を進行
  • shortlivedプロファイル のみで対応、証明書の有効期間は 6日間
  • 発行対象は 許可リスト登録済みの利用者 に限定
  • 一般公開前の段階であり、 スケジュールや申請受付は未定
  • テスト用証明書（ abadcafe.txt）と、サンプルサイト（ https://[2602:ff3a:1:abad:c0f:fee:abad:cafe]/）を公開
  • 利用者に対し、 バグや不具合報告 を呼びかけ
  • Firefoxにおける IPアドレスSAN表示の不具合 （BZ #1973855）を確認
    • ブラウザ側の対応状況も今後の課題

shortlivedプロファイルの特徴

  • 有効期間が6日間 と極めて短い
  • セキュリティ強化 や証明書管理の簡素化を目的
  • 利用には 許可リスト登録 が必須
  • 通常の証明書発行とは異なる 運用フロー となる

今後の展望と注意点

  • 一般公開までの作業 が複数残存
  • 許可リスト申請受付の開始時期は未定
  • サンプルサイトや証明書を利用した 検証・フィードバック の重要性
  • ブラウザやクライアント側の IPアドレスSAN対応状況 の継続的な確認

まとめ

  • Let's Encryptは IPアドレスSAN証明書の発行 に向けて着実に進展
  • 現状は 限定的なテスト段階 であり、一般利用には今しばらく時間を要する見込み
  • 利用希望者や開発者は 今後の発表や進捗情報 に注目

Hackerたちの意見

面白いね。XMPPのフェデレーションがこんな証明書でうまくいくのかな。

└

ホストにIPだけを使ってる公開XMPPサーバーってあるの？聞いたことないけど、内部ではそういうのがあるかもしれないね。

技術的にはどうなるか分かるけど、具体的な使い道は何なんだろう？

└

主に趣味でやってる人たちや、プロジェクトにホスト名を結びつけたくない一回限りのケースが多いんじゃないかな。

└

"オポチュニスティック" DoTLSをauthdnsサーバーに向けるのは面白いかもね。authdnsサーバーのパブリックIPに合ったSANを含む証明書でDoTLSポートをリッスンしてるかもしれないし。（今はauthdnsサーバーのホスト名でできるけど、1つのパブリックauthdns IPに対して色んな名前があるから、これでより明確に結びつけられるかも。）

└

インフラにDNSエントリーがない機器が結構あると思うから、これは仕事で活用できそう。

└

一般的ではないけど、バニティIPのケースはあるよ。https://1.1.1.1の証明書は、IPとドメイン名one.one.one.oneの両方に対して署名されてる。

└

DNSが大規模に再設計されている間に有効な証明書を持っていたいこともあるよね。例えば、ダッシュボードを使えるようにしたり、DNSの問題で古い自動化が失敗しないように三重に確認したり。場合によっては、DNSが全く必要ないこともある。シンプルさやDNSの伝播からの独立を重視するなら、テスト環境でCockpitをすぐに公開できるよね。ここでは想像力だけが制限だね。

└

他にも良いユースケースを持ったレスポンスがたくさんあるけど、NTSについては見なかったな。NTSを使いたいけどIP証明書が取れないなら、信頼できる時間を得るためにDNSが必要になるよね。DNSがダウンしていると、時間を取得できない。DNSSECの一般的な問題は、間違った時間を持つことで、検証失敗を引き起こすことだよ。DNSSECが強制されていて間違った時間を持っていると、NTSがDNSに依存している場合、回復する方法がなくて運が悪いことになる。証明書の一部としてIPを持つことで、DNSの要件なしに信頼できる時間を得られるから、壊れたDNSSECの強制を修正できるんだ。

└

ESNI/ECHだけでも大きな話だね。暗号化されたサーバー名インディケーション（ESNI）に対する主な反論の一つは、Cloudflareのような巨大なHTTPSプロキシサービスにしか効果がないってことだった。IP証明書のアイデアが提案されたけど、夢物語として却下されたんだ。IPアドレス証明書があれば、今やすべてのサーバーがESNIに参加できるようになるから、巨人だけじゃなくなる。もしクライアントがすべてのウェブサーバーがIP証明書を持っていると仮定して、すべての接続でESNIを使おうとするようになれば、インターネット全体のプライバシーにとって大きな恩恵になるかもしれないね。

└

ローカルや開発環境での作業には便利かもね。my-dev-env.staging.service.comとか設定しなくてもHTTPSをテストできるし。

└

一つの使い道は、ホスト名を使わずにDoT（TLS経由のDNS）サーバーに直接接続することだね。OpenSSLを使ってIPアドレスにTLS接続をすると、IP SANを検証して、そこにないと失敗するよ。

└

ICANNのドメイン名システムから解放されるのが助けになるよ。これによって、競合他社も自己署名証明書なしでHTTPSをサポートできるようになる。

またCVE-2010-3170を引っ張り出す時が来たかな？ :-)

└

「自分でX.509バリデーションをやる」ロジックにはそのバグがあるだろうけど、それを悪用するには、ちゃんと動かないCAがその証明書を発行しないといけないから、可能性は低いね。

面白いね、見せられた証明書の例には主題がないんだ。これは、証明書がIPのためにリクエストされたからで、他のDNSエントリがSANの一部になってるからかな？

└

私たち（Let's Encrypt）は、主題の共通名を廃止して、主題の代替名だけを使う方向に進んでいるよ。この変更は短命（6日間）の証明書プロファイルに適用されたけど、「クラシック」プロファイル（90日間）にはまだ適用されていないんだ。

これはパブリックIPアドレス用みたいで、プライベートRFC1918のIPv4範囲アドレスではないね。考えられる課題はHTTPとTLS-ALPNだけで、DNSではないから、IPを所有している証明はLetsEncryptがそのIPにアクセスできることなの？

└

うん、ドメイン名の管理をチェックするのと同じ方法だね。DNSはターンキーとして使えないから、少数のケースでしか使われないよ。

└

DNSがあっても「証明」にはならないよ。申請者がどの証明の形を提供するかを選べるから、選択肢を増やすことは「証明」を簡単にするだけだと思う。

じゃあ、すべてのアドレス機関（ISPやクラウドプロバイダーなど）は賛成してるってこと？彼らは時々IPをすごい速さで切り替えるからね。少なくとも6日より早い。ここにはたくさんのスポーツがあるけど、もしかしたらIPを再割り当てする前に冷却しているか、再利用する前に証明書を照会して取り消しているのかな？もしアドレス機関が賛成していないなら、ホストヘッダーを検証して、古い証明書がなくなるまで不要なIPアドレス接続を拒否するのはユーザーの責任だね。それとも、ただ新しいIPを使うのを待つ？異なるクラウドプロバイダーでどれだけのIP証明書がどれくらいの金額で手に入るのか気になるな。

└

異なるクラウドプロバイダーでどれだけのIP証明書がどれくらいの金額で手に入るのか気になるな。いつかワイルドカード証明書を提供してくれるかな。

└

つまり、すべてのアドレス管理機関（ISPやクラウドプロバイダーなど）が協力してるってことだよね？彼らは時々、IPアドレスをすごい速さで切り替えるから。少なくとも6日より早いし…それに、同じIPアドレスに複数の顧客を同時に割り当てたりもする。でも、そういう使い方をしてるアドレスに対して実際に証明書を取得するための手続きをする気はないだろうね。念のため、基本的にすべてのソフトウェアを監査して、誰かが生のIPアドレスをURLに埋め込んだとしても、IPベースのSANを使って接続を検証しないようにするのがいいかも。この話は本当に狂ってる。

└

じゃあ、すべてのアドレス管理機関（ISPやクラウドプロバイダーなど）は賛成してるってことだよね？ 彼らは時々IPをすごい速さで切り替えるから。少なくとも6日より早いよね。 >ここにはたくさんのスポーツがあるけど、もしかしたらIPを再割り当てする前にクールオフするか、再利用する前に証明書を照会して取り消すかもしれないね。これがクラウドプロバイダーから取得できるカスタム/バニティドメインとどう違うのか分からないよ。例えば、Azureでは、myapp.westus.cloudapp.azure.comの形式でVMにDNS名を割り当てることができて、CAは喜んで証明書を発行してくれるよ[1]。これらのドメインにもクールオフはないから、理論的にはVMが廃止されたら誰かがそのドメインを奪うこともできるんだ。[1] https://crt.sh/?identity=westus.cloudapp.azure.com&exclude=e...

└

じゃあ、すべてのアドレス関連機関（ISPやクラウドプロバイダー）は賛成してるってこと？私の予想では、逆のアプローチになると思う。結局、ISPがTLSに従ってIPアドレスを発行するのは仕事じゃないし、TLSプロバイダーが「アイデンティティを検証」するのが仕事なんだよね。つまり、エコシステムの他の部分がどうやってアイデンティティを付与するかに従ってTLS証明書を発行すること。投稿にはどのようにアプローチするかは書いてないけど、私の直感では、LetsEncryptは長期的なIP発行者ASNのための徐々に増えていくホワイトリストを持つことになると思う。そして、そのASNの下に存在するIPに対してのみ証明書を発行して、リストにない他のASNにIPが売られたらそのIP証明書を無効にするんじゃないかな。このリストはMozillaのパブリックサフィックスリストのような公開データベースになると思うし、LetsEncryptは他のACME発行者と共有（そして共同管理）することを期待してるんじゃないかな。

└

ドメインが期限切れの前日に、HTTPS証明書を90日間更新できるよ。CAは自動更新に紐づけられたクレジットカードの限度額が達しているかどうかは見えないからね。IP証明書を使う人たちが、一週間後に自分のIPアドレスを放棄するような人たちとは思えないな。私が考える最も役立つことは、すごく変なレガシーソフトウェアか、Cloudflareみたいに共有IPなしでの暗号化クライアントハロー/暗号化SNIのサポートだね。前者は気まぐれにIPを落とさないし、後者は本物のドメインに接続するのに成功しないだろうね。

いいね、またTLSの脆弱性が見つかったね。前のやつは、自分が持ってないドメインの有効な証明書を生成することについてだったけど、今回は自分が持ってないIP用の証明書を生成するやつだ。ハッカーたちはテレグラムで大騒ぎするだろうね :)

これに関する公式な理由を知ってる人いる？

└

https://github.com/cabforum/servercert/pull/579/commits

└

発表はここだよ：https://letsencrypt.org/2025/01/16/6-day-and-ip-certs/。そんなに複雑じゃないと思う。何らかの理由でドメイン名を持っていないサービスがあって、それにパブリックな静的IPアドレスでアクセスできるんだ。セキュリティのためにTLS証明書が必要で、他のCAもこれを提供してるから、Let's Encryptもそうすべきだと思うんだけど、何か特別な理由があるの？

自分のローカルルーターで暗号化されたHTTPS（自己署名証明書エラーなし）を取得するのに役立つの？192.168.0.1が例のログインページね。

└

いや、プライベートIPアドレスには証明書を発行しないよ。独占的に管理してないからね（つまり、同じIPアドレスが他のネットワークの別のマシンを指すことがある）。

└

いや、でも多分そうかもね。ローカルアドレスに対して証明書を発行するのは不可能だし、望ましくもないよ。ローカルアドレスは本質的にローカルで、グローバルにルーティングできないから、検証する手段がないんだ。ただ、ルーターのメーカーがそうしたいと思えば、CG-NATの背後にいなければ、デバイスが自分のパブリックIPv4アドレスのために証明書をリクエストすることはできるかもしれないね。IPv6は比較的簡単だと思うよ。呪われたISPじゃなければ、ほとんどのIPv6はグローバルにルーティングできるから。

└

IPを持ってないとダメだよ。

└

いや、そうすべきじゃない。実際のドメインと本物の証明書を持つプロキシを立てて、そのドメインをローカルホストに向けるためにDNSリライトを使えばいいんだ。例えば、UIが欲しいならnginxマネージャーを使って、DNSにはAdGuardを使うといいよ。ルーターをAdGuard専用のDNSに設定して、ドメインをプロキシに向けるリライトルールを追加する。ドメインを登録して、本物の証明書を取得すれば、問題解決だね。私のローカルサービスは全部HTTPSを使ってるよ。

└

いや、逆だよ。グローバルIPじゃないと有効な証明書は取れないけど、ドメイン名の証明書は取れるし、それを192.168.0.1に向けることはできるよ。

└

いや、でも関連することはできるよ： - ドメイン名（foo.com）を取得して、*.foo.comの証明書を取る - a.b.c.d.foo.com（またはa-b-c-d.foo.com）を対応するプライベートIP a.b.c.dにマッピングするDNSリゾルバーを運営する - そのプライベートIPのデバイスにfoo.comの証明書をインストールすれば、https://192-18-1-1.foo.comを使ってローカルネットワーク内のデバイスにIP経由で接続できるよ。上のステップ3で証明書をインストールする必要があるから、もちろん長期的な証明書の方がうまくいくけど、自動化が助けてくれるよ。

この場合、SANはストレージエリアネットワークじゃなくて、サブジェクトオルタナティブネームを指してると思う。はぁ…人々がもうちょっと言葉を使ってくれれば、あやふやな略語を使う前に混乱を避けられるのに。特にそのトピックに詳しくない読者にとっては助かるよね。

└

TLS証明書発行者のブログで「SAN」を解釈できないなら、この投稿のターゲット層じゃないと思うよ。

└

TLS証明書機関からの技術フォーラムの投稿で、この略語の解釈は一つだけで、そんなにあやふやでもないし、文脈も十分だったよ。