要約

  • draft-ietf-acme-profiles-02 は、ACMEサーバー固有の証明書プロファイルをDirectoryで広告し、選んだ名前をOrderに固定する。現時点では標準化過程のInternet-Draftであり、RFCでも世界共通のプロファイル辞書でもない。
  • Orderに名前が入ったことは方針選択の受理を示すが、アカウント資格、識別子の支配、発行証明書の適合、配備、依存者の受容は別々の確認事項である。
  • 実務では、選択時のDirectoryと説明文を保存し、発行されたDER、実際の配備先、利用クライアントの結果までをつなぐ必要がある。

更新ジョブは成功し、Orderには tlsserver と記録されている。だが、東京のロードバランサーは新しい証明書を返し、別地域のノードは古い証明書を返す。あるクライアントは接続し、別の信頼ストアを使う端末はチェーンを構築できない。

この状況でプロファイル名が証明できるのは、ACME制御面で何が選ばれたかまでだ。どの拡張を持つ証明書が実際に署名され、どこに置かれ、誰に受け入れられたかは、その後の証拠である。

draft-ietf-acme-profiles-02 は2026年8月28日付のACME Working Group Standards Track Internet-Draftだ。CAが異なる種類の証明書を提供しても、RFC 8555だけではクライアントがそれを発見し、明示的に選ぶ標準的な場所がないという問題に対処する。実装注記は二つのサーバーと七つのクライアントを挙げ、Let’s Encryptは実運用を公表している。ただしrevision 02はなお作業中であり、実装一覧は独立した普及調査ではない。

名前はサーバーの方針を指す

選択を許すサーバーはDirectoryのmetaにprofilesを載せる。短い名前を、人が読める説明URLへ対応付ける。クライアントはnewOrderのprofileに名前を入れ、受理されたOrderはその名前を返す。

この仕組みは意図的に小さい。名称はサーバー側の名前空間に属する。classicやshortlivedが別のCAでも同じ挙動を意味するとは規定されない。説明URLも、すべての証明書フィールドを機械判定できるスキーマではない。data URIを使うことさえできる。

従って、文字列はサーバー方針へのセレクターである。ポータブルな品質証明ではない。だからこそ、DirectoryのURL、応答ハッシュ、取得日時、TLS相手、説明文のバイト列、アカウント固有の条件を一緒に保存する必要がある。名前だけをログに残すと、意味を与えた文脈が消える。

この限定は欠点ではない。共通仕様は、方針を発見してOrderへ結び付けるために必要な最小面だけを定める。各CAの製品設計や各利用者の受容条件まで中央集権化しない。

CSRから外れるのは方針選択である

RFC 8555では、newOrderに識別子と有効期間の希望を置き、finalize時にCSRを送る。CSRは多様なX.509フィールドや拡張を含められる。CAがそれを無検査で複写すれば、構文解析と方針違反の危険が増える。

Profile拡張は証明書種別の選択をOrderに置く。草案は、Subject Alternative NameとSubject Public Key以外のCSR内容を、この方針判断から切り離せると説明する。CAはクライアントが並べた拡張ではなく、自身のテンプレートに基づいて証明書を組み立てる。

ただし「CSRは不要になった」と言ってはいけない。公開鍵は不可欠で、SANは認可された識別子に関係する。CAには、適切な発行、署名、チェーン選択、ポリシー遵守、必要な透明性処理が残る。改善点は、方針入力の場所が明確になったことだ。

Orderのフィールドを確認するだけでは、実際のCredentialを見ていない。Running-Code Primacyの観点では、決定的なのはサーバーが返した最終バイトである。

クライアントの選択とサーバーの既定値を区別する

クライアントが明示的にProfileを送った場合、署名済みACME要求はアカウント鍵がその文字列を含む要求を承認した証拠になる。サーバーはなお、識別子やアカウント条件との整合性を判定する。

クライアントが省略した場合、草案はサーバーがProfileを選び、Orderに関連付けることを推奨する。この経路では、Orderの値はサーバー選択の記録であり、利用者の能動的な意思ではない。

監査ログには選択主体を残すべきだ。クライアントの版、設定元、アカウント、要求、Order応答、サーバー方針版、設定を変更できる担当者も必要になる。そうして初めて「早期採用者が選んだ変更」と「既定値が変わり、未変更のクライアントが追随した変更」を区別できる。

Let’s Encryptの移行計画はこの差を具体化する。TLS Client Authentication EKUの削除や証明書寿命の短縮を、任意選択のProfileから始め、後に既定のclassicへ反映する。どちらも計画的でも、意思決定の所在は同じではない。

Profile資格と識別子認可は別の関門

サーバーは、Profileと要求内容が非互換なら拒否しなければならない。例えばTLSサーバー用Profileにメール識別子を組み合わせる場合や、必要なallowlistにアカウントがない場合だ。提案されるエラーがinvalidProfileである。

これはドメイン支配の検証ではない。企業アカウントが私的Profileを使う資格を持っても、対象ドメインを支配しているとは限らない。DNS-01やHTTP-01に成功しても、特別なProfileを利用する契約権限までは得られない。

アカウント資格、識別子認可、発行方針を三つのレシートに分ける。External Account Binding、契約、課金、事故承認、allowlistは一つ目に関係する。チャレンジ記録は二つ目。CAの判断と発行証明書は三つ目を支える。

