ハクソク

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

6日間およびIPアドレス証明書が一般提供開始されました

129日前原文(letsencrypt.org)

概要

Let's Encryptが 短期間有効な証明書 および IPアドレス証明書 の一般提供を開始。 短期間証明書は 160時間（約6日間） の有効期限。 証明書失効の問題点 を改善し、セキュリティを強化。 IPアドレス証明書は 短期間証明書のみ で発行可能。 今後は 証明書の有効期間短縮 も計画中。

Let's Encryptの短期間証明書の一般提供

  • Let's Encryptが 短期間有効な証明書 （short-lived certificates）の一般提供を開始
  • 有効期間は 160時間（約6日間） で設定
  • ACMEクライアントで ‘shortlived’証明書プロファイル を選択するだけで取得可能
  • 頻繁な検証 を必要とすることで、セキュリティ強化を実現
  • 証明書の 失効（revocation）システムの信頼性の低さ を補完
  • プライベートキー漏洩時のリスク期間を 大幅短縮
  • 通常の証明書（90日間有効）では、失効が機能しない場合 長期間脆弱性が残る 問題
  • 短期間証明書は オプトイン方式 で、現時点ではデフォルトにしない方針
  • 自動更新プロセス を完全自動化している利用者は、短期間証明書への移行が容易
  • 一般的な利用者が短期間証明書に慣れるまで、デフォルト化は見送り
  • 今後数年で デフォルト証明書の有効期間を90日から45日に短縮 予定

IPアドレス証明書の提供

  • サーバ運用者が IPアドレス（IPv4、IPv6） でTLS接続を認証可能
  • IPアドレス証明書は短期間証明書のみ で発行
  • IPアドレスは ドメイン名よりも流動的 なため、頻繁な検証が重要
  • 詳細やユースケースは、Let’s Encrypt公式の IP Certificate発表記事 参照

今回の取り組みへの支援

  • Open Technology Fund や Sovereign Tech Agency、スポンサー・ドナー各位の支援による開発推進

Hackerたちの意見

IP証明書が欲しい人は、certbotがまだ対応してないことに注意してね。実装のためのPRはまだオープン中だよ: https://github.com/certbot/certbot/pull/10495 でも、acme.shは対応してると思うよ。

└

現在IPアドレスをサポートしていると思われるACMEクライアントは、acme.sh、lego、traefik、acmez、caddy、cert-managerだよ。certbotのサポートも早く実装されるといいな。

このスレッドでも既に指摘されてるけど、今のところcertbotを使ってIPアドレス証明書は取得できないよ。lego [1] を使えるけど、正確なコマンドラインを見つけるのに昨日はちょっと苦労した。これがうまくいったコマンドだよ: lego --domains 206.189.27.68 --accept-tos --http --disable-cn run --profile shortlived [1] https://go-acme.github.io/lego/

└

Caddyはもうサポートされてるのかな？（まだ作業中みたいだね）https://github.com/caddyserver/caddy/issues/7399

これは面白いね。IPアドレス証明書の使い道は、エフェメラルサービスがTLS通信を行うためだと思うけど、今は名前サーバーにレコードをプロビジョニングする必要がなくなったんだね。何百も何千も立ち上げるかもしれないサービスが、1時間や1日だけしか持たないのに。

└

確かに、人間が直接関わらないものに対して名前サーバーに依存しないのは結構便利だね。

└

レジストラに依存しないのはいいね。もっと匿名性が高い。

└

TLSが必要だけど、プロジェクト用の適切なサブドメインを取得するには、動きが遅い人たちと話さなきゃいけないの？

└

IPアドレス証明書の使い道は、エフェメラルサービスがTLS通信を行うためだと思うよ。DNS over TLSやDNS over HTTPSっていうのもあるけど、聞いたことある？

└

これが役立つのは、暗号化されたクライアントハロー（ECH）だね。TLS/HTTPSを使って、サーバー名を聞いているデバイスに漏らさずに通信できる方法なんだ（標準のSNI名は平文で送信される）。使うには、接続先のサーバーのホスト名が読みやすい形で放送される有効な証明書が必要だよ。CloudflareやAzure、Googleみたいな大手は、プロキシの名前を使えばいいから問題ないけど、小さいサイトだと一つか二つのドメインしか持ってないことが多いから、明確なホスト名がないことが多いんだ。IP証明書を使えば、外側のTLS接続は読みやすいSNIフィールドにIPアドレスを使って、実際の接続のホスト名を暗号化できる。もう他人のコンテンツをプロキシする必要もなくなるから、ECHが有効に働くよ。

└

7月のIPアドレス証明書の発表では、いくつかの潜在的な使用例が挙げられてたよね：https://letsencrypt.org/2025/07/01/issuing-our-first-ip-addr...

今、45日からの変更をテストするために2週間の更新間隔を実装したんだけど、6日間の証明書が来るの？批判するつもりはないけど、更新はどうすればいいの？もし何か問題が起きたら、certbotをトリガーするパイプラインがうまくいかなくなるかもしれないし、修正する時間もないよ。そうなると、2日間の更新と4日間の「デバッグ」ウィンドウができちゃう。これが必要な人もいるだろうけど、私は違うな。それに、理由も少し変だよね。> IPアドレス証明書は短命でなければならないという決定をしたのは、IPアドレスがドメイン名よりも一時的だから、より頻繁に検証することが重要だということ。45日間のウィンドウ内で、IPアドレスは本当にドメインより一時的なの？VPSを借りたときに得られる静的IPは、一時的じゃないよ。

