DNS CAAレコードに Let's Encrypt 認証局を設定する

クラウド
クラウド
スポンサーリンク

DNS CAA(Certification Authority Authorization)は、自分が所有しているドメインに対して、SSL/TLSサーバー証明書を発行できる認証局(CA)を指定できる仕組みです。ドメイン所有者が CAAレコードを登録することによって、認証局が証明書を誤発行してしまうリスクを減らすのがこの仕組みのねらいとされています。そこで今回は、CAA に対応している Let's Encrypt 認証局を DNS CAAレコードに設定してみました。

Let's Encrypt は自分が所有しているドメインのSSL/TLSサーバー証明書を、無料で発行してくれる認証局です。詳しくは「Let's Encrypt サーバー証明書の取得と自動更新設定メモ」の記事をご参照ください。

CAAレコードを設定できるDNSサーバー

自前でDNSサーバーを運用していれば、BINDやPowerDNSなどほとんどのDNSサーバーソフトが CAAレコードに対応していますので、CAAレコードを設定することができます。

CAAレコードの例

example.com. IN CAA 0 issue "letsencrypt.org"

古いバージョンのBIND(9.9.6以下)は CAAレコードに対応していませんが、CAA に割り当てられているリソースレコードタイプ「TYPE257」を使うことで CAAレコードを設定することができます。

上の CAAレコードを TYPE257 で設定

example.com. IN TYPE257 \# 22 000569737375656C657473656E63727970742E6F7267

しかし問題となるのは、DNSサービスを使っている場合です。2017年5月10日現在、お名前.com などレジストラのDNSサービスや AWS Route53 などクラウドDNSサービスのほとんどが CAAレコードに対応していませんしリソースレコードタイプ「TYPE257」を使うこともできません。

(2017年8月22日追記)AWS Route53 が CAAレコードに対応しました!
Amazon Route 53 now supports CAA records

今回設定する CAAレコード

CAAレコードを作成するには、SSLMate の「CAA Record Generator」が便利です。TYPE257 のレコードも生成してくれます。

今回 CAAレコードを設定するドメイン名は「www.g.apar.jp」です。このドメイン名に対して証明書を発行できる認証局を Let's Encrypt に限定する CAAレコードは次のようになります。

www.g.apar.jp. IN CAA 0 issue "letsencrypt.org"
www.g.apar.jp. IN CAA 0 issuewild ";"
www.g.apar.jp. IN CAA 0 iodef "mailto:sample@example.com"

issue
 証明書を発行できる認証局のドメイン名を指定します。

issuewild
 ワイルドカード証明書を発行できる認証局のドメイン名を指定します。上のように「issuewild ";"」としている場合は、どの認証局からもワイルドカード証明書を発行してくれるな!という意味になります。

iodef
 認証局からの連絡先を指定します。おかしな証明書要求があった場合などの報告先として使われることがあります。

 
また、証明書を発行できる認証局は、下のように複数指定することも可能です。

www.g.apar.jp. IN CAA 0 issue "letsencrypt.org"
www.g.apar.jp. IN CAA 0 issue "symantec.com"

Google Cloud DNS に CAAレコードを設定

CAAに対応している Google Cloud DNS にCAAレコードを設定してみました。

CAAレコードの設定

Google Cloud Platform コンソール左上の「≡」メニューから「ネットワーキング」>「Cloud DNS」を選択します。

CAAレコードを設定するゾーンを選択します。

「レコードセットを追加」をクリックします。

DNS名に、CAAレコードを設定するサブドメイン名を入力して、リソースレコードのタイプ「CAA」を選択します。

(補足)TTL(リソースレコードをキャッシュに保存できる期間)の値をどうすればよいのか迷いましたが、CAAの技術仕様には「CAAレコードの確認は権威DNSサーバー(authoritative name server)に行い、第三者にキャッシュされたデータは信頼するべきではない」のような内容が書かれていますので、あまり気にしなくてもいいのかもしれません。(なのでデフォルトの5分のままにしています)

For example, all portions of the DNS lookup process SHOULD be performed against the authoritative name server. Data cached by third parties MUST NOT be relied on but MAY be used to support additional anti-spoofing or anti-suppression controls.

https://tools.ietf.org/html/rfc6844 より引用

 
CAAレコードのフラグ「0」から先の部分を「認証局の承認」欄に入力し「作成」をクリックします。(「+項目を追加」をクリックして入力欄を増やすことができます)

以上で CAAレコードの設定完了です。

CAAレコードの確認

現時点では dig コマンドは CAAレコードに対応していませんが、リソースレコードタイプに「TYPE257」を指定することで CAAレコードを確認することができます。

$ dig www.g.apar.jp TYPE257
(略)
;; QUESTION SECTION:
;www.g.apar.jp. IN TYPE257
 
;; ANSWER SECTION:
www.g.apar.jp. 277 IN TYPE257 \# 22 000569737375656C657473656E63727970742E6F7267
www.g.apar.jp. 277 IN TYPE257 \# 12 0009697373756577696C643B
www.g.apar.jp. 277 IN TYPE257 \# 32 0005696F6465666D61696C746F3A73616D706C65406578616D706C65 2E636F6D

SSL Server Test で確認すると CAAレコードの内容をデコードして表示くれるので便利ですね(^^)

本当に Let's Encrypt は CAA に対応しているの?

試しにどの認証局からも証明書を発行できない下のような CAAレコードを設定して、Let's Encrypt に証明書の発行要求をしてみました。

nocerts.g.apar.jp. IN CAA 0 issue ";"

証明書の発行要求の実行と結果

# /usr/local/certbot/certbot-auto certonly --webroot -w /var/www/html -d nocerts.g.apar.jp -m sample@example.com --agree-tos -n
(略)
Failed authorization procedure. nocerts.g.apar.jp (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: CAA record for nocerts.g.apar.jp prevents issuance
 
IMPORTANT NOTES:
- The following errors were reported by the server:
 
Domain: nocerts.g.apar.jp
Type: connection
Detail: CAA record for nocerts.g.apar.jp prevents issuance
 

しっかり CAAレコードで証明書の発行を防止してくれています。うたぐってゴメンナサイ(^^;)

おわりに

現時点で DNS CAAレコードはほとんど普及していませんが、2017年3月にCA(認証局)/ブラウザフォーラムの採決で、認証局がSSL/TLSサーバー証明書を発行する際に CAAレコードを確認することが必須となりました。この流れで CAAレコードに対応したDNSサービスが増えてくれるといいですね。

コメント

タイトルとURLをコピーしました