Value-DomainでcertbotのDNS-01 challengeをやるスクリプトを書き直した中で知ったこと
投稿日:
前の記事でvalue-domain-dns-utilを作り、かつてのvalue-domain-dns-cert-register (vddcr)を焼き直したことを書いたが、あれからいくらか直し、学びも得たので、その記録として残す。
なお、今回行った調査によりvalue-domain-dns-utilのvd-dcr.plでは、複数ドメイン指定(-d hoge.example.com -d fuga.example.com)や、ワイルドカードドメイン指定(-d example.com -d *.example.com)が動作することを確認している。
certbotがauth-hookに渡す環境変数
ドメインを一つだけ指定したとき
--manual-auth-hookに指定したスクリプトが一回だけ走る。
入力
sudo certbot certonly --manual -n --preferred-challenges dns --agree-tos -m postmaster@example.com --manual-auth-hook "/path/to/script" -d hoge.example.com
環境変数
| 変数名 | 値 |
|---|---|
| CERTBOT_DOMAIN | hoge.example.com |
| CERTBOT_VALIDATION | xxxxx |
| CERTBOT_ALL_DOMAINS | hoge.example.com |
ドメインを複数指定したとき
指定した回数分、--manual-auth-hookに指定したスクリプトが走る。
入力
sudo certbot certonly --manual -n --preferred-challenges dns --agree-tos -m postmaster@example.com --manual-auth-hook "/path/to/script" -d hoge.example.com -d fuga.example.com
環境変数
走行一回目
| 変数名 | 値 |
|---|---|
| CERTBOT_DOMAIN | hoge.example.com |
| CERTBOT_VALIDATION | xxxxx |
| CERTBOT_ALL_DOMAINS | hoge.example.com,fuga.example.com |
走行二回目
| 変数名 | 値 |
|---|---|
| CERTBOT_DOMAIN | hoge.example.com |
| CERTBOT_VALIDATION | yyyyy |
| CERTBOT_ALL_DOMAINS | hoge.example.com,fuga.example.com |
ワイルドカードドメインを指定したとき
ドメインを複数指定したときと似た挙動をするが、CERTBOT_DOMAINは二回とも同じものが入り、CERTBOT_ALL_DOMAINSも同じドメインが二個入り、CERTBOT_VALIDATIONだけ異なる値になる。
入力
sudo certbot certonly --manual -n --preferred-challenges dns --agree-tos -m postmaster@example.com --manual-auth-hook "/path/to/script" -d example.com -d *.example.com
環境変数
走行一回目
| 変数名 | 値 |
|---|---|
| CERTBOT_DOMAIN | example.com |
| CERTBOT_VALIDATION | xxxxx |
| CERTBOT_ALL_DOMAINS | example.com,example.com |
走行二回目
| 変数名 | 値 |
|---|---|
| CERTBOT_DOMAIN | example.com |
| CERTBOT_VALIDATION | yyyyy |
| CERTBOT_ALL_DOMAINS | example.com,example.com |
TXTレコードに永続性は不要で、証明書を作るときにだけあればよいということが分かった
私は長らくDNSレコードにtxt _acme-challenge.bts "gfj9Xq...Rg85nM"のような値が存在し続けることに意味があると考えていたが、実際にはそうではなかった。
Challenge Types - Let's EncryptのDNS-01 challengeの仕様には次のようにある。
原文
After Let’s Encrypt gives your ACME client a token, your client will create a TXT record derived from that token and your account key, and put that record at _acme-challenge.<YOUR_DOMAIN>. Then Let’s Encrypt will query the DNS system for that record. If it finds a match, you can proceed to issue a certificate!
日本語訳
Let’s EncryptがACMEクライアントにトークンを渡すと、クライアントはそのトークンとアカウントキーから派生したTXTレコードを作成し、_acme-challenge.<YOUR_DOMAIN>に格納します。その後、Let's EncryptはDNSシステムにそのレコードを照会します。一致するレコードが見つかった場合、証明書の発行に進むことができます。
つまり、DNS-01 challengeにおけるTXTレコードはドメインの所有権を確認するための一時的な検証値に過ぎず、証明書の発行が完了すれば不要になる。
この仕様を知ったことで、ワイルドカードドメイン指定時の懸念が解消された。ワイルドカードでは_acme-challenge.example.comに対して--manual-auth-hookに指定したスクリプトが二度走り、そのままでは二回目で一回目のTXTレコードが上書きされるが、永続する必要がないなら問題にならない。
以前はワイルドカードドメインに対してTXTレコードを二個維持する必要があると考え、「_acme-challengeのTXTレコードがDNS上に二行以上あればワイルドカード用とみなして全削除してから追加、二行未満なら単純に追加」という判別ロジックを検討していた。
しかしこの方法では、前回のレコードが一行だけ残っている場合に破綻する。ワイルドカード指定では--manual-auth-hookに指定したスクリプトが二回走るので、次のようなことが起きる。
- 一回目:既存レコードは一行(前回の残り)なので「二行未満→追加」が選ばれ、計二行になる
- 二回目:既存レコードが二行になったため「二行以上→全削除して追加」が選ばれ、一回目で登録したばかりのレコードごと消えてしまう
このように既存レコード数という外部状態に依存した判別では、初期状態の違いによって正しく動かないケースが生じ、運用でカバーせざるを得なかった。
だが、TXTレコードに永続性は不要で、証明書を作るときにだけあればよいということが分かり、結果としてレコードを永続させる必要がないと分かったことで、このような判別ロジック自体が不要になった。
これによって例外処理をするスクリプトの作成も、それを動かすための運用も考慮しなくてよくなり、vd-dcr.plはシンプルな状態に保てるということが分かったので、とても良かったし、何よりcertbotへの理解が深まったのもよかった。
余談だがCertbotの振る舞いはRFC 8555に定められており、Automatic Certificate Management Environment (ACME)、つまり自動証明書管理環境とされているようだ。有志による日本語訳も存在し、日本語で読むこともできる。
DNS-01 challengeの運用負荷を減らす、新しいDNS-PERSIST-01という方式の登場について
DNS-01 challengeについて調べる中で、DNS-PERSIST-01という新しいACMEチャレンジタイプの存在を知った。これはDNS-01の代替ではなく、DNS-01と併存する別の選択肢として提案されているものだ。
これはまだドラフトだが、今後導入される予定のDNSを利用した証明書の発行方式で、Let's Encryptでは2026年Q2に本番導入が予定されている。
DNS-PERSIST-01の利点は一度DNSに検証文字列を書けば、以降はDNSレコードを触らなくてよいというものである。DNSのAPIを都度叩かなくてよいため、運用面で非常に便利だといえる。当然、セキュリティ面では劣化がある。
欠点はACMEアカウント鍵が漏洩すると、第三者に証明書を発行されるリスクがあることだ。DNS-01 challengeでは更新の都度、ランダムな検証文字列を設定して検証するのでこの問題は起きない。
要するにDNSレコードを弄らない代わりに鍵を使う方式と、DNSレコードを弄る代わりに盗まれる物がない方式の二つになるということだ。
DNS-PERSIST-01でもセキュリティのために、ACMEアカウント鍵に有効期限を設けられるようだが、それだと本末転倒にも思う。勿論、そういうケースが役に立つ場合もあるだろうが、運用は大変そうだ。