└

短い証明書の有効期間を推進するのは本当に悪いアイデアで、こういう取り組みをしている人たちが世の中のことを全く理解していないことを示してるね。

└

商業的な文脈でこれをやっていて、4日間のデバッグウィンドウやダウンタイムが、例えば商業サプライヤーから1年の証明書を買うよりもコストがかかるなら、それが答えかもしれないね。

└

これを修正する時間がない それなら、プロセスを自動化することを考えた方がいいよ。

└

IP証明書の短期間の要件は、IPアドレスがよくレンタルされて、ユーザー間で素早く移動することを考えると、かなり妥当だと思う。例えば、クラウドプロバイダーでVMを買った場合、そのVMやIPを解放した瞬間に別の顧客に渡されることがある。そうなると、そのIPに対して有効な証明書を持っていることになるんだ。6日って、実際にはこの状況では長い方かもね！

└

IPアドレスは45日間のウィンドウ内でドメインよりも一時的なの？ EIPをEC2インスタンスに割り当てずにシャットダウンしたら、再起動する時にはほぼ確実に別のIPを取得することになるよ。シャットダウンが完了してから数秒以内に再起動してもね。ただ、この挙動を悪用するのはかなり難しいけど。最近使われていたIPが割り当てられないといけないし、そのIPを使っていた人もTLSを使っているか、証明書の検証を無効にしている必要があるから。

└

IPアドレスの一時性よりも、IPアドレスの管理が重要なんだ。ウェブサイトやサービスの運営者がIPアドレスを管理することはほとんどないからね。CAのリスクを制限するためなんだ。

次は、.onionアドレスの証明書発行に注力してほしいな。現代のウェブでは、多くの機能やプロトコルがHTTPSの背後にロックされてるからね。.onionの所有者はキーのペアを持ってるから、所有権の証明がDNSよりも信頼できるんだ。

└

でも、tor自体がエンドポイントのアイデンティティを暗号化して確認するから、httpsを使う必要はないんじゃない？

└

「自動証明書管理環境（ACME）拡張：『.onion』特別使用ドメイン名」 * https://datatracker.ietf.org/doc/html/rfc9799 * https://acmeforonions.org * https://onionservices.torproject.org/research/appendixes/acm...

IPアドレスはインターネットからアクセスできる必要があるから、手動設定なしでLANデバイスのTLSをサポートする方法はないし、セキュリティ研究者を怒らせることにもなるね。

└

ルーティングできないなら、他の誰にも所有権を証明する方法なんてどうするの？ ドメイン名を作ればいいじゃん。

└

そのシナリオにはプライベートCAを使うこともできるよ。

└

最近、家のネットワーク用にワイルドカード（*.home.example.com）証明書に移行したんだけど、いろんな部分でうまくいってるよ。ただ、TXTレコードをAPI経由で設定できるパブリックDNSサーバーが必要なんだ。legoはいくつかのDNSプロバイダーをサポートしてるから、詳しくはここを見てね：https://go-acme.github.io/lego/dns/

IPアドレス証明書ができるなら、トランスポートモードのIPsecが再び関連してくるかもしれないね。RFC 5660も同様だし（ちなみに、私が書いたものだよ）。

IPアドレス証明書は、自分のDoHサーバーを運営したいiOSユーザーにとって特に面白いんだよね。適切に設定されたDoHサーバー（たぶんunboundを使ってるやつ）に、正しい構成プロファイルがあって、DoHのFQDNと適切な証明書が含まれていても、iOSでは動かないんだ。理由は、iOSがFQDNとIPの両方に正しい証明書が必要だって主張するからなんだよね。だから、dns4euやnextdnsみたいな大きな組織の構成プロファイルは、例えばiPhoneにインストールするとちゃんと動くけど、自分の個人的なDoHサーバー（とプロファイル）は動かないってわけ。

なんで6日で8日じゃないの？ - 8はラッキーナンバーで、2の累乗だし - 8だと毎週リフレッシュできて、API 429のタイムアウトがあったかどうか確認する固定の日が持てる - 6は獣の数字の各桁の値だし - ただ6が好きじゃないんだよね！

└

それは、6日間働いて、7日目は休むことができるからだよ。神様もそうしたんだ。

└

8だと毎週リフレッシュできて、API 429のタイムアウトがあったかどうか確認する固定の日が持てる これが答えだね。6日だと、長い時間軸で見ると負荷が週の中で均等に分散されることになる。8日だと特定の曜日に負荷が集中しちゃうんだ。

└

いいポイントがいくつかあるね。

└

実は6と2/3なんだよ！160時間の理由を考えようとしてるけど、全然思いつかない。誰か知ってたら教えてほしいな。200は8 1/3日になるちょうどいい数字だから、週ごとのローテーションの利点もあるし。

└

心配しないで、6日間（144時間）じゃなくて、6日ちょっとだよ。160時間だし、160は最初の11個の素数の合計でもあるし、最初の3つの素数の立方体の合計でもあるんだよね！

彼らの発表の中に埋もれてるけど、IPアドレス証明書は今のところステージング中だけなんだ。

└

それはすごく古い記事で、今はもう古くなってるみたい。