Let's EncryptでＳＳＬ証明書の新規作成と自動更新（dns-01編）

Let's Encrypt とは

dns-01 とは

• サイト利用者を証明するための「チャレンジ・レスポンス」のやりとりをＨＴＴＰ経由（http-01）ではなく、ＤＮＳ経由（dns-01）で行う方法である。
• 以下のような環境では、この方法しか採れないケースもある。
  • イントラネット内のサーバーである。
  • アプライアンス機器等で、ＨＴＴＰのランディングが不可能である。
  • 特定プロトコル（メールサーバー等）ユースでＨＴＴＰでのランディングができない場合など。
• ＤＮＳコンテンツサーバーとの連携（諸設定）が必要になってしまうが、この味を知ってしまうと http-01 手順には戻れなくなること請け合いである:-)。
• どれくらい戻れないかというと、Ｗｅｂサーバーに対しても dns-01 手順を適用したくなってしまうくらい中毒性がある:-)。

目次

検証環境

• 以下のソフトウェアの利用を前提に検証を実施した。いずれも最新のリリースということで確認しているが、ある程度古い環境でも問題無いと思われる。
  • ＯＳ： FreeBSD 11.1-R
  • ＡＣＭＥクライアント： dehydrated 0.4.0
  • ＤＮＳダイナミックアップデートクライアント： BIND 9.11.2（nsupdate コマンド）
  • ＤＮＳコンテンツサーバー： BIND 9.11.2
  • ＳＳＬ証明書利用サーバーについてはここでは言及しない。
• 上記以外の環境では、以下の点に相違が発生する。必要に応じて読み替えたし。
  • インストール方法
  • インストールされるディレクトリ
  • 自動更新のための手続きとその設定
• 逆に以下の点は参考にできる。
  • 設定パラメータとその意味
  • 運用事例

検証作業内容

• 本例では、www.example.jp というサイトに対して証明書を発行するものとする。
• チャレンジ・レスポンスコードをＤＮＳダイナミックアップデートするため、example.jp ゾーンに対するＤＮＳコンテンツサーバーへの更新権限があるものとする。
• ＢＩＮＤの場合、update-policy 機能（allow-update 機能とは排他）によりある程度制限することができる。
• とは言え、ＤＮＳダイナミックアップデートは「ゾーン」に対してフリーダムに更新できてしまうのも確かである。
• そこで今回、_acme-challenge.www.example.jp ゾーン（に分けて／委任してもらって）に、更新が閉じるよう制限してみた。
• そこまで要らないというケースでは、_acme-challenge.www.example.jp ゾーンに対する各種設定を example.jp ゾーンに適用すればよい。ただし詳細は取り扱わない。
• ここでは敢えて「example.jp」ゾーンから「_acme-challenge.www.example.jp」を自分自身（ＤＮＳコンテンツサーバー）へ委任するものとし、外部のＤＮＳコンテンツサーバーへは向けないものとする。
• ここまでお膳立てが整えられていれば、例えば、サービスゾーンのＤＮＳコンテンツサーバーへの更新権限は得られなくても、自分のＤＮＳコンテンツサーバーに委任してもらって、更新できるようにするのは難しくないと思う。

想定サーバー・ドメイン

• ＤＮＳコンテンツサーバーは ns.example.jp とする。
  • 実際には複数のＤＮＳコンテンツサーバーで運用されていると思う。
  • それらサーバーへの反映は ns.example.jp の notify yes; およびＩＸＦＲ（Incremental Zone Transfer）により、全てのサーバーへ即時に遅滞なく通達されるものとする。
  • それら運用上の詳細については既に設定されているものとして、ここでは取り扱わない。
• ＳＳＬサーバーは www.example.jp とする。
• 上記サーバー（ＤＮＳコンテンツサーバー・ＳＳＬサーバー）は同一でもかまわないし、別々でもかまわない。

ＤＮＳコンテンツサーバー側

• ＤＮＳサーバーは ports/dns/bind911 をインストールする。

ＳＳＬサーバー側

• ＤＮＳダイナミックアップデートクライアントは ports/dns/bind-tools をインストールする。

• 既にＢＩＮＤ（ports/dns/bind911）がインストールされている環境では不要。

• 古いＦｒｅｅＢＳＤ（９．ｘ等）の nsupdate コマンドはＴＳＩＧは取り扱えないため、やはりインストールする必要がある。

• ＡＣＭＥクライアントは ports/security/dehydrated をインストールしておく。

インストール

• いずれも ports/security/dehydrated、ports/dns/bind911 または ports/dns/bind-utils よりインストールする。
• オプションの選択によって手順が変わる点は無いため、ここでは明示しない。

ＤＮＳコンテンツサーバー側の設定

• Let's EncryptでＳＳＬ証明書の新規取得と自動更新（http-01編）で実施した「ドメイン所有者確認トークンディレクトリの指定」の代わりの作業となる。

• よってディレクトリ作成作業は不要である。

