Let's Encrypt、6日間およびIPアドレス証明書の一般提供を開始

 (letsencrypt.org)
14 ポイント 投稿者 GN⁺ 2026-01-17 | 1件のコメント | WhatsAppで共有
  • Let's Encrypt が 6日間有効の短期証明書 と IPアドレスベースの証明書 の正式提供を開始
  • 短期証明書は 160時間（約6日16時間） 有効で、ACMEクライアントで shortlived プロファイルを選択して発行可能
  • この証明書は より頻繁な更新を促してセキュリティを強化 し、信頼性の低い失効（revocation）手順への依存を減らすこと を目的とする
  • IPアドレス証明書は IPv4 と IPv6 の両方をサポート し、IPアドレスの変動性が高いため 短期証明書の形でのみ発行
  • 今回の措置は 自動化された証明書更新体制の普及とセキュリティ強化のための段階的な変化 と評価される

短期（6日）証明書の提供

  • 短期証明書（short-lived certificate） は160時間有効で、従来の90日証明書よりはるかに短い寿命
    • ACMEクライアントで shortlived 証明書プロファイル を選択すると発行可能
  • この証明書は より頻繁な検証を要求 することでセキュリティを強化し、失効システムの不安定性の問題を緩和
    • 従来は秘密鍵が漏えいした場合に証明書の失効が必要だったが、失効手順は信頼できず、有効期限が切れるまで脆弱な状態が続く可能性があった
    • 短期証明書を使うことで、この 脆弱な期間が大幅に短縮 される
  • 短期証明書は 任意選択（opt-in） 方式であり、デフォルトに切り替える計画はない
    • 自動更新プロセスを完全に構築したユーザー は容易に移行可能
    • ただし、すべてのユーザーが短い有効期間に慣れているわけではないことを考慮し、デフォルトは維持 される
  • 今後数年以内に 標準の証明書有効期間を90日から45日に短縮 する予定

IPアドレス証明書

  • IPアドレス証明書（IP address certificate） は ドメイン名の代わりにIPアドレスでTLS接続を認証 できるようにする
    • IPv4 と IPv6 の両方をサポート
  • IPアドレス証明書は必ず 短期証明書の形でのみ発行 される
    • IPアドレスはドメインより さらに頻繁に変更されるため、頻繁な検証が必要 という理由による
  • 関連する詳細情報とユースケースは 2025年7月に公開された最初のIP証明書に関する投稿 で確認できる

支援と後援

  • 今回の開発は Open Technology Fund、Sovereign Tech Agency、そして 支援者と寄付者 の支援により実現
  • Let's Encrypt は非営利団体 Internet Security Research Group (ISRG) が運営する 無料・自動化・公開認証局（CA）
  • ISRGの2025年年次報告書で 非営利活動全般 を確認できる

関連記事