一つのOrder画面に並ぶからといって、権限が一つになるわけではない。アカウント鍵の署名は、すべての名前の支配やすべての証明書能力を証明しない。

広告されないProfileには例外権限が要る

草案は、広告していない名前を通常は拒否するよう求める一方、特別な事情での受理を許す。例として、事前に合意した私的Profileと、大規模失効時に既に廃止されたProfileの証明書を置換するケースがある。

この柔軟性は継続性のために重要だ。Directoryが唯一の権限源になることを防ぐ。しかし、Directoryにないことが無効の証拠ではなくなる。

例外では、合意やインシデント番号、対象アカウント、期間、制約、承認者、置換目的、撤回方法、一般アカウントが利用できなかった証拠を保存する。非公開であること自体を不正とみなす必要はない。権限をたどれないことが問題である。

廃止には広告の時計とOrderの時計がある

ProfileをDirectoryから消しても、以前に作ったOrderは生きていることがある。finalize時点でCAがその方針で発行しないなら、サーバーはinvalidProfileを返す必要がある。草案は、既存Orderが期限切れになるまで発行を維持し、この衝突を避けるよう推奨する。

広告停止と発行停止を一つの日付で扱ってはいけない。開始、既定値変更、最終受付、最長Order期限、最終発行、残る更新、代替Profile、例外期間を台帳にする。クライアントが終盤でエラーを受けたとき、ネットワーク障害やCSR不良と区別できる。

同じ名前の意味が変わる場合はさらに難しい。有効期間、EKU、認可再利用、チェーンが変更されてもセレクターは同一かもしれない。各Orderが参照した説明を凍結し、更新ごとに実証明書を確認する必要がある。

適合判定の対象はDERである

Orderはサーバーの方針コミットメントだ。検査可能な成果物は署名された証明書である。

DERを解析し、版管理されたProfile条件と比較する。SAN集合、識別子型、鍵アルゴリズム、Key Usage、Extended Key Usage、Basic Constraints、証明書ポリシー、critical属性、有効期間、Issuer、署名方式、チェーン、シリアル、CT証拠、禁止フィールドを対象にする。

証明書をOrder、認可記録、CSR公開鍵へ結び付けることも必要だ。そうしなければ「条件に合う証明書」は示せても、「この取引から生まれた証明書」は示せない。

人向け文書は選択に役立つが、自動検査には曖昧だ。CAが機械可読の適合マニフェストを追加公開すれば、中央Profile登録簿を作らずに、自身の約束を検証可能にできる。これは本稿の運用提案であり、草案の要件ではない。

更新でも同じ検査を行う。同一名称は同一の寿命、チェーン、拡張、方針版を保証しない。ACME応答だけを検証する自動化は、制御面だけを検査している。

CTとCAAは別の観測である

Certificate Transparencyは証明書やprecertificateがログに提出されたことを示せる。利用者がどのProfileを選んだか、その方針に適合したか、配備されたかは示さない。

CAAは発行可能なCAを制限し、独自の意味でアカウントや検証方法を拘束できる。ACME Profileを選択したり、証明書フィールドを保証したりはしない。

独立しているから価値がある。チェーン構築も同様で、CAが提供した経路とクライアントが信頼ストアから構築する経路は異なり得る。Profile意図は利用側の信頼判断を命令できない。

配備は最後の別工程である

発行された証明書は、対応する秘密鍵と共に正しいサービスへ配置される必要がある。ロードバランサー、地域レプリカ、シークレットストア、sidecar、再起動されていないプロセスが部分配備を生む。

DERハッシュと公開鍵ハッシュを各ターゲットへ結び付け、外部から実際に提示される証明書を観測する。SNI、サービスID、チェーン、稼働開始、旧証明書の停止を確認し、代表的なクライアントで試験する。

証拠鎖は 発見 -> 保存 -> 選択 -> 資格 -> 識別子認可 -> Order固定 -> finalize -> DER検査 -> 配備 -> 観測 -> 更新 となる。前段が正しくても後段は失敗できる。単一の緑色表示ではなく、どこまで通ったかを示すべきだ。

実運用はProfileの移行能力を示した

Let’s EncryptはProfileを、検証過程と最終証明書特性の集合として説明する。一般利用者は自動選択を使え、特別な要件がある運用者は明示選択できる。

EKU移行では、tlsserverでClient Authentication EKUを先に外し、既定のclassicを後で変更し、移行猶予用のtlsclientを期限付きで用意した。寿命移行では45日や6日の選択肢を先行させ、後に既定を短くする計画を公表した。

これは実装が変化を段階化できる証拠だ。同時に、名前には時点が必要だと示す。寿命、EKU、認可再利用、提供期間は別々に動く。公表資料は全利用者の成功や全クライアントの対応を証明するものではない。

Profileレシートを作る

レシートにはDirectoryと説明文のハッシュ、名前、選択主体、アカウントと設定権限、識別子、鍵ハッシュ、資格規則、ACME認可、Orderと期限、CSRハッシュ、DER、シリアル、Issuer、チェーン、CT、適合検査、設置先、外部観測、利用側試験、更新日程、例外承認、失効・ロールバックを結び付ける。

「Orderが名前を返した」は観測。「Profile版Xに適合した」は検査結果。「このエンドポイントが当該DERを提示した」も観測。「サービス成果を得た」はその後の結論である。

プロトコルは小さく保てる。各参加者が必要な証拠を局所的に保持する。ラベルを万能にするより、相互運用と責任の両方に適している。