- セクティゴ・コモドSSLトップ
- ＞ サポート
サポート
◆ こちらからサポート記事を検索いただけます
注文・設定方法など （CaaS関連）
Certbot クライアントでドメインのDNS TXT レコードを自動で更新するための手順
BIND DNS サーバを API 経由で操作するには、通常、BIND のゾーンファイルを直接操作するか、ISC Kea のような次世代の DNS サーバで API 機能を利用する方法が考えられますが、CertbotなどのACMEクライアント本体がこれらと直接連携する機能はありません。
それぞれのプロバイダのマニュアルに従い設定してください
もし BIND サーバが RFC 2136 (DNS ダイナミックアップデート) をサポートしている場合、certbot-dns-rfc2136 プラグインを利用できる可能性があります。これは、DNS のレコードを動的に更新するための標準的なプロトコルです。
要件: BIND サーバがダイナミックアップデートを受け入れるように設定されていること。 キーファイル(TSIGキー)を生成し、Certbot がそのキーを使って認証できるようにすること。
BIND 9系であれば RFC 2136 (DNS ダイナミックアップデート) をサポートしています。
RFC 2136 で定義されているダイナミックアップデート機能は、BIND のバージョン9系ではかなり古いバージョンからサポートされ、この機能に関して安定しており、広く利用されています。
ただし、サポートしているからといって、デフォルトで有効になっているわけではありません。ダイナミックアップデートを受け入れるように BIND の設定ファイル (named.conf) で明示的に設定する必要があります。
zone "your.domain.com" IN {
type master;
file "your.domain.com.zone";
allow-update { key "your-tsig-key"; }; // ここでダイナミックアップデートを許可
};
// TSIGキーの定義 (named.conf のオプションセクションなどで)
key "your-tsig-key" {
algorithm hmac-sha256; // 使用するアルゴリズム
secret "YOUR_BASE64_ENCODED_TSIG_SECRET"; // dnssec-keygen で生成した秘密鍵
};
重要なポイント:
allow-update ディレクティブ: これがダイナミックアップデートを許可するために必須です。{ any; } とすると誰でもアップデートできてしまうため、セキュリティ上非常に危険です。通常は、特定のIPアドレスや、上記のようにTSIGキーを指定して認証されたクライアントのみに限定します。
TSIGキー: dnssec-keygen ツールを使ってキーを生成し、そのキーを named.conf に定義する必要があります。certbot-dns-rfc2136 プラグインも、このTSIGキーを使って認証を行います。
ゾーンファイルのパーミッション: BINDがゾーンファイルを書き換えられるように、ゾーンファイルの所有者とパーミッションを適切に設定する必要があります。通常、named ユーザーがゾーンファイルを書き込めるようにします。
まとめ 上記の設定を行うことで certbot-dns-rfc2136 プラグインを利用してTXTレコードをダイナミックアップデート経由で更新することが可能です。
Certbot の manual プラグインは、証明書発行プロセス中に特定のフック(スクリプト)を実行する機能を提供します。
CERTBOT_DOMAIN: 証明書を発行するドメイン名
CERTBOT_VALIDATION: TXT レコードの値(ACMEチャレンジトークン)
スクリプトの実装例(nsupdate を使用する場合):
auth_hook.sh:
Bash
#!/bin/bash
# BINDサーバのIPアドレスとTSIGキーの情報
BIND_SERVER="your.bind.server.ip"
TSIG_KEY_NAME="your-tsig-key"
TSIG_KEY_FILE="/path/to/your/tsig-key.key" # TSIGキーファイルへのパス
# nsupdate コマンドでTXTレコードを追加
echo "server $BIND_SERVER"
echo "update add _acme-challenge.$CERTBOT_DOMAIN 60 IN TXT \"$CERTBOT_VALIDATION\""
echo "send"
echo "quit"
# ここでパイプを使ってnsupdateにコマンドを渡す
# もしTSIGキーを使う場合は "-k" オプションでキーファイルを指定
/usr/bin/nsupdate -k "$TSIG_KEY_FILE" << EOF
server $BIND_SERVER
update add _acme-challenge.$CERTBOT_DOMAIN 60 IN TXT "$CERTBOT_VALIDATION"
send
quit
EOF
sleep 10 # DNSの伝播を待つために少し待機
cleanup_hook.sh:
Bash
#!/bin/bash
# BINDサーバのIPアドレスとTSIGキーの情報
BIND_SERVER="your.bind.server.ip"
TSIG_KEY_NAME="your-tsig-key"
TSIG_KEY_FILE="/path/to/your/tsig-key.key" # TSIGキーファイルへのパス
# nsupdate コマンドでTXTレコードを削除
/usr/bin/nsupdate -k "$TSIG_KEY_FILE" << EOF
server $BIND_SERVER
update delete _acme-challenge.$CERTBOT_DOMAIN TXT
send
quit
EOF
Certbot コマンドの実行:
Bash
sudo certbot certonly --manual --preferred-challenges dns \
--manual-auth-hook /path/to/auth_hook.sh \
--manual-cleanup-hook /path/to/cleanup_hook.sh \
-d your.domain.com
注意点:
これらのスクリプトは、実行権限(chmod +x)が必要です。
nsupdate コマンドが利用できる環境が必要です。
TSIG_KEY_FILE は、セキュリティ上、適切なパーミッションを設定し、保護してください。
スクリプト内でエラーハンドリングを追加するなど、堅牢性を高める必要があります。
どちらの方法を選ぶか?
RFC 2136 をサポートする BIND サーバがあり、比較的シンプルな設定で済ませたい場合:
certbot-dns-rfc2136 が最も適しています。
より細かな制御が必要な場合、または rfc2136 プラグインがうまく動作しない場合:
カスタムスクリプト (--manual-auth-hook / --manual-cleanup-hook) を作成する方法が適しています。ただし、スクリプトの作成とデバッグに手間がかかります。
まとめ
Certbot が直接 BIND のゾーンファイルをAPI経由で更新するような統合された機能は持っていませんが、上記のいずれかの方法で実現することが可能
代替案1 商用 DNS プロバイダはAPI 経由で更新操作に対応させる
Cloudflare
Route 53 (AWS)
Google Cloud DNS
Azure DNS
DigitalOcean DNS
Dynu
GoDaddy
OVH
それぞれのプロバイダのマニュアルに従い設定してください
代替案2: certbot-dns-rfc2136 プラグインの利用 (ダイナミックアップデート)
もし BIND サーバが RFC 2136 (DNS ダイナミックアップデート) をサポートしている場合、certbot-dns-rfc2136 プラグインを利用できる可能性があります。これは、DNS のレコードを動的に更新するための標準的なプロトコルです。
要件: BIND サーバがダイナミックアップデートを受け入れるように設定されていること。 キーファイル(TSIGキー)を生成し、Certbot がそのキーを使って認証できるようにすること。
BIND 9系であれば RFC 2136 (DNS ダイナミックアップデート) をサポートしています。
RFC 2136 で定義されているダイナミックアップデート機能は、BIND のバージョン9系ではかなり古いバージョンからサポートされ、この機能に関して安定しており、広く利用されています。
ただし、サポートしているからといって、デフォルトで有効になっているわけではありません。ダイナミックアップデートを受け入れるように BIND の設定ファイル (named.conf) で明示的に設定する必要があります。
named.conf の設定例
// named.conf またはゾーンファイル内でzone "your.domain.com" IN {
type master;
file "your.domain.com.zone";
allow-update { key "your-tsig-key"; }; // ここでダイナミックアップデートを許可
};
// TSIGキーの定義 (named.conf のオプションセクションなどで)
key "your-tsig-key" {
algorithm hmac-sha256; // 使用するアルゴリズム
secret "YOUR_BASE64_ENCODED_TSIG_SECRET"; // dnssec-keygen で生成した秘密鍵
};
重要なポイント:
allow-update ディレクティブ: これがダイナミックアップデートを許可するために必須です。{ any; } とすると誰でもアップデートできてしまうため、セキュリティ上非常に危険です。通常は、特定のIPアドレスや、上記のようにTSIGキーを指定して認証されたクライアントのみに限定します。
TSIGキー: dnssec-keygen ツールを使ってキーを生成し、そのキーを named.conf に定義する必要があります。certbot-dns-rfc2136 プラグインも、このTSIGキーを使って認証を行います。
ゾーンファイルのパーミッション: BINDがゾーンファイルを書き換えられるように、ゾーンファイルの所有者とパーミッションを適切に設定する必要があります。通常、named ユーザーがゾーンファイルを書き込めるようにします。
まとめ 上記の設定を行うことで certbot-dns-rfc2136 プラグインを利用してTXTレコードをダイナミックアップデート経由で更新することが可能です。
代替案3:カスタムスクリプトと--manual-auth-hook / --manual-cleanup-hook の利用
これは最も柔軟な方法ですが、ご自身でスクリプトを作成する必要があります。Certbot の manual プラグインは、証明書発行プロセス中に特定のフック(スクリプト)を実行する機能を提供します。
--manual-auth-hook スクリプト:
Certbot が TXT レコードを追加する際に実行されます。このスクリプト内で、BIND サーバのゾーンファイルを操作したり、nsupdate コマンドを使ってダイナミックアップデートを実行したりするロジックを実装します。CERTBOT_DOMAIN: 証明書を発行するドメイン名
CERTBOT_VALIDATION: TXT レコードの値(ACMEチャレンジトークン)
--manual-cleanup-hook スクリプト:
Certbot が TXT レコードの検証が完了した後、そのレコードを削除する際に実行されます。スクリプトの実装例(nsupdate を使用する場合):
auth_hook.sh:
Bash
#!/bin/bash
# BINDサーバのIPアドレスとTSIGキーの情報
BIND_SERVER="your.bind.server.ip"
TSIG_KEY_NAME="your-tsig-key"
TSIG_KEY_FILE="/path/to/your/tsig-key.key" # TSIGキーファイルへのパス
# nsupdate コマンドでTXTレコードを追加
echo "server $BIND_SERVER"
echo "update add _acme-challenge.$CERTBOT_DOMAIN 60 IN TXT \"$CERTBOT_VALIDATION\""
echo "send"
echo "quit"
# ここでパイプを使ってnsupdateにコマンドを渡す
# もしTSIGキーを使う場合は "-k" オプションでキーファイルを指定
/usr/bin/nsupdate -k "$TSIG_KEY_FILE" << EOF
server $BIND_SERVER
update add _acme-challenge.$CERTBOT_DOMAIN 60 IN TXT "$CERTBOT_VALIDATION"
send
quit
EOF
sleep 10 # DNSの伝播を待つために少し待機
cleanup_hook.sh:
Bash
#!/bin/bash
# BINDサーバのIPアドレスとTSIGキーの情報
BIND_SERVER="your.bind.server.ip"
TSIG_KEY_NAME="your-tsig-key"
TSIG_KEY_FILE="/path/to/your/tsig-key.key" # TSIGキーファイルへのパス
# nsupdate コマンドでTXTレコードを削除
/usr/bin/nsupdate -k "$TSIG_KEY_FILE" << EOF
server $BIND_SERVER
update delete _acme-challenge.$CERTBOT_DOMAIN TXT
send
quit
EOF
Certbot コマンドの実行:
Bash
sudo certbot certonly --manual --preferred-challenges dns \
--manual-auth-hook /path/to/auth_hook.sh \
--manual-cleanup-hook /path/to/cleanup_hook.sh \
-d your.domain.com
マニュアル
- CSRの生成方法
- 証明書のインストール
- ドメイン認証用サイトシールの設置
- ドメイン認証用セキュアサイトシール
(2012/11/1以降のご注文より) - 企業認証＆ＥＶ用サイトシールの設置
- コード証明書関連（codesign）
- セキュアEMAIL関連（smime）
- CaaS 自動化関連（ACME）
- IISサーバのみに起因する問題と解消のコツ
- 企業認証/EV認証の電話認証(コールバック)
- Windowsサーバーにおいて不完全な証明書チェーンとなる場合の解消法
- セクティゴの中間証明書及びルート証明書について
- ルート証明書 中間証明書について
- セクティゴサイトシール(trustlogo)のインスト―ル
- 中間CA証明書・ルート証明書について
- ドメインの所有者確認【メール方式:英文の承認メールの表示例】
各種手続きについて
- Multi-Perspective Issuance Corroboration(マルチ視点発行検証)を導入
- 「サーバ証明書」の拡張キーの使用法(EKU)フィールドに「クライアント認証」を記載することを廃止
- 古いSHA1ルート終了における対応につきまして。
- 新ドメイン認証レベルで確認させていただく内容
- オンラインDBへの電話番号確認
- DUNSの新規登録申請はオンラインで簡単
- ドメイン認証レベルで確認させていただく内容
- 企業認証レベルで確認させていただく内容
- 認証レベルに応じた確認・必要書類はなんですか
- 申請ドメインの登録状態を確認しよう :whoisチェック
- 企業情報(登録確認)にはどのような媒体がありますか?
- 無償版SSLとは
- 申請までにご準備いただく物
- お申込みから納品までの流れ
- 費用の支払方法
- お見積書発行依頼
- 請求書の発行依頼
- 更新の申請方法
- 販売パートナ・アフェリエイトパートナーになる。
- ID/パスワードを忘れたら
購入前のご質問
- Sectigo ルート証明書の移行と古いCAの無効化について
- vPRO対応AMT証明書について
- セクティゴの補償とは一体どのようなものでしょうか?
- FileMaker(ファイルメーカー)製品対応SSLについて
- 携帯電話、スマートフォン、タブレット対応状況
- 新旧ドメイン認証タイプの比較
- 携帯電話・スマートフォン対応状況(ユニファイドコミュニケーション)
- ドメイン管理状況の認証 (DCV) を実施
- ブラウザーの互換性
- マルチドメインは何個まで追加できますか
- 追加ドメインの購入はどのように申請するのでしょうか?
- IEの設定の「信頼されたルート証明期間」のなかでどのように表示されますか？
- コードサイニング証明書とはなんですか？
- ユニファイドコミュニケーションとはなんですか？
- どのようにすればSSLをテストできるでしょうか？
- コモドのSSL証明書は顧客のブラウザーで正しく動作するでしょうか？
- 補償とは一体どういう意味でしょうか?
- コモドのSSLはどのバージョンのSSLプロトコルと互換性がありますか？
- SGCとは何でしょうか？
- お申込フォームで間違った申請をしてしまいました。
- 個人でもコードサイニングが購入できますか??
- コモドのSSLはどのバージョンのSSLプロトコルと互換性がありますか？