RFC 8555 - 自動証明書管理環境 (Automatic Certificate Management Environment, ACME)

インターネット技術特別調査委員会 (IETF) Request for Comments: 8555 カテゴリ: 標準化過程 ISSN: 2070-1721

著者: R. Barnes (Cisco) J. Hoffman-Andrews (EFF) D. McCarney (Let's Encrypt) J. Kasten (University of Michigan)

発行日: 2019年3月

概要 (Abstract)

X.509を使用する公開鍵基盤 (Public Key Infrastructure using X.509, PKIX) 証明書は、さまざまな目的で使用されますが、最も重要なのはドメイン名認証です。したがって、Web PKI内の証明機関 (Certification Authorities, CAs) は、証明書申請者が証明書内のドメイン名を正当に代表していることを検証することが信頼されています。本文書執筆時点では、この検証は一連の臨時的なメカニズムを通じて完了しています。本文書は、CAと申請者が検証および証明書発行プロセスを自動化するために使用できるプロトコルについて説明します。このプロトコルは、証明書失効など、他の証明書管理機能のための機能も提供します。

本メモのステータス (Status of This Memo)

これはインターネット標準化過程文書です。

本文書は、インターネット技術特別調査委員会 (IETF) の成果物です。これはIETFコミュニティの合意を表しています。公開レビューを受けており、インターネット技術運営委員会 (IESG) によって発行が承認されています。

目次 (Table of Contents)

1. はじめに (Introduction)
2. 展開モデルとオペレータ体験 (Deployment Model)
3. 用語集 (Terminology)
4. プロトコル概要 (Protocol Overview)
5. 文字エンコーディング (Character Encoding)
6. メッセージ転送 (Message Transport)
- 6.1 HTTPSリクエスト
- 6.2 リクエスト認証
- 6.3 GETおよびPOST-as-GETリクエスト
- 6.4 リクエストURL完全性
- 6.5 リプレイ保護
- 6.6 レート制限
- 6.7 エラー
7. 証明書管理 (Certificate Management)
8. 識別子検証チャレンジ (Validation Challenges)
- 8.1 鍵承認
- 8.2 チャレンジの再試行
- 8.3 HTTPチャレンジ
- 8.4 DNSチャレンジ
9-12. 重要章の要約
- 9. IANA考慮事項
- 1. セキュリティ考慮事項
- 1. 運用考慮事項
- 1. 参考文献

1. はじめに

Web PKI内の証明書は、ドメイン名の認証に最も一般的に使用されます。したがって、Web PKI内の証明機関は、証明書申請者が証明書内のドメイン名を正当に代表していることを検証することが信頼されています。

証明書タイプは、CA が証明書サブジェクト情報に対して実行するさまざまな検証レベルを反映しています:

ドメイン検証 (Domain Validation, DV): 最も一般的なタイプで、CAは申請者がドメイン名を有効に制御していることのみを検証します
組織検証 (Organization Validation, OV): 組織の実在性を検証します
拡張検証 (Extended Validation, EV): 最も厳格な検証で、詳細な身元確認が含まれます

既存のWeb PKI証明機関は、証明書発行と身元認証に一連の臨時的なプロトコルを使用する傾向があります。DV証明書の典型的なユーザー体験は次のとおりです:

PKCS#10証明書署名要求 (Certificate Signing Request, CSR) を生成する
CSRをCAのWebページにコピー＆ペーストする
さまざまな方法でドメイン名制御権を証明する（メール検証、ファイル検証など）
発行された証明書を手動でダウンロードする

ACMEの目標: プロセス全体を標準化および自動化し、証明書の取得と更新を完全に自動化します。

2. 展開モデルとオペレータ体験

典型的なACMEワークフロー:

クライアント (ACME Client)                  ACMEサーバー (CA)
       |                                        |
       |  1. アカウント作成                      |
       |--------------------------------------->|
       |     <-- アカウントURL                  |
       |                                        |
       |  2. 証明書注文送信                      |
       |--------------------------------------->|
       |     <-- 注文オブジェクト + 承認チャレンジ |
       |                                        |
       |  3. ドメイン検証チャレンジ完了          |
       |     (HTTP-01 または DNS-01)           |
       |--------------------------------------->|
       |     <-- 検証成功                       |
       |                                        |
       |  4. 注文完了 (CSR送信)                 |
       |--------------------------------------->|
       |     <-- 証明書URL                      |
       |                                        |
       |  5. 証明書ダウンロード                  |
       |--------------------------------------->|
       |     <-- PEM形式証明書チェーン          |

自動化のメリット:

⚡ 人的介入ゼロ: 完全自動化された証明書申請と更新
🔄 頻繁な更新: 短期証明書をサポート（Let's Encryptデフォルト90日）
💰 コスト削減: 手動プロセスコストの削減
🔒 セキュリティ向上: 短期証明書により漏洩リスクを軽減

3. 用語集

ACMEクライアント (ACME Client) ACMEプロトコルを実装するクライアントソフトウェアで、証明書申請者を代表してCAと対話します。

ACMEサーバー (ACME Server) CAが運用するサーバーで、証明書を自動的に発行するためにACMEプロトコルを実装しています。

アカウント (Account) ACMEサーバー上のクライアント登録で、鍵ペアと連絡先情報に関連付けられています。

注文 (Order) クライアントが証明書発行を要求するリクエストオブジェクト。

承認 (Authorization) クライアントが識別子（通常はドメイン名）を制御していることを証明するオブジェクト。

チャレンジ (Challenge) ACMEサーバーがクライアントに完了を要求する検証タスク。

識別子 (Identifier) 証明書で認証される名前で、通常はドメイン名です。

技術的特徴:

✅ 完全自動化: 申請から更新まで完全自動 ✅ 標準化: IETF標準、複数のCAがサポート ✅ 安全: 暗号署名とチャレンジ-レスポンス検証に基づく ✅ 柔軟: HTTPおよびDNS検証方式をサポート

人気のACMEクライアント:

Certbot (EFF公式)
acme.sh (シェルスクリプト)
Lego (Go言語)
win-acme (Windows)

関連RFC:

RFC 7515 - JSON Web Signature
RFC 5280 - X.509証明書
RFC 6797 - HSTS

詳細な技術仕様については、各章の文書を参照してください。

概要 (Abstract)​

本メモのステータス (Status of This Memo)​

目次 (Table of Contents)​

1. はじめに​

2. 展開モデルとオペレータ体験​

3. 用語集​