してみるテストロゴ
Apache 2.4系でHTTP/2サーバを構築してみるテスト。

Certification Authority Authorization(DNS CAA)設定

SSL Labsのチェックの証明書の欄に「DNS CAA」の確認が表示されるようになりました。

CAAとは、Certification Authority Authorizationの略で、日本語訳だと、「認証局認可」といったところでしょうか。

DNSにCAAレコードとして登録する情報になります。

このDNSレコードの用途ですが、日本語に直訳で「認証局認可」とあるように、認証局が利用するものです。

ドメイン所有者は、CAAレコードを記載しておくことによって、証明書を発行する認証局あらかじめ指定します。

たとえば、ドメイン認証によって証明書を発行する認証局、とくに、申請後数分で証明書を発行することを売りにしている認証局の場合、審査の隙を突かれてしまう可能性もあります。

これを防ぐため、ドメイン所有者が利用する認証局を、明示しておくことで、意図しない認証局からの誤発行を防ぐことができます。

CAAについては、こちらの解説がわかりやすいと思います。

Certification Authority Authorizationの概要

サイトでも紹介しているLet's Encryptは、このCAA情報を積極的に見て、誤発行を防いでいます。

具体的な処理の流れとしては、以下の図のようになります。

ステップ2.1と、ステップ2.2がDNS CAAの処理になります。


[拡大]

このように、DNS CAAの情報をみて、認証局は証明書を発行すべきか、判断することができます。

つまり、Let's Encryptに証明書を発行してほしい場合は、そのように、DNS CAAを設定します。

 

https://sslmate.com/labs/caa/によれば、Let's Encrypt は CAAレコードが有れば、それに従います。

それ以外の、 Comodo 、DigiCert、Entrust、Izenpeあたりは、CAAレコードとは関係なく、書面などの審査によては、証明書を発行する可能性があります。

Symantec/GeoTrust/Thawte は、審査ポリシーが不明となっています。

SSL/TLSのサーバ証明書に関連したDNSを利用した仕組みとしたは、CAAの他に、「DNS-based Authentication of Named Entities(DANE)」があります。

こちらは、認証局では無く、一般の利用者向けの機能ですが、Chromeへの実装が進んでいないこともあり、ここでは、割愛します。

 

CAAの設定は、DNSサーバの設定に使われるゾーンファイルに記載することで行います。

そのため、DNSサーバとしては、BINDなどでも利用可能です。

CAAレコード自体は、最近定義されたレコードのため、ゾーンファイルが構文として対応しているソフトウエアは、比較的新しいものに限られます。

古いDNSサーバでも、レガシーゾーンファイルの記載方法 (RFC 3597 Syntax)を利用することで、CAAを利用することができます。

とはいえ、セキュリティーなどの観点からも、NSD 4.0.1以降の最新版を推奨します。

NSD 4.0.1以降の設定方法

ここで記載のゾーンファイルは、BIND 9.9.6以降, PowerDNS 4.0.0以降, Knot DNS 2.2.0以降で利用できます。

つまり、ゾーンファイルの構文として、CAAレコードを解釈できるソフトウエア向きの説明です。

 

証明書を発行するサブドメインの設定に、以下のようにCAAレコードを設定します。

# vi /etc/nsd/example.com
/etc/nsd/example.com
$ORIGIN example.com.
$TTL 1H
@           IN      SOA     ns1.example.com. postmaster.example.com. (
                        2017012601      ;serial
                        1H              ;refresh
                        1H              ;retry
                        1H              ;Expire
                        1H              ;Minimum
                        );

                        IN      NS      ns1.example.com.

ns1                     IN      A       xxx.xxx.xxx.1
                        IN      AAAA    240d:XXXX:XXXX:XXXX::2

www                     IN      A       xxx.xxx.xxx.1
                        IN      AAAA    240d:XXXX:XXXX:XXXX::2
						IN      CAA     0 issue "letsencrypt.org"
  

CAAの後に続く数字が、クリティカルフラグと呼ばれる数値になります。RFC 6844 では、これが128の場合、証明書を発行してないけないとなっています。

ちなみにLet'sEncryptでは、クリティカルフラグが、128だけではなく、1の場合も、証明書の発行を行いません。

