目次
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）に対応している（全ての認証局で対応してるね）。
- その代わり、ワイルドカード証明書には対応していない（対応してるブランドと対応してないブランドとあるね）。
- ＤＶ（Domain Validation）証明書のみ提供（対応してるブランドと対応してないブランドとあるね）。
- ただしＯＶ（Organization Validation）証明書やＥＶ（Extended Validation）証明書との純技術的な優劣は無い。
- 他の認証局と明確に違う点は、
- 無償。
- ＲＳＡ(2048bit, 3072bit, 4096bit), ＥＣＤＳＡ(prime256v1, secp384r1) の５種類の鍵が選べる（ここまで選べる認証局は限られるね）。
- ＡＣＭＥ（Automated Certificate Management Environment）プロトコルによる証明書の認証から発行までの一連のバッチ化（自動化）が可能。
- 今時誤差かもしれないが、扱える端末が（他の認証局と比べて）少ない。
- エンドユーザーが粘り強く使用している、全アクセスの０．５％以下の端末であってもフォローしないといけない用途であるならお勧めしない。
- 逆に今時のメジャーどころの端末・ブラウザは対応している。
- よってＰＣ相手にはほぼ問題無い（Windows XP? IE6? 知らんがな）。
取得数制限（特に単位時間あたりの）があるので注意。詳しくは Rate Limits を参照のこと。
検証（ステージング）用認証局も用意されているので、セットアップ時の検証や、ＡＣＭＥクライアントの開発といった用途ではこちらを使う。
「現在の」ルート証明書は「IdentTrust|DST(Digital Signature Trust) Root CA X3」である。
IdentTrust なの？ DST なの？ については旧会社のブランドも残ってるらしい、としか認識してない。
少なくとも中間証明書の発行者（Issuer）はそうである（ISRG - Internet Security Research Group ではない）。
- このルート証明書がインストールされた端末が対応端末となる。
- 中間証明書は「Let's Encrypt Authority X3」である（場合によってはこっち「も」入ってることがあるかもしれない）。
使用するツール・傾向については Let's EncryptでＳＳＬ証明書の新規取得と自動更新（http-01編） を参照のこと。
- ここでは「チャレンジ・レスポンス」をＨＴＴＰ（http-01）ではなく、ＤＮＳ（dns-01）を使う方法について説明する。
- 環境（イントラネット内など）によってはこの方法しか採れないケースもありうる。
- ＤＮＳコンテンツサーバーとの連携（諸設定）が必要になってしまうが、この味を知ってしまうと http-01 手順には戻れなくなること請け合いである:-)。
- どれくらい戻れないかというと、Ｗｅｂサーバーに対しても dns-01 手順を適用したくなる。
検証環境
- いずれも最新のリリースということで確認しているが、ある程度古い環境でも問題無いと思われ。
- 本例では、www.example.jp というコモンネームに対して証明書を発行するものとする。
- チャレンジ／レスポンスコードをＤＮＳダイナミックアップデートするため、example.jp ゾーンに対するＤＮＳコンテンツサーバーへの更新権限があるものとする。
- ある程度制限できるとは言え、ＤＮＳダイナミックアップデートは「ゾーン」に対してフリーダムに更新できてしまうので、_acme-challenge.www.example.jp ゾーン（に分けて／委任してもらって）に、更新が閉じるよう制限するのが必要と思われる。
- ここでは敢えて「example.jp」ゾーンから「_acme-challenge.www.example.jp」を自分自身（ＤＮＳコンテンツサーバー）へ委任するものとし、外部のＤＮＳコンテンツサーバーへは向けないものとする。
- ここまでお膳立てが整えられていれば、例えば、サービスゾーンのＤＮＳコンテンツサーバーへの更新権限は得られなくても、自分のＤＮＳコンテンツサーバーに委任してもらって、更新できるようにするのは難しくないと思う。
想定サーバー・ドメイン
- ＤＮＳコンテンツサーバーは ns.example.jp とする。
- 実際には複数のＤＮＳコンテンツサーバーで運用されていると思う。
- それらサーバーへの反映は ns.example.jp の notify yes; およびＩＸＦＲ（Incremental Zone Transfer）により、全てのサーバーへ即時通達されるものとする。
- それら詳細についてはここでは取り上げない。
- ＳＳＬサーバーは www.example.jp とする。
- 上記サーバーは同一でもかまわないし、別々でもかまわない。
- ＯＳは FreeBSD 11.0-R での想定で行っているが、設定ファイルの位置以外は他のＯＳでも有効である。
- インストールされるパッケージ如何によっては細かい振る舞いが変わるが、詳細は取り扱わない。
- あくまでも FreeBSD 11.0-R 環境における検証結果とする。
ＤＮＳコンテンツサーバー側
ＤＮＳサーバーは BIND 9.11.1（ports/dns/bind911）。
ＳＳＬサーバー側
ＤＮＳダイナミックアップデートクライアントは BIND 9.11.1（ports/dns/bind-tools）。
既に BIND 9.11.1 （ports/dns/bind911）がインストールされている環境では不要。
- FreeBSD 9.x 等といった古い環境では nsupdate コマンドが存在したため、そのような環境でもインストールは不要である。
ＡＣＭＥクライアントは dehydrated 0.4.0（ports/security/dehydrated）。
インストール
- いずれも ports/security/dehydrated、ports/dns/bind911 または ports/dns/bind-utils よりインストールする。
- オプションの選択によって手順が変わる点は無いため、ここでは明示しない。
ＤＮＳコンテンツサーバーの設定
Let's EncryptでＳＳＬ証明書の新規取得と自動更新（http-01編）で実施した「ドメイン所有者確認トークンディレクトリの指定」の代わりの作業となる。
- よってディレクトリ作成作業は不要である。
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）。
- また変更できるレコード名およびリソースレコードを限定する（name _acme-challenge.www.example.jp. TXT）。
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.」とするのが妥当か（ほんと？）。
- まぁなんでもいいけど、わかりやすいようにね。
key "ns-www." {
algorithm hmac-sha256;
secret "PfzeGvXiOqtPOwQJY/iNFrvlD3/eKAHRZ0TbyK5GYII=";
};- /usr/local/etc/namedb/ns-www.key
- /usr/local/etc/dehydrated/ns-www.key