Let's Encrypt

チャレンジの種類

デンマーク語で見る

ドイツ語で表示

スペイン語で見る

フィンランド語で見る

フランス語で見る

ヘブライ語で見る

ハンガリー語で表示

日本語で表示する

韓国語で見る

ロシア語で表示

ウクライナ語で表示

簡体中国語ページを読む

繁体中国語でこのページを読む。

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

Let's Encrypt から証明書を取得する際、当社のサーバーは、ACME 標準で定義されている「チャレンジ」を使用して、その証明書内のドメイン名を制御していることを検証します。ほとんどの場合、この検証は ACME クライアントによって自動的に処理されますが、より複雑な構成の決定を行う必要がある場合は、それらについて詳しく知っておくと役立ちます。不明な場合は、クライアントのデフォルト設定または HTTP-01 を使用してください。

HTTP-01 チャレンジ

これは現在最も一般的なチャレンジの種類です。Let's Encrypt は ACME クライアントにトークンを与え、ACME クライアントは Web サーバー上の http://<YOUR_DOMAIN>/.well-known/acme-challenge/<TOKEN> にファイルを配置します。そのファイルには、トークンとアカウントキーのサムプリントが含まれています。ACME クライアントが Let's Encrypt にファイルの準備ができたことを通知すると、Let's Encrypt は (複数の視点から複数回) ファイルの取得を試みます。当社の検証チェックが Web サーバーから正しい応答を取得した場合、検証は成功したとみなされ、証明書の発行に進むことができます。検証チェックが失敗した場合は、新しい証明書で再試行する必要があります。

HTTP-01 チャレンジの実装は、最大 10 回のリダイレクトを追跡します。「http:」または「https:」へのリダイレクトのみを許可し、ポート 80 または 443 のみにリダイレクトします。IP アドレスへのリダイレクトは許可しません。HTTPS URL にリダイレクトされた場合、証明書を検証しません (このチャレンジは有効な証明書をブートストラップすることを目的としているため、途中で自己署名証明書または有効期限切れの証明書に遭遇する可能性があるためです)。

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

利点

欠点

DNS-01 チャレンジ

このチャレンジでは、ドメイン名の DNS を制御していることを証明するために、そのドメイン名の TXT レコードに特定の値を入力する必要があります。HTTP-01 より構成が難しいですが、HTTP-01 では不可能なシナリオで機能します。また、ワイルドカード証明書を発行することもできます。Let's Encrypt が ACME クライアントにトークンを渡した後、クライアントはそのトークンとアカウントキーから派生した TXT レコードを作成し、そのレコードを _acme-challenge.<YOUR_DOMAIN> に配置します。次に、Let's Encrypt はそのレコードについて DNS システムにクエリを実行します。一致するものが見つかれば、証明書を発行するに進むことができます。

発行と更新の自動化が非常に重要であるため、DNS プロバイダーに更新を自動化するために使用できる API がある場合にのみ DNS-01 チャレンジを使用することが理にかなっています。私たちのコミュニティは、そのような DNS プロバイダーのリストをここに作成しました。DNS プロバイダーは、レジストラ (ドメイン名を購入した会社) と同じである場合もあれば、異なる場合もあります。DNS プロバイダーを変更する場合は、レジストラでいくつかの小さな変更を行うだけで済みます。ドメインの有効期限が切れるまで待つ必要はありません。

Web サーバーに完全な DNS API 認証情報を配置すると、その Web サーバーがハッキングされた場合に影響が大幅に大きくなることに注意してください。ベストプラクティスは、より狭い範囲に絞った API 認証情報を使用するか、別のサーバーから DNS 検証を実行し、Web サーバーに証明書を自動的にコピーすることです。

Let's Encrypt は DNS-01 検証のために TXT レコードを検索する際に DNS 標準に従うため、CNAME レコードまたは NS レコードを使用して、チャレンジへの応答を他の DNS ゾーンに委任できます。これは、_acme-challenge サブドメインを検証専用のサーバーまたはゾーンに委任するために使用できます。また、DNS プロバイダーの更新が遅い場合に、より早く更新するサーバーに委任したい場合にも使用できます。

ほとんどの DNS プロバイダーには、「伝播時間」があり、DNS レコードを更新してから、すべてのサーバーで利用可能になるまでの時間を管理しています。多くの場合、エニーキャストを使用しているため、測定が難しい場合があります。つまり、複数のサーバーが同じ IP アドレスを持つことができ、世界のどこにいるかによっては、Let's Encrypt とは異なるサーバーと通信している (そして異なる応答を取得している) 可能性があります。最適な DNS API は、更新が完全に伝播されたかどうかを自動的に確認する方法を提供します。DNS プロバイダーにこれがない場合は、検証をトリガーする前に、更新が伝播されるのを十分に待つ (多くの場合、1 時間も待つ) ようにクライアントを構成する必要があります。

同じ名前で複数の TXT レコードを配置できます。たとえば、ワイルドカード証明書と非ワイルドカード証明書のチャレンジを同時に検証している場合に、これが起こる可能性があります。ただし、古い TXT レコードは必ずクリーンアップする必要があります。応答サイズが大きすぎると、Let's Encrypt が拒否し始めるためです。

利点

欠点

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 のような主流の Web サーバーは、いつかこれを実装できる可能性があります (Caddy はすでに実装しています)。

利点

欠点