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

• Lets' EncryptによるＳＳＬ証明書の自動取得・自動更新に関するメモを残す。

• Let's Encrypt について復習ではあるが、

  • 認証局のブランドの一つである。これは「Symantec(旧Verisign)セキュア・サーバーＩＤ」「CyberTrust SureServer」「SecomTrust セコムパスポート for Web3.0」「GlobalSign クイック認証SSL」「GeoTrust RapidSSL」「Comodo PositiveSSL」などの一つと考えれば良い。たぶんどれかは聞いたことあるはずと思う。

  • 他の認証局と明確に違う点は、
    • 無償。当然ではあるが、１証明書をどのように（複数ＩＰ, 複数バックエンド, 複数プロトコル）使用しても１取得で済む。
    • 親ドメインをまたぐ、マルチドメイン証明書（Subject Alternative Names）に対応している。
    • その代わり、ワイルドーカード証明書には対応していない。
    • ＲＳＡ(2048bit, 3072bit, 4096bit), ＥＣＤＳＡ(prime256v1, secp384r1) の５種類の鍵が選べる。
    • ＡＣＭＥ（Automated Certificate Management Environment）プロトコルによる証明書の認証から発行までの一連のバッチ化（自動化）が可能。
    • 扱える端末が（比較的）少ない。エンドユーザーの粘り強い、全アクセスの０．５％以下であってもフォローしないといけない用途であるなら使えない。
    • 逆に今時のメジャーどころの端末・ブラウザは対応している。
    • ＤＶ（Domain Validation）証明書のみ。ただしＯＶ（Organization Validation）証明書やＥＶ（Extended Validation）証明書との純技術的な優劣は無い。

    • 取得数制限（特に単位時間あたりの）があるので注意。詳しくは Rate Limits を参照のこと。

    • 検証（ステージング）用認証局も用意されているので、セットアップ時の検証や、ＡＣＭＥクライアントの開発といった用途ではこちらを使う。

    • 「現在の」ルート証明書は「IdentTrust|DST(Digital Signature Trust) Root CA X3」である。

    • 少なくとも中間証明書の発行者（Issuer）はそうである（ISRG - Internet Security Research Group ではない）。

    • このルート証明書がインストールされた端末が対応端末となる。
    • 中間証明書は「Let's Encrypt Authority X3」である（場合によってはこっち「も」入ってることがあるかもしれない）。

• 使用するツール・傾向については Let's EncryptでＳＳＬ証明書の新規取得と自動更新（http-01編） を参照のこと。

• ここでは「チャレンジ・レスポンス」をＨＴＴＰ（http-01）ではなく、ＤＮＳ（dns-01）を使う方法について説明する。
• 環境（イントラネット内など）によってはこの方法しか採れないケースもありうる。
• ＤＮＳコンテンツサーバーとの連携（諸設定）が必要になってしまうが、この味を知ってしまうと http-01 手順には戻れなくなること請け合いである:-)。

検証環境

いずれも最新のリリースということで確認しているが、ある程度古い環境でも問題無いと思われ。

本例では、www.example.jp というコモンネームに対して証明書を発行するものとする。 チャレンジ／レスポンスコードをＤＮＳダイナミックアップデートするため、 example.jp ゾーンに対するＤＮＳコンテンツサーバーへの更新権限があるものとする。 少なくとも _acme-challenge.www.example.jp ゾーン（と分けて／委任してもらって）に対する更新権限は最低限必要である。

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

• ＯＳは FreeBSD 11.0-R。

• ＤＮＳサーバーは BIND 9.11.1（ports/dns/bind911）。

ＳＳＬサーバー側

• ＯＳは FreeBSD 11.0-R。

• ＤＮＳダイナミックアップデートクライアントは BIND 9.11.1（[[https://www.freshports.org/dns/bind-tools|ports/dns/bind-tools）

• ＡＣＭＥクライアントは dehydrated 0.4.0（ports/security/dehydrated）。

インストール

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

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

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

• よってディレクトリ作成作業は不要である。
• ここでは「example.jp」ゾーンから「_acme-challenge.www.example.jp」を委任する。
• また今回、自分自身（ＤＮＳコンテンツサーバー）への委任とし、特に外部のＤＮＳコンテンツサーバーへは向けない。
• この時ＤＮＳコンテンツサーバーは ns.example.jp とする。

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 の書式に準拠したテキストファイルである。
• このＴＳＩＧキーを「ダイナミックアップデートキーファイル名」で保存しておく（所有者は root:wheel、パーミッションは 0400 で）。
• また、ダイナミックアップデートキーファイル名で定義されているキー名に対して、更新許可設定を与える（update-policy および grant）。

example.jp ゾーンファイルの設定例

$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

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

_acme-challenge.www.example.jp ゾーンファイルの設定例

$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

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

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

key "キー名" {
    algorithm hmac-sha256;
    secret "PfzeGvXiOqtPOwQJY/iNFrvlD3/eKAHRZ0TbyK5GYII=";
};

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

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

• もちろん secret の部分は毎回ランダムに発行される。
• このファイルは named.conf でも、（後で説明する）nsupdate コマンド（-k オプションで）でもそのまま解釈してくれる。
• 本ファイルの設置場所、命名規則については一概に言えることが無く、「ポリシーで」で逃げるには無責任すぎるので、例を出してみる。
• ＢＩＮＤ側に設置する場合は、/usr/local/etc/namedb/ ディレクトリに設置することとする。
• ｄｅｈｙｄｒａｔｅｄ側に設置する場合は、/usr/local/etc/dehydrated/ ディレクトリに設置することとする。
• ファイル名についてだが、「キー名.key」とするのが違和感なくていいと思う。

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

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

参考文献

• BIND 9 Administrator Reference Manual