当サイトは、無料 SSL/TLS 証明書発行サービス Let's Encrypt の非公式解説サイトです。
This is an unofficial website about Let's Encrypt.
(非公式解説サイト)
2018年03月15日 更新

ACME v2 とワイルドカード証明書の技術情報

2018年03月13日に本番環境の ACME v2 エンドポイントが使用可能になりました。

エンドユーザーは、ACME v2 互換クライアントで下記の Directory URL を用いることで、本番環境で使用できる SSL/TLS サーバ証明書(ブラウザで信頼済みとして扱われる証明書)を発行することができます。

Directory URL:
https://acme-v02.api.letsencrypt.org/directory

※このエンドポイントにアクセスする際には、ACME v2 に対応したクライアント を使用する必要があります。ACME v2 Compatible Clients をご確認ください。

※Certbot クライアントは、Version 0.22.0 以上が ACME v2 とワイルドカード証明書に対応しています。

背景情報

Let's Encrypt Community Support の過去のアナウンス (英文) をご覧ください。ステージング環境における ACME v2 の可用性や、ACME v2 に関するより詳しい情報が書かれています。

既存のアカウントの使用について

ACME v1 API で使用していた既存の ACME アカウントは、そのまま ACME v2 API で使用できます。

ACME v1 で取得した認可(Authorizations)は、ACME v2 環境においては無効となるため、ACME v2 でドメイン名に対する検証をやり直す必要があります。

ステージング環境(ACME v1 または ACME v2)のアカウントは、本番環境では使用できません。

認可 ID と透明性について

ACME v1 では、第三者による予測が困難な認可 ID(Authorization's ID)が用いられていました。

この方針は透明性を高める目的で大きく変更されており、ACME v2 による認可の際には予測可能な連番 ID 番号による管理が行われます。

そのため、ACME v2 ではドメイン認証の試行に関する下記の情報が第三者によって取得される恐れがあります。

  • DNS によって解決された IP アドレス
  • 認証エラーメッセージ

レート制限

既存のレート制限 が ACME v2 にも適用されます。

ACME v2 API を使用する場合、新しいレート制限(アカウントごとのオーダー数の制限)も適用されます。ACME v2 エンドポイント(本番環境用)においては、新しいオーダー数は、1つのアカウントにつき、3時間ごとに300 までに制限されます。

なお、Pending Authorizations のレート制限も適用され、1つのオーダーが複数の Pending Authorization を生成することがあります。証明書の発行のやり方によっては、新しいレート制限(アカウントごとのオーダー数の制限)の前に、Pending Authorization の制限に引っかかる場合があります。

テストを行う際には、レート制限が緩い Staging endpoint for ACME v2 の使用をお勧めします。

※Staging endpoint で取得できる SSL/TLS 証明書は、無効な証明書(ブラウザで信頼済みとして扱われない証明書)のため、本番環境では使用できません。

ワイルドカード証明書

ACME v2 API は、ワイルドカード証明書の発行に対応しています。

ワイルドカード証明書を取得するには、新しいオーダーリクエストとして、ワイルドカード DNS 識別子を送信します。Let's Encrypt の方針では、ワイルドカード証明書の取得の際には必ず DNS-01 Challenge による認証を行う必要があります。

証明書の発行対象の DNS 名として使用できるワイルドカード文字( * )は1つだけで、かつ DNS ラベルの一番左である必要があります。例えば、*.example.com のように指定する必要があります。

1枚の証明書に、ワイルドカードを含むベースドメイン名を複数含めることや、ワイルドカード以外の FQDN を混ぜることもできます。

※例えば *.example.com*.example.nethoge.example.org のすべてに対応した1枚の証明書を発行することができます。これは、ワイルドカード文字を使った指定と、サブジェクトの代替名(SAN : Subject Alternative Name)の使用が併用された証明書です。

ベースドメインと当該ベースドメインに対するワイルドカードの両方を含むオーダー(例えば example.com*.example.com)も有効です。その場合、example.com のオーダーとして、ベースドメイン名認証とワイルドカード認証の2つの認可オブジェクトが作られます。

なお、冗長な指定を行うことはできません。例えば、*.example.comwww.example.com を含むオーダーは、前者のワイルドカードの指定が後者の FQDN の指定を内包するため、エラーが発生します。

クライアントの互換性

ACME v2 API は ACME v1 API との互換性が無いため、ACME v1 クライアントは ACME v2 エンドポイントでは動作しません。既存のクライアントは、ACME v2 に対応させるため、コードに変更を加えた新たなバージョンを公開する必要があります。

ACME v2 に対応しているクライアントのリストは、ACME v2 Compatible Clients をご覧ください。

Certbot クライアントは、Version 0.22.0 以降が ACME v2 に対応しています。このバージョンは、Certbot のインストール方法や OS のパッケージ管理システムによっては、まだ使用できない場合があります。

※あなたが作成した ACME クライアントを ACME v2 Compatible Clients のリストへ追加したい場合には、Website pull-request(to update the “ACME v2 Compatible Clients” section of the Client Options documentation)を送信してください。

仕様の相違

ACME はまだ最終 RFC ではありません。プロトコルのドラフトは、実装と並行して変更が続けられています。

そのため、Let's Encrypt の実装と draft-ietf-acme-acme-10 には相違点があります。

現在、Let's Encrypt には、下記のプロトコルや機能は実装されていません。

  • 事前認可(Pre-authorization)は、オプション機能であり、実装する予定はありません。ACME v2 クライアントは、事前認可無しのオーダーを発行する必要があります。
  • アカウントオブジェクトの orders フィールドは今のところ実装されていません。近い将来には、この非本質的な機能をサポートする予定です。詳しくは Boulder Issue 333525 をご覧ください。
  • オーダーオブジェクトの ready ステートは実装されていません。関係する認可がすべて有効で finalization が発生する可能性がある場合、オーダーは pending として残留します。クライアントの開発者は、オーダーの準備が完了したかどうかを判定するため、認可ステータスをチェックする必要があります。詳しくは Boulder Issue 3530 をご覧ください。

互換性を破る API の変更

2018年03月29日に、互換性を破る API の変更(最近導入されたプロトコルの相違点の除去)が行われます。

API 変更以降は、すべての ACME v2 クライアントは、すべての JWS authenticated POST リクエストの Content-Type ヘッダーに application/jose+json を含めなければなりません。詳しくは JWS POST Content-Type Header Enforcement をご覧ください。

ACME v2 endpoint に、final ACME RFC を実装する計画があります。そのため、Let's Encrypt Community Support の API Announcements カテゴリー にて事前の情報公開が行われた上で、いくつかの変更が加えられる予定です。

翻訳記事の出典と留意事項

このページ「ACME v2 とワイルドカード証明書の技術情報」は、下記ページの全文を和訳した上で、補足説明などを加えたものです。

Menu
ページトップへ