[該当ソース部分]

ネットワークオーダのMSBを理解していない人がいることが原因のようです。

あとは、issueが発行者の指定、その後のドメイン名が、認証局の指定になります。

ワイルドカードで指定する場合は、以下のように、issueの代わりに、issuewildを使います。

# vi /etc/nsd/example.com
/etc/nsd/example.com
$ORIGIN example.com.
$TTL 1H
@           IN      SOA     ns1.example.com. postmaster.example.com. (
                        2017012601      ;serial
                        1H              ;refresh
                        1H              ;retry
                        1H              ;Expire
                        1H              ;Minimum
                        );

                        IN      NS      ns1.example.com.
						IN      CAA     0 issuewild "letsencrypt.org"

ns1                     IN      A       xxx.xxx.xxx.1
                        IN      AAAA    240d:XXXX:XXXX:XXXX::2

www                     IN      A       xxx.xxx.xxx.1
                        IN      AAAA    240d:XXXX:XXXX:XXXX::2
      

設定の反映方法と確認方法は、コチラになります。

レガシーDNSサーバ用の設定

宗教上の理由などで、どうしても新しい、DNSサーバのソフトウエアが使えない方もいらっしゃると思います。

その場合、レガシーゾーンファイルの記載方法 (RFC 3597 Syntax)を利用します。

証明書を発行するサブドメインの設定に、以下のようにTYPE257として、CAAレコードを設定します。

# vi /etc/nsd/example.com
/etc/nsd/example.com
$ORIGIN example.com.
$TTL 1H
@           IN      SOA     ns1.example.com. postmaster.example.com. (
                        2017012601      ;serial
                        1H              ;refresh
                        1H              ;retry
                        1H              ;Expire
                        1H              ;Minimum
                        );

                        IN      NS      ns1.example.com.

ns1                     IN      A       xxx.xxx.xxx.1
                        IN      AAAA    240d:XXXX:XXXX:XXXX::2

www                     IN      A       xxx.xxx.xxx.1
                        IN      AAAA    240d:XXXX:XXXX:XXXX::2
						IN      TYPE257 \# 22 000569737375656C657473656E63727970742E6F7267
  

ワイルドカードで指定する場合は、以下の感じです。

# vi /etc/nsd/example.com
/etc/nsd/example.com
$ORIGIN example.com.
$TTL 1H
@           IN      SOA     ns1.example.com. postmaster.example.com. (
                        2017012601      ;serial
                        1H              ;refresh
                        1H              ;retry
                        1H              ;Expire
                        1H              ;Minimum
                        );

                        IN      NS      ns1.example.com.
						IN      TYPE257	\# 26 0009697373756577696C646C657473656E63727970742E6F7267

ns1                     IN      A       xxx.xxx.xxx.1
                        IN      AAAA    240d:XXXX:XXXX:XXXX::2

www                     IN      A       xxx.xxx.xxx.1
                        IN      AAAA    240d:XXXX:XXXX:XXXX::2
      

設定の反映方法と確認方法は、コチラになります。

NSDのリロードと、確認方法

ゾーンファイルの設定はが終わったので、設定を再読み込みさせます。

# /usr/local/sbin/nsdc reload

今回はdigで動作を確認します。

digやnslookupは、OSと一緒にインストールされるものを使うことが多いと思いますので、RFC 3597 の構文で問い合わせることになります。

# dig www.example.com TYPE257

; <<>> DiG 9.6-ESV-R11-P3 <<>> try-and-test.net TYPE257
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16644
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 4

;; QUESTION SECTION:
;www.example.com.              IN      TYPE257

;; ANSWER SECTION:
www.example.com.       3600    IN      TYPE257 \# 22 000569737375656C657473656E63727970742E6F7267

TYPE257、つまりCAAのレコードが帰ってきていればOKです。

設定できたら、SSL Labsのチェックを見たり、Let's Encryptの証明書を取りに行ってみてください。

NEXT >> トップページに戻る

©Copyrights 2015-2018, non-standard programmer

このサイトは、あくまでも私の個人的体験を、綴ったものです。 軽く参考程度にご利用ください。