Let's Encrypt

チャレンジのタイプ

最終更新日: | すべてのドキュメントを読む

注意: このページが翻訳された後、英語バージョンのページがアップデートされています。 () 英語で表示する

Let’s Encrypt から証明書を取得するときには、ACME 標準で定義されている「チャレンジ」を使用して、証明書が証明しようとしているドメイン名があなたの制御下にあることを検証します。ほどんどの場合、この検証は ACME クライアントにより自動的に処理されますが、より複雑な設定を行った場合、詳細な仕組みについて知っておくと役に立つはずです。よく分からない場合には、クライアントのデフォルトの設定か、HTTP-01 を使用してください。

HTTP-01 チャレンジ

現在、最も多く使われているチャレンジです。Let’s Encrypt は ACME クライアントにトークンを発行し、ACME クライアントはウェブサーバー上の http://<YOUR_DOMAIN>/.well-known/acme-challenge/<TOKEN> という場所に1つのファイルを設置します。このファイルにはトークンに加えて、あなたのアカウントのキーのフィンガープリントが含まれています。ACME クライアントがLet’s Encrypt にファイルが準備できたことを伝えると、Let’s Encrypt はそのファイルを取得しようとします (複数の有効な場所から複数回取得する可能性もあります)。私たちの検証チェックであなたのウェブサーバーから正当なレスポンスが得られた場合、検証は成功したとみなされ、証明書の発行に進むことができます。検証チェックに失敗した場合には、新しい証明書の発行を再試行する必要があります。

私たちの HTTP-01 チャレンジの実装は、リダイレクトを最大 10 回まで追跡します。追跡されるのは、“http:” から “https:” へのリダイレクトで、80 番ポートから 443 番ポートへのリダイレクトのみです。IP アドレスへのリダイレクトは許可されません。HTTPS URL へのリダイレクトである場合、証明書の検証は行いません (というのも、このチャレンジは、有効な証明書のブートストラップを意図したものであり、HTTPS URL へのリダイレクトの場合、途中で自己署名証明書や有効期限切れの証明書が存在する可能性があるためです)。

HTTP-01 チャレンジは 80 番ポートでのみ実行可能です。クライアントに任意のポートを指定できるようにしてしまうと、チャレンジのセキュリティが低下してしまうため、ACME 標準ではポートの変更は許可されていません。

利点:

欠点:

DNS-01 チャレンジ

このチャレンジは、あなたのドメイン名が登録されている DNS があなたの制御下にあることを証明するために、ドメイン名の TXT レコードに特定の値を設定することを求めます。HTTP-01 に比べると設定が難しいですが、HTTP-01 が動作しない状況でも適切に動作します。Let’s Encrypt が ACME クライアントにトークンを与えると、あなたのクライアントは、与えられたトークンとあなたのアカウントの鍵から作られた TXT レコードを生成し、そのレコードを DNS の _acme-challenge.<YOUR_DOMAIN> の値として設定します。その後、Let’s Encrypt は DNS システムにそのレコードを問い合わせます。もし正しい値とマッチすれば、証明書の発行に進むことができます。

発行と更新の自動化は非常に重要なので、DNS-01 チャレンジの使用は、あなたの DNS プロバイダが自動的なアップデートに利用できる API を提供していなければ有効ではありません。私たちのコミュニティでは、対応する DNS プロバイダのリストを作成しています。あなたの DNS プロバイダはレジストラ (ドメイン名を購入した会社) と同じ場合もありますが、違うこともあります。DNS プロバイダの変更は、レジストラに小さな変更を加えるだけで行えます。ドメインの有効期限が近づくまで待つ必要はありません。

DNS API の完全な認証情報をウェブサーバーにおいてしまうと、ウェブサーバーがクラックされた場合に受ける影響が非常に大きくなってしまいます。ベストプラクティスは、より狭いスコープに制限された API 認証情報を使用するか、DNS 検証を別のサーバーで行い、ウェブサーバー用の証明書を自動的にコピーするようにすることです。

Let’s Encrypt は DNS-01 検証で TXT レコードを検索するときに DNS 標準に従っているので、CNAME レコードや NS レコードを使用することで、他の DNS ゾーンへチャレンジの回答を移譲できます。この機能は、検証用のサーバーやゾーンへ _acme-challenge サブドメインを移譲するときに利用することができます。また、あなたの DNS プロバイダの更新が遅くて、より更新の早いサーバーに移譲したい場合にも利用できます。

ほとんどの DNS プロバイダには、DNS レコードを更新してからプロバイダのサーバー全体に情報が反映されるまでの時間を定める「伝搬時間 (propagation time)」が設定されています。複数のサーバーに同一の IP アドレスを持たせることができるエニーキャストが利用されることも多く、世界のどの場所にいるかによって、同じ IP アドレスでも Let’s Encrypt とは違うサーバーと通信してしまい、レスポンスが異なることがあるため、正確な伝搬時間を測定するのは難しい場合があります。最善の DNS API では、完全に伝搬したかどうかを自動的にチェックする方法が提供されています。DNS プロバイダがこの手段を提供していない場合、検証を実行する前に更新した情報が伝搬されていることを確実にするために、クライアントが十分長い時間 (通常は最大1時間) 更新を待機するように設定する必要があります。

同じ名前の場所に対して、複数の TXT レコードを設定することもできます。たとえば、ワイルドカードと非ワイルドカードの証明書に対するチャレンジを同時に検証する必要があるかもしれません。ただし、レスポンスのサイズが大きすぎると Let’s Encrypt はリジェクトするため、古い TXT レコードは削除しておくべきです。

利点:

欠点:

TLS-SNI-01 チャレンジ

このチャレンジは、ACME のドラフトバージョンで定義されました。このチャレンジでは、443 ポートで TLS のハンドシェイクを行い、特定の SNI ヘッダを送信し、トークンを含んでいる証明書を探します。十分にセキュアではないことが判明したため、2019年3月に無効化されました。

TLS-ALPN-01 チャレンジ

このチャレンジは TLS-SNI-01 が非推奨となった後に開発され、別の標準として開発が行われています。TLS-SNI-01 と同様に、443 番ポート上の TLS で実行されます。ただし、カスタムの ALPN プロトコルを使用することで、このチャレンジの種類を知ることができるサーバーのみが検証リクエストに応答できることが保証されます。さらに、このタイプのチャレンジの検証リクエストが、継承しようとしているドメイン名にマッチする SNI フィールドを利用できるようにすることで、より安全性が高まります。

このチャレンジはほとんどの人には適しません。最適なのは、HTTP-01 のようなホストベースの検証を実行したいが、関心の分離を行うために完全に TLS レイヤーで検証を行いたいと考えているような、終端が TLS となっているリバース・プロキシの提供者です。現在の主な対象は大規模なホスティング・プロバイダですが、将来は、Apache や Nginx などのメインストリームのウェブサーバーでも実装される可能性があります (Caddy ではすでに実装されています)。

利点:

欠点: