- Let's EncryptがまもなくIPアドレスSANを含む証明書の発行をサポートする予定で、初期段階では有効期限6日の短期（shortlived）プロファイルに限って提供され、一定期間はホワイトリスト方式で制限運用される
- 正式公開までは具体的な日程や申請案内はなく、内部テストと準備が進行中
- ステージング環境でIPv6アドレスを含むサンプル証明書と、それを適用したサイトが公開されており、コミュニティに異常事項やフィードバックの共有を要請
- FirefoxでIP SAN表示に関するバグ（BZ #1973855）が見つかっており、テストが続いている
- DNS SANとIP SANを混在させたケースで混乱の余地があることを実際のテスト例で確認し、TLDとIPv6アドレスの表記が似る可能性を実演
Let's Encrypt, Getting ready to issue IP address certificates
IPアドレスSAN対応の準備状況
- Let's Encryptはまもなく本番環境でIPアドレスSANを含む証明書の発行をサポートする計画
- 該当証明書は有効期限6日のshortlivedプロファイルでのみ発行され、一定期間は許可リスト（allowlist）方式で制限運用される
- まだ正式リリース日程および許可リスト申請方法は未定で、追加の内部準備が必要
テストおよびサンプル証明書
- ステージング環境でIP SANを含むサンプル証明書と実際に適用したサイト（IPv6アドレス）の例が公開された
- コミュニティユーザーに対し、異常事項や興味深い点、問題点を見つけた場合は共有してほしいと要請
IP SANとDNS SANの混在事例
- テスト過程でDNS SANとIP SANが同時に含まれた証明書の発行可能性と、表記上の混乱事例を実演
.cafe など特定のTLDとIPv6アドレスの表記が似る可能性があり、混乱の余地がある- Firefoxで**IPアドレスSAN表示に関するバグ（BZ #1973855）**も確認された
要約
- Let's EncryptのIPアドレス証明書対応は、ホワイトリストと短期証明書に限定して先行適用される
- 実サービス適用前までにさまざまなケースのテストとコミュニティフィードバックを通じて安定性・互換性を点検する予定
- DNS名とIPアドレスのSAN混在によるブラウザ表示の問題などもあわせて議論されている
1件のコメント
Hacker Newsの意見
IPアドレス用の証明書も有用だと思う
ただ、Let‘s EncryptがS/MIME証明書をサポートすれば、はるかに大きなインパクトを与えられると思う
メール暗号化をめぐっては、ここ数年ずっと滑稽な状況が続いている
今では主要なメールクライアントのほとんどがS/MIME暗号化を標準でサポートしているが、Webと同じく、スムーズなユーザー体験のためにはCAから証明書を取得する必要がある
信頼できて無料で、しかも1年以上有効なS/MIME証明書を提供するCAは、今やすべて姿を消した
その結果、個人ユーザーはメール暗号化をまったく使わない状況になっている
PGPは不便すぎて、技術マニア以外ではほとんど使われていない
そろそろメールも暗号化すべきだと思う
参考までに、CAが秘密鍵を代わりに生成するなら、その証明書は信頼できないと考える
また、S/MIMEでは昔のメールを復号するために古い証明書を保管し続ける必要があるため、頻繁に切り替わる証明書は実用的ではない
S/MIMEで古いメールを復号するには旧証明書が必要だという話については、復号鍵そのものは新しい証明書でも既存の鍵を使って作れるので（例: certbotの
--reuse-keyオプション）、必ずしも頻繁に切り替える必要はないと思うただし、このやり方が良い方法かどうかは別問題
本当に必要なのは、ACMEスタイルの自動証明書発行の自動化だと思う
今は証明書更新のプロセスが面倒で、ほとんど使われていない
PGPには今ではWKD(Web Key Directory)リンクという仕組みがあり、メールにTLSの信頼網を適用できる
TLS証明書はS/MIME証明書よりはるかに取得しやすい
アイデンティティ管理を第三者が担うことが役立つ場合もあるが、多くの人はそうしたアイデンティティ管理にあまり適していない会社で働いていることが多い
企業であれば、アイデンティティ管理は社内で行うほうが適切だと思う
最近あったSignalgate 1.0騒動リンクは、エンドツーエンド暗号化におけるアイデンティティ管理の失敗という点で、実に学ぶところが多かったと思う
こうした点から、S/MIME証明書やWKDが実用的な仕組みとして導入されれば、政府でも有用かもしれないと思う
個人的にはS/MIMEベースのメール暗号化の将来性を前向きに見てはいるが、実現可能性は低いと感じる
一般ユーザーは秘密鍵の管理すら難しいことが多く、メールパスワードですら適切に管理できないのが現実だ
結局、各ドメインごとに中央で証明書発行が必要になるか、さもなければユーザーが証明書を受け取れない状況になる一方で、サイバー犯罪者がS/MIME署名付きメールを送る問題も出てくる
今後passkeyの利用が一般化し、世代交代が進んだ段階で、そこで初めて鍵ペアを直接扱わせるのが妥当だと思う
メール暗号化はもう消えるべきだという意見
参考: Stop using encrypted email
S/MIME暗号化についてあまり詳しくないので疑問がある
なぜ同じプロトコルで古いメールを復号しなければならないのだろう
個人的には証明書は転送経路(transport)のためのものだと思っていたし、実際の保存時にはサーバーやホスト側で保存用の暗号化が別にあるはずなので、転送時は短期証明書、保存時は好きな方式の暗号化、というように分けて使うのが自然に思えるが、何か見落としている点があるのだろうか
すべてのアドレス管理機関（例: ISP、クラウドプロバイダー）もこの流れに加わるのか気になる
これらはIPを非常に高速でローテーションすることがあり、6日より早く切り替わることもある
クラウドプロバイダーがIPの分析前にクールダウン期間を設けたり、そのIPに関連する証明書を照会・失効させたりするなら理解できるが、そうでなければユーザー側の責任でホストヘッダーを検証し、望まないIPベース接続を拒否するか、レガシー証明書が完全になくなるまで待つ必要があり、複雑さが生じる
クラウドプロバイダーごとにIP証明書をどれだけ、いくらで取得できるのかも気になる
実際のところ、この問題はクラウドプロバイダーのカスタム/バニティドメイン提供と大差ないと思う
たとえばAzureでは
myapp.westus.cloudapp.azure.comのようなDNS名をVMに割り当てられるが、CAからは誰でもそのドメインの証明書を発行してもらえる 参考この場合も、別途クールダウンなしでVMが消えれば、別の人がすぐそのドメインを取得できる
HTTPS証明書はドメインの期限切れ前日に90日物へ更新できるし、CAはクレジットカードの利用限度額も把握できない
IP証明書を使う人の多くは、すぐIPを捨てて去っていくユーザーとは違うはずだ
最も有用なケースは、非常に特殊なレガシーソフトウェアや、Cloudflareのように共有IPなしでECH(Encrypted Client Hello)やESNI(Encrypted SNI)のサポートが必要な場合だろう
最初のケース（レガシー）ではIPを簡単に手放さないだろうし、後者（ECH/ESNI）では実際のドメインに接続を成立させるのが難しいと思う
ISPが加わるべきかという問いには、むしろ逆だと思う
ISPの役割はTLS標準に沿った形でIPを割り当てることではなく、TLS証明書プロバイダーがエコシステムにおけるアイデンティティ（ドメイン、IPなど…）の結び付け方に合わせて「本人確認」を担うべきだと思う
今回どう進めるのか詳細は出ていないが、私の直感ではLetsEncryptはASN（自律システム番号）ベースで長期的なIP移管が行われる一覧を作り（Mozilla Public Suffix Listのような公開DBを共同管理する形で）、その一覧内のIPに対してのみ証明書を発行し、別ASNへ移った場合は証明書失効の管理などを行うのではないか
他のACME発行者とも共有される形になることを期待している
さまざまなクラウドでIP証明書をいくらで何枚取れるのかが気になるなら、将来的にワイルドカード証明書のサポートが来るのかも気になる
私のケースでは、たった1日でもIP証明書があればhttps URLのテストができるので、とても歓迎すべき変化だと思う
技術的にどう動くかは分かるが、実際に意図された用途が何なのか気になる
ECH(Encrypted Client Hello)やESNI(Encrypted SNI)のサポートだけでも十分に大きな意味があると思う
ESNI初期にはCloudflareのような大規模httpsプロキシでしか適用できず、IP証明書の導入は夢物語のように思われていたが、今ではすべてのサーバーがESNI/ECHに参加できる
クライアントがすべてのサーバーにIP証明書があると仮定してESNIを試みるようになれば、インターネット全体のプライバシー向上に大きく寄与するはずだ
いくつかの返信で良い事例が挙がっているが、NTS(Network Time Security)も言及に値する
IP証明書が取れないと、NTSにもDNSが必要になり、DNSが落ちると認証付きの時刻同期がまったくできなくなる
DNSSECは正しい時刻がないと検証に失敗するが、DNS+NTS依存だと復旧不能になる
IPを含む証明書によってDNSなしで認証済み時刻を配布できれば、こうした問題を解決できる
DNSがかなり変化する過程でも有効な証明書を維持する必要がある場合、たとえばダッシュボードへのアクセス性を確保したり、古い自動化がDNSエラーで止まらないようにしたりするために使える
別の例としては、DNSなしでもっと単純にテスト環境をすぐ立ち上げたり、Cockpitなどを外部公開したりする用途も考えられる
要するに、想像力が許す限りさまざまな活用先がある
authdns（認証DNSサーバー）に対して「日和見的(opportunistic)」DoTLS（TLSベースのDNSクエリ）を行う場合にも面白い使い方になりそうだ
公開IPをSAN(Subject Alternative Name)に含む証明書を使って、認証DNSサーバーがDoTLSポートでサービスを提供できる
今でもホスト名で可能だが、1つのパブリックIPに複数の異なる名前が載ることがあるため、IPベースのSANのほうがより明確に結び付けられる
ホスト名ではなく、プロジェクトに直接IPで接続するといった趣味用途や単発用途で、ドメインなしで使いたい人には向いていると思う
なぜ地域インターネットレジストリ(RIR)やローカルインターネットレジストリ(LIR)が証明書を発行しないのか気になる
なぜ第三者がRIRやLIRの登録者を検証しなければならないのか、ドメイン登録者は仕事が多すぎるということなのか
同じ理由なのか疑問だ
TLSを新たに悪用できる余地が増えたようにも思える
これまでは所有していないドメインに対する証明書発行が問題だったが、今度は所有していないIPに対しても証明書が出せるかもしれない
ブラックハットの連中がTelegramで大はしゃぎしそうだ
これによってローカルルーター（例: 192.168.0.1）の管理画面にもself-signedエラーなしでhttps接続できるようになるのか気になる
できないが、将来的には可能になるかもしれない
ローカルアドレスは一般的に割り当てられるものではなく、グローバルルーティングもされないため、本質的に検証する方法がない
ただし、ルーターメーカーにやる気があり、CG-NATの背後ではなくパブリックIPv4アドレスが割り当てられた機器であれば、そのパブリックアドレスに対して証明書を要求することは可能だ
IPv6は大半がグローバルルーティングされるので、さらに簡単だと思う
できないし、そうあるべきでもない
実際には、プロキシと実ドメイン、本物の証明書、そしてDNSリライト機能を組み合わせれば十分実現できる
たとえばnginx manager UIとDNSとしてadguardを使う
ルーターのDNSをadguardに限定し、自分のドメインはproxyへリライトする
ドメインを登録して本物の証明書を発行してもらえば解決する
私もすべてのローカルサービスをhttpsで使っている
プライベートIPには証明書は発行されない
同じプライベートIPが、別のネットワークではまったく別の機器に毎回使われる可能性があり、排他的な所有権が保証されないからだ
むしろ逆だ
パブリックIPでない限り有効な証明書は発行できない
すでにドメイン証明書を取得し、そのドメインを192.168.0.1へ転送する方法がある
証明書を取得するには、そのIP（パブリックIP）を実際に所有している必要がある
内部IPv4（192.168.x.x、172.16.x.x、10.x.x.x）向けの証明書も可能なのか、あるいはブラウザがこうしたアドレスを無視するべきなのか、そうでないなら内部ネットワーク向けのワイルドカード証明書でも発行できるのか気になる
公開(public) CAが発行する証明書という文脈では、その質問はあまり意味をなさないと思う
ドメインと違って、10.10.10.10のようなプライベートIPは非常に多くの人が同時に「所有」している
社内開発用ならmkcertのようなツールがあるし、社内共有リソースならドメインベースのTLS証明書のほうが簡単だ
もし機器の秘密鍵が絶対に漏えいしないと証明できるなら、既存CAでも試みる余地はある
ただし内部アドレス証明書については、誰かが機器を購入して秘密鍵を取り出せば、即座に証明書鍵の失効が問題になる
そのため、信頼できる機器なら証明書を手動でインポートして警告なしで接続するか、複数機器があるなら独自CAを構築して証明書を配布するのが現実的だ
オープンソースのACMEサーバーを使えば、Let's Encryptと同じ方式の発行自動化を内部でも実現できる
DNSをまずパブリックサーバーへ向けて証明書を発行し、その後DNSを内部の192.168…アドレスへ向け直して証明書と鍵をコピーする、という方法もある
注意点として、一部のルーターは内部アドレスへ転送されるDNS応答をブラックホール化することがあるので、事前テストが必要だ
ブラウザはプライベートネットワークを無視すべきではないと思う
私にとってプライベートネットワークは単に自宅ルーターにすぎないが、人によっては世界規模のネットワークかもしれない
サンプル証明書にsubjectフィールドがないのは興味深い
IPで要求していて、SANにDNSが記載されているからだろうか
6日間の短期証明書プロファイルではすでに適用されており、「クラシック」な90日プロファイルにはまだ適用されていないとのこと
CVE-2010-3170脆弱性がまた脚光を浴びる時期かも、という冗談
ただ、実際にこれを突くには、誤動作するCAがその証明書を発行してしまう必要があるので、可能性は低いと思う
残念ながらIPアドレス用証明書はDNSチャレンジ方式では発行できない
だが、その理由は理解できる