named.conf の設定（一部）例（/usr/local/etc/namedb/named.conf）

include "/ダイナミック/アップデート/キー/フルパス名";

zone "example.jp" {
    type master;
    file "/example.jp/ゾーン/フルパス名";
};

zone "_acme-challenge.www.example.jp" {
    type master;
    file "/_acme-challenge.www.example.jp/ゾーン/フルパス名";
    update-policy {
        grant ダイナミックアップデートキー名 name _acme-challenge.www.example.jp. TXT;
    };
};

• 「ＤＮＳコンテンツサーバー」と「ＳＳＬサーバー」とで、ＴＳＩＧ（Transaction SIGnature）キーを共有する。
• ＴＳＩＧキーはキー名と秘密鍵で構成された、named.conf の書式に準拠したテキストファイルである。
• このＴＳＩＧキーを「ダイナミックアップデートキーファイル名」で保存しておく（所有者は bind:wheel、パーミッションは 0400 で）。
• また、ダイナミックアップデートキーファイル名で定義されているキー名に対して、更新許可設定を与える（update-policy および grant）。
• また変更できるレコード名およびリソースレコードを限定する（name _acme-challenge.www.example.jp. TXT）。
• 残念なことに update-policy ではアクセス元制限ができないので、キーの取り扱いについては注意すること。
• なお allow-update は update-policy とは排他であるため、両方設定することはできない。

example.jp ゾーンファイルの設定例（/usr/local/etc/namedb/master/example.jp.db）

$TTL               300

@                       IN SOA ns.example.jp. domain.example.jp. (
                               2017032201 ; serial
                               7200       ; refresh (2 hours)
                               900        ; retry (15 minutes)
                               2419200    ; expire (4 weeks)
                               86400      ; minimum (1 day)
                               )
                        IN NS ns
_acme-challenge.www     IN NS ns

• 本ファイルの設置場所、命名規則はそれぞれのポリシーに従う（本例では ゾーン名.db とした）。
• 少なくともＦｒｅｅＢＳＤ的には、/usr/local/etc/namedb/master/ ディレクトリ以下に設置されるものとしている。
• さらに「example.jp.db」とするか「jp.example.db」とするかなどは、好きにすれば良い。

_acme-challenge.www.example.jp ゾーンファイルの設定例（/usr/local/etc/namedb/dynamic/_acme-challenge.www.example.jp.db）

$TTL               300

@                       IN SOA ns.example.jp. domain.example.jp. (
                               2017032201 ; serial
                               7200       ; refresh (2 hours)
                               900        ; retry (15 minutes)
                               2419200    ; expire (4 weeks)
                               86400      ; minimum (1 day)
                               )
                        IN NS ns.example.jp.

• 本ファイルの設置場所、命名規則はそれぞれのポリシーに従う（本例では ゾーン名.db とした）。
• 少なくともＦｒｅｅＢＳＤ的には、/usr/local/etc/namedb/dynamic/ ディレクトリ以下に設置されるものとしている。
• さらに「_acme-challenge.www.example.jp.db」とするか「jp.example.www._acme-challenge.db」とするかなどは、好きにすれば良い。

ダイナミックアップデートキーファイルの設定例

key "キー名" {
    algorithm hmac-sha256;
    secret "シークレットキー（ＢＡＳＥ６４表現）";
};

上記ファイルは以下のコマンドにより生成することができる。

tsig-keygen -a hmac-sha256 キー名 > /ダイナミック/アップデート/キーファイル名
chown bind:wheel /ダイナミック/アップデート/キーファイル名
chmod 0400       /ダイナミック/アップデート/キーファイル名

• もちろん secret の部分は毎回ランダムに発行される。
• このファイルは named.conf でも、（後で説明する）nsupdate コマンド（-k オプションで）でもそのまま解釈してくれる。
• 本ファイルの設置場所、命名規則については一概に言えることが無く、「ポリシーで」で逃げるには無責任すぎるので、例を出してみる。

本例における具体的設定例

• ＢＩＮＤ側に設置する場合は、/usr/local/etc/namedb/ ディレクトリに設置することとする。
• ｄｅｈｙｄｒａｔｅｄ側に設置する場合は、/usr/local/etc/dehydrated/ ディレクトリに設置することとする。
• ファイル名についてだが、「キー名.key」とするのが違和感なくていいと思う。

• 肝心のキー名だが、ＢＩＮＤ９．１１のマニュアル（ＴＳＩＧ）によれば「ホスト名１-ホスト名２.」という例がある。

• 本気かどうかわからないが、「ＤＮＳコンテンツサーバー-ダイナミックアップデートするサーバー.」というニュアンスらしい。
• 本件の場合、ns.example.jp と www.example.jp であることから「ns-www.」とするのが妥当か（ほんと？）。
• まぁなんでもいいけど、わかりやすいようにね。

key "ns-www." {
    algorithm hmac-sha256;
    secret "PfzeGvXiOqtPOwQJY/iNFrvlD3/eKAHRZ0TbyK5GYII=";
};