1件のコメント

 
GN⁺ 2026-01-17
Hacker Newsのコメント

  • 今日の時点では certbot では IP アドレス証明書を取得できなかった
    代わりに lego を使ったが、正しいコマンドを見つけるのにかなり時間がかかった
    昨日成功したコマンドは次のとおり
    lego --domains 206.189.27.68 --accept-tos --http --disable-cn run --profile shortlived

    • Caddy でもこの機能がサポートされているのか気になった
      まだ進行中のようだ（GitHub issue）

  • IP アドレス証明書は、iOSユーザー が自分で DoH サーバーを運用する場合に特に興味深い話題だ
    iOS では FQDN と IP の両方に正しい証明書がないと動作しなかった
    そのため dns4eu や nextdns のような大規模サービスのプロファイルはうまく動く一方、個人が作った DoH サーバーは失敗していた

    • OpenSSL は TLS 接続時、証明書の SAN フィールドに IP アドレスが含まれていることを厳格に要求する
      おそらく iOS エンジニアが明示的に追加したというより、使っている 暗号ライブラリの副作用 ではないかと思う
    • 私は個人ドメインをリバースプロキシの背後で DoH として毎日使っているが、何の問題もない

  • なぜ 6 日証明書なのか気になった
    8 日なら週単位で更新しやすく、8 は 2のべき乗 で縁起の良い数字だと思っていた
    でも 6 はどうにも好きになれない

    • 6 日周期にすると、長期的には負荷が平日に 均等に分散 される
      8 日だと特定の曜日にトラフィックが集中する可能性がある
    • 実際には 6 日ではなく約 160時間（6.6日） だ
      160 は最初の 11 個の素数の和であり、最初の 3 つの素数の立方の和でもある
    • 6 日は 神が 6 日働いて 7 日目に休んだ ことの象徴でもある
    • 6 は最小の 完全数（perfect number） なので、完全さの象徴だ

  • 次は .onion アドレス向け証明書 の発行に注力してほしい
    .onion はすでに鍵ペアを持っているため、所有証明は DNS よりも信頼できる

  • IP 証明書が欲しいなら、certbot はまだ対応していない
    関連 PR はすでに開かれている（#10495）
    一方で acme.sh はすでに対応しているようだ

    • 現在 IP アドレスをサポートする ACME クライアントには acme.sh, lego, traefik, acmez, caddy, cert-manager がある
      certbot もまもなく対応すると期待している

  • 私は 2 週間更新周期でテストしていたのに、証明書が 6日もの になっていて面食らった
    パイプラインが失敗するとデバッグの時間が短すぎる
    IP がドメインより 変動しやすい という理由は納得しにくい
    VPS の固定 IP はそう頻繁には変わらない

    • しかし AWS のようなところでは Elastic IP を即座に解放できる
      もし 45 日証明書を発行してすぐに IP を返却したら、別の利用者がその IP を使うことになる
      すると他人の IP に対する有効な証明書を持つことになり危険だ
    • クラウド環境では IP がすばやく再割り当てされるため、6日でも長い と思う
    • 短すぎる証明書の有効期間は現実の運用方法と合っていない
      こうしたポリシーは現場の実務をよく知らない発想に見える
    • 問題は IP の 所有・制御権 にある
      ほとんどのサービス運用者は IP 自体を直接制御していないため、CA のリスクを減らすための措置だ
    • EC2 インスタンスに EIP を関連付けていなければ、再起動時にはほぼ確実に別の IP が割り当てられる
      悪用は難しいが、それでもセキュリティ上の考慮点ではある

  • IP アドレス証明書ができれば IPsec トランスポートモード が再び注目されるのか気になった
    私が書いた RFC 5660 も関連している

    • しかし現実には、すでに SDN や site-to-site VPN が十分普及している
      IPsec トンネルで証明書を使わせるのも依然として面倒だ
      一部のファイアウォール機器には、証明書チェーンが長いと認証に失敗する奇妙なバグまである
    • IPSec 標準 は大きすぎて複雑すぎるうえ、作った会社でさえ何十年も CVE を出し続けてきた

  • IP 証明書はインターネットから到達可能なアドレスにしか使えないので、LAN 機器向け TLS は依然として難しい

    • IPv6 を使えば外部公開なしでも可能だ
      エッジで DNAT によりトラフィックを受け、証明書更新用 VM に転送し、そこから内部機器へ配ればよい
    • 私は自宅ネットワーク用に ワイルドカード証明書（*.home.example.com）を使っている
      TXT レコードを API で設定できる公開 DNS が必要だが、lego の DNS プラグイン は多くのプロバイダーをサポートしている
    • このような場合は プライベート CA を使うのも一つの方法だ
    • 内部ネットワークのアドレスは外部から所有証明ができないので、素直にドメインを使う方がよいと思う

  • 今回の発表は本当にうれしい
    IP 証明書は self-hosted ソフトウェアの初期ブートストラップ問題 を解決してくれる
    たとえば TakingNames の instant subdomains 機能 も、もう不要になるかもしれない

  • IP アドレス証明書は 短命なサービス（ephemeral service） が TLS 通信を行う際に便利だ
    DNS レコードを別途作る必要がないので、何百もの一時インスタンスを立ち上げるときに都合がよい

    • Encrypted Client Hello（ECH） にも活用できる
      平文で露出する SNI の代わりに IP 証明書を使えば、外部から実際のホスト名を見られない
      小規模サイト でもプロキシなしで ECH を使えるようになる
    • Let's Encrypt の公式発表 にはさまざまなユースケースが整理されている
    • レジストラ依存 がない点が魅力的だ
      より 匿名性 が高くなる
    • 人向けではないサービスなら、ネームサーバー依存の排除 は特に有用だ
    • DNS over TLS や DNS over HTTPS のようなプロトコルにも適用できる