最終更新日: | すべてのドキュメントを読む
Let’s Encript では、ACME クライアントを使用した ACME API へのアクセスでも、ドメイン名の所有権を検証するときに行う DNS ルックアップと HTTP リクエストでも、IPv6 をサポートしています。
ドメインの検証
IPv4 と IPv6 アドレスの両方 (例: A と AAAA レコード) を持つドメインに対して、外向きのドメイン検証のリクエストを行う場合、Let’s Encrypt は最初のコネクションでは常に IPv6 を優先して使用します。 IPv6 の接続がネットワークレベル (例えば、タイムアウト) で失敗して、IPv4 アドレスが利用可能な場合は、IPv4 アドレスの1つを使ってリクエストをリトライします。
誤った IPv6 アドレス
ドメインの所有者がドメインの AAAA レコードに理解していないことがよくあります。 AAAA レコード内の IPv6 アドレスが正しくない場合、ドメインの検証プロセスに影響があります。
通常、IPv6 アドレスは、ACME クライアントが実行されている IPv4 アドレスとは異なるサーバーになります。 その場合、ACME クライアントがチャレンジに応答する IPv4 サーバーだけを設定しているため、IPv6 サーバーが使われた場合にドメイン検証は失敗します。
ほとんどの場合、正しい修正方法は、ACME クライアントが動作しているサーバーを指すように IPv6 アドレスを更新することです。ドメインが IPv6 で動作することを想定していない場合は、AAAA レコードを削除します。 Let’s Encrypt が IPv4 を優先するようにリクエストする方法はないため、誤った設定を修正する必要があります。
IPv6 から IPv4 へのリトライの詳細
IPv6 から IPv4 へのリトライは、接続タイムアウト時にのみ行われ、他のタイプのエラーでは行われません。
たとえば、「よくある落とし穴」のシナリオは、ウェブサーバーが IPv6 アドレスを listen しているものの、ACME チャレンジに応答する準備ができていないとき、リトライが起こらないというものです。 この場合、IPv6 アドレスへのアクセス時に接続のタイムアウトは発生せず、チャレンジはリトライなしに失敗します。不正確な応答が返ってくるためです。
Let’s Encrypt の CA ソフトウェアをシンプルなものにするため、“http-01” チャレンジを検証するときには、最初のリクエスト時にだけ IPv6 から IPv4 へのリトライを実行します。 リダイレクトを使用する場合、リダイレクトはリトライされません。
たとえば、ドメイン名が常にタイムアウトする AAAA レコードを持ち、HTTP から HTTPS にリダイレクトするウェブサーバーの A レコードを持つ場合、IPv6 から IPv4 へのフォールバックは正しく動作しません。 まず、ドメインへの最初のリクエストは IPv4 に適切にフォールバックし、HTTP から HTTPS へのリダイレクトを受け取ります。 後続のリクエストは再度 IPv6 アドレスを優先しますが、タイムアウトして IPv4 へのフォールバックは行われません。 この状況を解決するには、IPv6 の誤った設定を修正する方法と、ACME の HTTP-01 チャレンジバスに対するリクエストに対しては HTTP から HTTPS へのリダイレクトの設定を削除するという方法があります。
助けを得る
IPv6 関連の問題を調べるのに助けが必要な場合は、コミュニティ フォーラムで相談してください。