• /usr/local/etc/namedb/ns-www.key（owner:group=bind:wheel, mode=0400）
• /usr/local/etc/dehydrated/ns-www.key（owner:group=root:wheel, mode=0400）

ＳＳＬサーバー側の設定

• ほとんどLet's EncryptでＳＳＬ証明書の新規取得と自動更新（http-01編）で実施した作業と同じになる。

• 明確に違う点は、先のページでは解説してない「HOOK」設定となる。
• ここでは一通り作業の意味がわかってる前提で、一通り設定を紹介する。

/etc/periodic.conf

weekly_dehydrated_enable="YES"

自動更新設定（YES＝自動更新する）。 periodic(8)にある通り、毎週土曜日３時に実行される。

なお今回、weekly_dehydrated_deployscript は指定しない（後述の HOOK 設定参照のこと）。

/usr/local/etc/dehydrated/ns-www.key

これは先に tsig-keygen コマンドで作成されたファイルである。 ＤＮＳコンテンツサーバーと同一になるようコピーするなどして設定すること。 その際のオーナー・グループ・パーミッションは以下の通りである。

chown root:wheel /usr/local/etc/dehydrated/ns-www.key
chmod 0400       /usr/local/etc/dehydrated/ns-www.key

/usr/local/etc/dehydrated/config

alias openssl="/usr/bin/openssl"

CHALLENGETYPE="dns-01"
HOOK="${BASEDIR}/hook.sh"
RENEW_DAYS="30"
KEY_ALGO="rsa" KEYSIZE="2048"
#KEY_ALGO="prime256v1"
CONTACT_EMAIL="メールアドレス"
#テスト発行したい場合、以下の２行を有効にすること。
#CA="https://acme-staging.api.letsencrypt.org/directory"
#CA_TERMS="https://acme-staging.api.letsencrypt.org/terms"

• http-01 との時との大きな違いは CHALLENGETYPE と HOOK 設定にある。
• HOOK 設定（によって指定されるファイル）については後述する。
• CHALLENGETYPE には dns-01 を指定する。
• CHALLENGETYPE は現在 http-01 か dns-01 の２つしか選択肢は無い。

/usr/local/etc/dehydrated/domains.txt

www.example.jp

本ファイルの設定については コモンネームの設定に準拠するものとする（例）。

/usr/local/etc/dehydrated/hook.sh

TTL="300"
DNSSERVER="ns.example.jp"
alias nsupdate="/usr/local/bin/nsupdate -k ${BASEDIR}/ns-www.key"

function deploy_challenge {
    local DOMAIN="${1}" TOKEN_FILENAME="${2}" TOKEN_VALUE="${3}"
    printf 'server %s\nupdate add _acme-challenge.%s. %d TXT "%s"\nsend\n' "${DNSSERVER}" "${DOMAIN}" "${TTL}" "${TOKEN_VALUE}" | nsupdate
}

function clean_challenge {
    local DOMAIN="${1}" TOKEN_FILENAME="${2}" TOKEN_VALUE="${3}"
    printf 'server %s\nupdate delete _acme-challenge.%s. TXT\nsend\n' "${DNSSERVER}" "${DOMAIN}" | nsupdate
}

function deploy_cert {
    /usr/sbin/service apache24 restart && /usr/local/bin/dehydrated -gc
}

function unchanged_cert {
    # NOTHING TO DO #
}

function invalid_challenge() {
    # NOTHING TO DO #
}

function request_failure() {
    # NOTHING TO DO #
}

function exit_hook() {
    # NOTHING TO DO #
}

HANDLER=$1; shift; $HANDLER $@

HOOK ファイルのひな形として、/usr/local/etc/dehydrated/hook.sh.example を参照すること。

/usr/local/etc/dehydrated/deploy.sh

• 本ケースでは deploy.sh を取り扱わない（無くてもいい）。
• これは HOOK で指定するシェルスクリプトの deploy_cert シェル関数で代替できるからである。
• HOOK（/usr/local/etc/dehydrated/config）と weekly_dehydrated_deployscript（/etc/periodic.conf）の違いは以下の通りである。
  • 証明書取得する単位毎に実行されるのが HOOK、全て取得終って実行されるのが weekly_dehydrated_deployscript。
  • 証明書取得に成功した・失敗した（または更新なし）がわかるのが HOOK、わからないのが weekly_dehydrated_deployscript。
• よって、１枚の証明書を相手にする時はそう違いは無いが、複数枚を取得して分散デプロイしたいなら HOOK しかない。
• ファインチューニング（更新ない時は何もしないなど）したいなら HOOK 一択。
• 逆に HOOK はデプロイだけしたいユースケースにおいて若干ながら大味（ダミーの関数を置く必要がある）である。
• この HOOK はバージョンによって拡張されることがあるので、場合によっては（エラーで止まるなど）追随しなければならないこともありうる。

参考文献

• BIND 9 Administrator Reference Manual