TLS証明書の基本と自動更新の理解 ― BIND・TSIG・certbot

Posted at 2026-10-12

はじめに

HTTPSの設定では「証明書を取得する」ことに目が向きがちです。しかし、運用では「何を確かめて発行するのか」「更新した証明書が実際に使われているか」も大切です。

この記事では、解説動画で扱ったTLS証明書の基本と、BIND・TSIG・certbotを使ったDNS認証の流れを短く整理します。

記事の内容を、図解・アニメーション・ナレーションで順番に学べる解説動画を作成しました。
自己学習用で作成しておりましたが何かのお役に立つかと思い、公開します。

動画前半では「証明書は何のためにあるのか」「公開鍵と秘密鍵はどう違うのか」といった基本から説明します。後半では、BINDのTSIG鍵やupdate-policyの設定、certbotによる証明書の取得・更新、Nginxへの反映まで、コマンドや設定例を交えて解説しています。

初めて学ぶ方は最初から、設定の流れを確認したい方は実践編からご覧ください。
動画の説明欄には、見たい内容へ移動できる時間付きの目次を用意しています。

TLSは、通信内容を暗号化し、途中での書き換えを検出するためのしくみです。証明書は、その通信相手が目的のサイトであることを確認する役割を担います。

ブラウザーは、証明書の対象ドメイン名、有効期間、信頼できる認証局につながる署名などを確認します。接続時には、サーバーが対応する秘密鍵を持っていることも確かめます。

ここで、2つの鍵を分けて覚えましょう。

鍵	役割と扱い
公開鍵	証明書に含まれ、接続する相手に公開される
秘密鍵	サーバー側で保管し、TLSの認証に使う。外部に渡さない

なお、TLS 1.3では、証明書の公開鍵で通信データを直接暗号化するわけではありません。鍵共有で得た情報から、通信に使う鍵を作ります。

また、HTTPSはサイトの内容や運営者の行為まで安全だと保証するものではありません。

証明書を発行する認証局（CA）は、申請者がそのドメインを管理できるか確認します。

その方法の1つが DNS-01認証 です。例えば example.com の証明書を申請するときは、次の名前に確認用のTXTレコードを置きます。

_acme-challenge.example.com.

CAは、その場所に指定の検証値が公開されていることを確認して、証明書を発行します。TXTレコードは、DNSに文字情報を登録するためのレコードです。

Let's Encryptでは、*.example.com のようなワイルドカード証明書の取得にもDNS-01を使えます。DNS-01の公式解説

名前が多いので、役割を分けて整理します。

名前	役割
BIND	DNS情報を管理し、問い合わせに答えるソフトウェア
certbot	CAへの申請、証明書の取得・更新を行うツール
dns-rfc2136	certbotからDNSの動的更新を行うプラグイン
TSIG	共有秘密を使い、DNS更新の送り手とメッセージの正しさを確認するしくみ

全体の流れは、次のようになります。

certbotがCAへ証明書を申請
  ↓
dns-rfc2136がTSIG付きの更新をBINDへ送信
  ↓
BINDが確認用TXTを公開
  ↓
CAが公開DNSで検証値を確認
  ↓
証明書が発行され、certbotが保存
  ↓
Webサーバーへ設定し、配信を確認

dns-rfc2136は、確認用TXTの追加と、検証後の削除を自動化します。プラグイン公式資料

TSIGの共有秘密と、TLS証明書の秘密鍵は別のものです。また、TSIGはDNSの通信内容を暗号化するしくみではありません。BIND公式資料

TSIGで送り手を確認できても、DNS全体の変更を許す必要はありません。

BINDでは、update-policy を使って「どの鍵に、どの名前の、どの種類のレコードを変更させるか」を絞れます。

例えば、acme-key. という鍵に、_acme-challenge.example.com. のTXTだけを更新させるルールは次の形です。

update-policy {
    grant acme-key. name _acme-challenge.example.com. TXT;
};

これは既存ゾーン設定に組み込むルールの抜粋です。TSIG鍵の登録や、BIND側の設定が別途必要です。

TSIGで「誰か」を確認し、update-policyで「何をしてよいか」を決める、と考えると整理しやすくなります。設定例の公式資料

動画では、次の順番で設定と確認を進めています。

エラーが起きたときは、処理を順番に切り分けます。

確認する段階	主な確認点
TSIG認証	鍵名・共有秘密・アルゴリズム・時計のずれ
DNS更新の許可	update-policyの対象名とレコード種類
TXTの公開	公開側の権威DNSでも検証値が見えるか
CAの検証	TXTの値が正しいか、公開が間に合っているか
証明書の配信	Nginxの参照先と再読み込み、外部から見える証明書

特に大切なのは、DNS更新の成功、証明書の発行、Webサーバーへの反映を、それぞれ確認することです。

この流れを押さえると、設定項目を丸暗記するだけでなく、トラブルが起きた場所も探しやすくなります。