はじめに
2026年1月15日、Let's EncryptがIPアドレス証明書の一般提供を開始したっていうリリースを見たので、どのRFCに準拠しているのか?などを整理したので、せっかくだからQiitaを書いたのです。今まではドメイン名でしか発行できなかったTLS証明書が、IPアドレス(IPv4/IPv6)に対しても自動発行可能になるのって結構応用が効きますよね。
この機能は、RFC 8738で標準化されたACMEプロトコルの拡張仕様に準拠しており、IoTデバイス、内部API、DNS非依存環境などでの利用が想定されています。
それでは解説をしていきますので、よろしくお願いします。
概要
変更点
- 従来: ドメイン名のみ証明可能
- 今後: IPアドレス直接の証明も可能(IPv4/IPv6対応)
主要な特徴
- 有効期限: 160時間(約6日間)固定
- 完全自動化: ACMEプロトコルによる自動発行・更新
- 標準準拠: RFC 8738に基づく実装
公式発表: https://letsencrypt.org/2026/01/15/6day-and-ip-general-availability
技術仕様
準拠する主要RFC
IPアドレス証明書は、以下のRFCに基づいて実装されています。
1. RFC 8738 - Automated Certificate Management Environment (ACME) IP Identifier Validation Extension
ACMEプロトコルでIPアドレスの証明書を発行するための拡張仕様です。IPv4およびIPv6の両方のアドレスに対応し、HTTP ChallengeとTLS-ALPN Challengeの使用を規定しています(DNS Challengeは使用不可)。
2. RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
X.509 v3証明書の基本標準プロファイルです。Subject Alternative Name(SAN)拡張にIPアドレスをiPAddress形式で含めることを規定しています。CA/Browser Forum Baseline Requirementsにより、IPアドレスはdNSName形式ではなくiPAddress形式で記載することが必須です。
3. RFC 8555 - Automatic Certificate Management Environment (ACME)
ACME基本プロトコルの仕様です。RFC 8738はこれを拡張する形で定義されています。
関連RFC
- RFC 8737 - Automated Certificate Management Environment (ACME) TLS Application-Layer Protocol Negotiation (ALPN) Challenge Extension
- TLS-ALPN Challengeの定義
- RFC 1123 - Requirements for Internet Hosts -- Application and Support
- IPv4アドレスのテキスト形式
- RFC 5952 - A Recommendation for IPv6 Address Text Representation
- IPv6アドレスのテキスト形式
- RFC 3779 - X.509 Extensions for IP Addresses and AS Identifiers
- IPアドレスのためのX.509拡張
証明書の仕様
有効期限
- 160時間(6日と16時間)固定
- shortlived certificate profileの選択が必須
対応プロトコル
- IPv4アドレス
- IPv6アドレス
検証方法(Validation Challenges)
- 使用可能
- HTTP Challenge (http-01)
- TLS-ALPN Challenge (tls-alpn-01)
- 利用不可
- DNS Challenge (dns-01)
- IPアドレスのため
- DNS Challenge (dns-01)
証明書形式
- Subject Alternative Name(SAN)拡張にiPAddress形式で格納
- dNSName形式での記載は不可(Baseline Requirements準拠)
なぜ有効期限が6日間なのか?
Let's Encryptは、IPアドレス証明書を短期証明書(short-lived certificates)に限定した理由を以下のように説明しています。
IPアドレスの一時的な性質
IPアドレスはドメイン名と比較して、より一時的(transient)な性質を持ちます。クラウド環境やコンテナオーケストレーション環境では、IPアドレスが頻繁に変更されるため、より頻繁な検証が重要です。
短期証明書のセキュリティ上の利点
1. 鍵漏洩時の影響範囲を最小化
従来の90日証明書では、秘密鍵が漏洩した場合、証明書失効(revocation)が適切に機能しない場合に最大90日間脆弱性が存在する可能性がありました。6日間証明書では、この脆弱性ウィンドウが大幅に短縮されます。
2. 失効機構の不確実性を軽減
証明書失効は歴史的に信頼性の低いシステムであり、多くのクライアントは証明書が期限切れになるまで脆弱なままです。短期証明書は、失効への依存度を減らします。
3. より頻繁な検証によるセキュリティ向上
6日ごとに所有権を検証することで、不正な証明書発行のリスクを低減します。
Validation Challengeの詳細
HTTP Challenge (http-01)
申請者がそのIPアドレスでHTTPサーバーを稼働させていることを確認します。
検証フロー:
- ACMEクライアントが証明書を申請
- CAが乱数トークンを生成
- クライアントが
http://<IPアドレス>/.well-known/acme-challenge/<トークン>にファイルを配置 - CAがHTTP GETリクエストでファイルを取得・検証
- 検証成功で証明書発行
要件:
- ポート80でHTTPサーバーが稼働
- 外部からアクセス可能
TLS-ALPN Challenge (tls-alpn-01)
TLSハンドシェイクのALPN(Application-Layer Protocol Negotiation)拡張を利用した検証方式です。
検証フロー:
- ACMEクライアントが証明書を申請
- CAが乱数トークンを生成
- クライアントがTLS接続時のALPN拡張に特定の値を設定
- CAがポート443でTLS接続を試み、ALPN拡張を検証
- 検証成功で証明書発行
要件:
- ポート443でTLSサーバーが稼働
- ALPN拡張のサポート
メリット:
- ポート80を開ける必要がない
- HTTPサーバー不要
DNS Challenge (dns-01) が使用不可の理由
IPアドレスには対応するDNS名(FQDN)が存在しないため、_acme-challenge.<ドメイン>のようなTXTレコードを追加できません。
逆引きDNS(PTRレコード)も以下の理由で利用不可です:
- ISPやクラウドプロバイダーが管理
- IPアドレス利用者が自由に変更できない
- セキュリティ上、第三者管理のDNSでの検証は不適切
取得方法
IPアドレス証明書を取得するには、ACMEクライアントでshortlived証明書プロファイルを選択します。
重要: 2026年1月時点で、certbotはIPアドレス証明書に正式対応していません(GitHub Issue #10346で開発中)。現在は以下のACMEクライアントの使用を推奨します。
acme.shの場合
# standaloneモード
acme.sh --issue \
--server letsencrypt \
-d 203.0.113.1 \
--standalone \
--cert-profile shortlived \
--days 3
# webrootモード
acme.sh --issue \
--server letsencrypt \
-d 203.0.113.1 \
--webroot /var/www/html \
--cert-profile shortlived \
--days 3
# または明示的にサーバーURLを指定
acme.sh --issue \
--server https://acme-v02.api.letsencrypt.org/directory \
-d 203.0.113.1 \
--standalone \
--cert-profile shortlived \
--days 3
重要なパラメータ:
-
--server letsencrypt- Let's Encryptを指定(必須 - acme.shのデフォルトはZeroSSL) -
-d 203.0.113.1- IPアドレスを指定 -
--cert-profile shortlived- 短期証明書プロファイル(必須) -
--days 3- 3日後に更新開始(推奨 - 160時間有効期限の半分以下)
参考情報:
legoの場合
lego --server=https://acme-v02.api.letsencrypt.org/directory \
--email "your@email.tld" \
--accept-tos \
--http \
--domains 203.0.113.1 \
--disable-cn \
run --profile shortlived
重要なパラメータ:
-
--domains 203.0.113.1- IPアドレスを指定 -
--disable-cn- Common Nameフィールドを無効化(必須) -
--profile shortlived- 短期証明書プロファイル
legoの特徴:
- Go言語実装で高速・軽量
- 180以上のDNSプロバイダー対応
- ライブラリとしても利用可能(プログラマブル)
- RFC 8738(IPアドレス証明書)正式対応
参考情報:
certbotの場合(将来対応予定 - 現在は使用不可)
⚠️ 重要な注意
以下の情報は、将来certbotに実装される可能性がある機能についての参考情報です。
2026年1月時点では実装されておらず、使用できません。実際に証明書を取得する必要がある場合は、上記のacme.shまたはlegoを使用してください。
開発状況:
- GitHub Issue: #10346 - IP address subjectAlternativeName certificates
- 現状: ACME libraryレベルでは実装済み、Certbot CLIレベルでの実装待ち
- マイルストーン: certbot 5.3(リリース時期未定)
実装された場合の予想構文(推測):
# 予想される構文例(未確定・動作未検証)
certbot certonly --standalone \
--preferred-challenges http-01 \
-d 203.0.113.1 \
--cert-profile shortlived
# または
certbot certonly --standalone \
--preferred-challenges http-01 \
-d 203.0.113.1 \
--profile shortlived
予想の根拠:
- ACMEプロファイルサポートは既にCertbot 4.0+で実装済み
- GitHub Issue #10346では
-dオプションでIPアドレスを受け付ける方向性が示唆されている - 既存のドメイン証明書取得と同様のコマンド構造になる可能性が高い
注意事項:
- 上記は推測であり、実際の実装時には構文が異なる可能性があります
- 現在、試すことはできません(エラーになります)
- 最新の開発状況はGitHub Issue #10346で確認してくださいませ
その他のACMEクライアント
以下のクライアントもIPアドレス証明書をサポートしています:
- Caddy - Webサーバーに統合、自動HTTPS機能
- traefik - リバースプロキシ・ロードバランサー
- cert-manager - Kubernetes環境向け
- acmez - Go言語ライブラリ
詳細は各クライアントの公式ドキュメントを参照してください。
注意事項
- 完全自動化が必須: 160時間(約6.67日)ごとの更新が必要なため、手動更新は非現実的
- 更新頻度: 有効期限の1/3(約2日)を経過したら更新を開始することを推奨
- モニタリング: 証明書の有効期限切れを検知するアラート設定が重要
- opt-in形式: 現時点では明示的なプロファイル選択が必要(デフォルトではない)
- Rate Limits: Let's Encryptのレート制限に注意(詳細は公式ドキュメント参照)
想定される利用シーン
1. IoTデバイスの直接通信
ドメイン名を持たないIoTデバイス間でのTLS通信を実現します。
2. 内部APIの認証
社内ネットワークなど、DNSが利用できない環境での内部API間の認証に利用できます。
3. Kubernetes等のコンテナ環境
Pod間通信など、動的にIPアドレスが割り当てられる環境での証明書管理を自動化します。
4. 一時的なサーバーインスタンス
クラウド環境で短期間利用されるインスタンスのTLS設定を簡素化します。
5. DNS非依存の認証
DNSインフラに依存せずにTLS認証を実現できます。
技術的な制約事項
Validation Challenge
- 使用可能
- HTTP Challenge (http-01)
- TLS-ALPN Challenge (tls-alpn-01)
- 利用不可
- DNS Challenge (dns-01)
- IPアドレスにはDNS名が存在しないため
- DNS Challenge (dns-01)
短期証明書の必須化
IPアドレス証明書は、必ず短期証明書(160時間)として発行されます。従来の90日証明書として発行することはできません。
証明書の表現形式
CA/Browser Forum Baseline Requirementsにより、IPアドレスはSANにおいてiPAddress形式で記載する必要があります。dNSName形式での記載は認められていません。
ACMEクライアントの選択
IPアドレス証明書は、複数のACMEクライアントで取得可能です。
主要なACMEクライアント(2026年1月時点)
| クライアント | 実装言語 | IPアドレス証明書 | 特徴 |
|---|---|---|---|
| Certbot | Python | 🚧 開発中 | EFF公式、広く利用されている(v5.3で対応予定) |
| acme.sh | Shell Script | ✅ 対応 | 軽量、100以上のDNSプロバイダー対応 |
| lego | Go | ✅ 対応 | 180以上のDNSプロバイダー、ライブラリ利用可能 |
| Caddy | Go | 未確認 | Webサーバー統合、自動HTTPS |
| cert-manager | Go | 未確認 | Kubernetes環境向け |
2026年1月時点での推奨:
-
IPアドレス証明書: acme.shまたはlego(両方とも動作確認済み)
- acme.sh: シンプルで依存関係が少ない
- lego: Go製で高速、プログラムから利用する場合に便利
- ドメイン名証明書: Certbot(広く使われており、情報が豊富)
- 軽量環境: acme.sh(依存関係が少ない)
今後の展開
デフォルト証明書の有効期限短縮
Let's Encryptは、2025年12月の発表で、デフォルトの証明書有効期限を段階的に90日から45日へ短縮することを表明しています。
参考: https://letsencrypt.org/2025/12/02/from-90-to-45
短期証明書運用の実証
IPアドレス証明書の6日間運用は、より短期間の証明書運用の実証実験としての側面もあります。完全自動化されたACMEクライアントを使用している環境では、この短期証明書への移行は比較的容易です。
opt-in継続
現時点では短期証明書はopt-in形式となっており、デフォルトにする計画はありません。すべてのユーザーが完全自動化された更新プロセスを持っているわけではないため、従来の90日証明書も引き続き利用可能です。
まとめ
Let's EncryptのIPアドレス証明書は、RFC 8738に準拠した標準的な実装であり、DNS非依存の環境でのTLS認証を実現します。6日間という短い有効期限は、IPアドレスの一時的な性質とセキュリティ強化の観点から設計されています。
完全自動化されたACMEクライアントの普及により、より短期間の証明書運用が実現可能になりつつあります。この取り組みは、証明書エコシステム全体のセキュリティ向上に寄与するものと期待されます。
参考資料
- Let's Encrypt公式発表
- RFC 8738 - ACME IP Identifier Validation Extension
- RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and CRL Profile
- RFC 8555 - Automatic Certificate Management Environment (ACME)
- RFC 8737 - ACME TLS ALPN Challenge Extension
- Let's Encrypt Certificate Profiles Documentation
- Let's Encrypt IP Certificate Announcement (2025/07/01)
- Certbot GitHub Issue #10346
- acme.sh公式サイト
- lego公式ドキュメント
最後に、GMOコネクトでは研究開発や国際標準化に関する支援や技術検証をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。