Let's Encrypt：DNSチャレンジが静的なのはなぜですか？
私の理解では、LetsEncrypt DNS検証は、静的TXTレコードをDNS（基本的には単なるナンス）に設定し、LetsEncryptサーバーによってチェックされることで機能します。
それについて最初に聞いたとき、私はかなり興奮していて、もっと洗練されたものを期待していました。公開鍵は私のドメインのDNSに保存されています。次に、検証のために、署名されたメッセージを作成し、LetsEncryptサーバーが署名が有効かどうかを確認します。 DNSの公開鍵と私が所有する秘密鍵なので、これは私がドメインを制御しているという証拠を確立します。
このように機能しないことを発見したことは少し残念でした。手動での操作が必要であり、更新の場合でも新しいTXTレコード。
署名アプローチが使用されないという技術的な理由はありますか？いいえの場合、LetsEncryptがそれを実装しない理由は何ですか？
あなたthinkが起こることは、実際に起こることではないと私は信じています。 Let's Encryptは、IETF ACMEワーキンググループのドラフトの現在のバージョン ACMEプロトコル に従います。そのドラフトでは、 セクション8.5 で、TXT）を作成する最初のステップとして、ランダムな文字列（チャレンジで提供）とアカウントキーの両方を使用する必要があります。 =レコードの値。
クライアントは、チャレンジで提供された「トークン」値とクライアントのアカウントキーからキー認証を構築することにより、このチャレンジに応答します。次に、クライアントは、キー認証のSHA-256ダイジェスト [FIPS180-4] を計算します。
アカウントキーの所有とDNSの制御は、ドメインの制御と、証明書を要求するアカウントへの接続の両方を証明するのに十分なはずです。アカウントに関連付けられた公開鍵はDNSで公開されず、LEによって保持されますが、秘密鍵should他の秘密鍵と同様に、サーバー自体に安全に保管してください。
それで、あなたの最後の質問、署名アプローチが使用されないという技術的な理由はありますか？いいえの場合、LetsEncryptがそれを実装しない理由は何ですか？は要点を見逃しているようです。署名が使用されます。