Let’s Encryptの証明書発行操作について、これまではhttp/httpsを使う HTTP-01 を使っていたのだが、DNSを使う手段もある、というので確認してみた
example.comドメインで「mail.example.com」の証明書を発行する、とした場合、DNSに「_acme-challenge.mail.example.com」という名前でTXTレコードを追加して発行処理を行うようだ
全体の流れとしては下記の様な感じ
① アカウント登録（初回のみ）
② 当該サーバ → LEサーバ：「mail.example.com の証明書がほしい」（order）
→ LEサーバからdns-01 チャレンジ用のトークン を受け取る
③ 当該サーバ：DNSにTXTレコード登録
トークンとアカウントキーから値を計算し、
_acme-challenge.mail.example.com のTXT レコードに登録
→ セカンダリDNSにも反映されるまで待つ
④ 当該サーバ → LEサーバ：反映されたことを通知
⑤ LEサーバ → 権威DNS：
・_acme-challenge.mail.example.com の TXT を複数ネットワークのLEサーバから確認
・CAA レコードでLet’s Encrypt による証明書の発行が許可されているかを確認（CAAがなければ許可扱い）
（mail.example.com → example.com の順で確認）
→ 検証OK
⑥ 当該サーバ：DNSに登録したレコード削除
_acme-challenge.mail.example.comのTXTレコードを削除
⑦ 当該サーバ → LEサーバ： CSR を送信（finalize）
→ LEサーバ上から証明書をダウンロード
⑥⑦の実施順は逆の場合がある
認可が有効期間内の場合、②の段階で検証済みと応答されることで③～⑥のプロセスが省略されることがある
そう、確認において、mail.example.com のAレコード/AAAAレコードは確認されないし、Let’s Encryptサーバ側からのアクセスは行われないので、NATの内側にある内部向けのサーバであっても証明書発行が可能なようだ。
これは意外なことだった
問題点は、コマンドを使って _acme-challenge.mail.example.com のTXTレコードを登録/削除処理を行えるような DNSサーバなのか？ということ
certbotコマンドでは RFC 2136 Dynamic DNS Update を使うことが想定されている。その際の認証は TSIG (RFC 8945、Secret Key Transaction Authentication for DNS)を使用する。
各DNSシステムで実装の差異などがあるので「DNS providers who easily integrate with Let’s Encrypt DNS validation」を確認すると、certbot や acme.sh などで対応しているものを確認することができる