ChromeでCT(Certificate Transparency)非対応のSSL EV証明書は警告表示
少し前から、ChromeでHTTPSのページを開いたときに、「○○により確認済みですが、公開監査記録がありません」っていうメッセージが出るようになってて、何それ?と気になっていた。
どうやら、使用されているSSL証明書がCertificate Transparency(以下CT)に対応していないと、このメッセージが出る模様。でもTwitterやらFacebookやらの証明書すら非対応ってどういうこっちゃ?と思ったら、各社まだCT対応の証明書の販売が間に合っていない様子。
各認証局のCT対応状況(2015年3月1日時点)
- シマンテック →「対応済み」のリリース見つけられず。恐らくCT未対応
シマンテックグループではCTに準拠するために、EV SSL証明書にProof情報を追加する対応を2014年(予定)より順次提供することを計画しています。 http://www.symantec.com/ja/jp/page.jsp?id=ssl-certificate-transparency
- サイバートラスト →CT未対応。2015年3月中旬から対応予定
2015 年 3 月中旬に CT に対応したサーバー証明書の提供を開始する予定です。 https://www.cybertrust.ne.jp/ssl/sureserver/ct.html
- digicert →CT対応済み。
Digicert は本年、Google ともに CT(Certificate Transparency:透かし入り証明書)実現の準備に取り組み、CTをサポートする最初の CA(認証局)として、Digicert CT プラットフォームを準備しました。 http://www.digicert.ne.jp/topics/CertificateTransparency.html
- Trend Micro SSL →CT対応済み。
Trend Micro SSL では、2014 年 12 月 22 日のシステム改修により、CT への対応を開始します。システム改修後は、新規に発行されるすべての EV 証明書に対し、CT Log から SCT が発行されるようになります。 http://esupport.trendmicro.com/solution/ja-JP/1106400.aspx?cm_re=Sup-_-tmssl-_-news_05
- グローバルサイン →「対応済み」のリリース見つけられず。恐らくCT未対応
GlobalSignでは、2014年末までにEVの証明書についてCTへの対応を完了する予定です。 https://jp.globalsign.com/blog/2014/certificate_transparency.html
- Rapid SSL →「対応済み」のリリース見つけられず。恐らくCT未対応
非対応のEV証明書はChromeでグリーンバーが表示されなくなる
ChromeにはCTの検証機能が導入されているので、今までも証明書の詳細を見れば「○○により確認済みですが、公開監査記録がありません」というメッセージが表示されていた。とはいえぱっと見じゃ何もわからないので影響はなかった。
でも2015年2月にリリースされたChrome 41(ベータ版)以降は、警告度合いがより厳しくなっているようで、
- 2015 年 1 月 1 日以降に発行した
- CT非対応の
- EV証明書
という3つの条件が揃うと、折角EV証明書なのにグリーンバーが表示されず、OVやDVと同じ表示になってしまうとのこと。
今は上記のような限定された条件だけど、SHA-1→SHA-2のときみたいに、順次警告度合いが厳しくなっていくとしたら、そのうちOVやDVも「CT対応でないと鍵マークが出ない」みたいになっていくのでは・・・と予想。
恐らくは「グリーンバーが出るから、一目でフィッシングサイトと見分けがつく!」というメリットのために、高いお金出してシマンテックのEV証明書を買ってるんだろうに、SHA-1だしCT非対応だしで、グリーンバーどころか三角の警告マークが出ているみずほダイレクトとか本当に可哀想で涙なしには見られない。
DNSで使える便利な*(アスタリスク)
nslookupよりdig!DNS初心者向けのdig解説
このサイト(例えばhttps://infra.xyz/)って、どこのウェブサーバ使ってるんだっけ?というときは、
host infra.xyz
とか
nslookup > set type=a > infra.xyz
でもいけますが、nslookupは既に開発も止まっていて、ゆくゆくは無くなると言われているので、nslookupよりはdigを使おう!と思っています。
でもdig、叩くとこんな感じでべろべろっと色々出るので最初驚くんだよね。
$ dig infra.xyz ; <<>> DiG 9.10.0-P1 <<>> infra.xyz ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33266 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;infra.xyz. IN A ;; ANSWER SECTION: infra.xyz. 600 IN A 153.121.58.159 ;; AUTHORITY SECTION: infra.xyz. 600 IN NS ns1.infra.xyz. infra.xyz. 600 IN NS ns2.infra.xyz. ;; ADDITIONAL SECTION: ns1.infra.xyz. 600 IN A 153.121.58.159 ns2.infra.xyz. 600 IN A 54.64.115.59 ;; Query time: 272 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Feb 28 22:24:44 JST 2015 ;; MSG SIZE rcvd: 122
どこ見たらいいの・・・という訳で一つずつ解説。
先ず、いちばん上にあるのがHEADER。
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33266 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
今回は「status: NOERROR」となってるけど、これは普通に聞いて、普通に返ってきたのでNOERROR(正常)。 他には、NXDOMAIN(リクエストされた名前が存在しない)、REFUSED(リクエストが拒否された)、FORMERR(DNSメッセージのフォーマットが不正)、SERVFAIL(DNSサーバ側の状態が異常)などがある。
「flags: qr rd ra;」は、qr(問い合わせたクエリに対する回答であること)、rd(再帰的問い合わせに対する回答であること)、ra(キャッシュサーバが再帰問い合わせを許可していること)を表している。
なので、どこかのサーバから
dig infra.xyz @ns1.infra.xyz
とDNSコンテンツサーバを指定して叩くと、「flags: qr aa rd;」とrdの代わりにaa(権威を持つ応答であること)になる。
あとは、ns1.infra.xyzは外からの再帰問い合わせは許可していない(=オープンリゾルバではない)ので、
dig yahoo.com @ns1.infra.xyz
のように叩くと、「status: REFUSED」で「flags: qr rd;」になる。
HEADERの下が、QUESTION SECTIONとANSWER SECTION。
;; QUESTION SECTION: ;infra.xyz. IN A ;; ANSWER SECTION: infra.xyz. 600 IN A 153.121.58.159
名前の通り、問い合わせとそれに対する回答。(慣れないとQUESTION SECTIONだけ見ちゃって、あれ値が返ってこない!ってなる)
ちなみに「infnya.xyz」みたいに存在しないドメインを問い合わせて「status: NXDOMAIN」になったときは、ANSWERセクションそのものがなくて、リクエストしたドメイン(infnya.xyz)の親ドメイン(xyz)のSOAレコードが、その下のAUTHORITYセクションで返ってくる。
$ dig infnya.xyz ; <<>> DiG 9.10.0-P1 <<>> infnya.xyz ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 8329 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;infnya.xyz. IN A ;; AUTHORITY SECTION: xyz. 3600 IN SOA ns0.centralnic.net. hostmaster.centralnic.net. 3000169304 900 1800 6048000 3600 ;; Query time: 590 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Feb 28 22:33:48 JST 2015 ;; MSG SIZE rcvd: 104
AUTHORITY SECTIONとADDITIONAL SECTION。
;; AUTHORITY SECTION: infra.xyz. 600 IN NS ns1.infra.xyz. infra.xyz. 600 IN NS ns2.infra.xyz. ;; ADDITIONAL SECTION: ns1.infra.xyz. 600 IN A 153.121.58.159 ns2.infra.xyz. 600 IN A 54.64.115.59
リクエストしたドメイン(infra.xyz)のネームサーバ(ns1.infra.xyz, ns2.infra.xyz)と、そのIPアドレス(153.121.58.159, 54.64.115.59)が表示される。(間違えやすいけど、ここで表示されるのは親のDNSコンテンツサーバに登録されているグルーレコードではなく、実際のns1.infra.xyzにあるinfra.xyz.zoneに書いてあるNSレコードとAレコード)
ちなみにDNSキャッシュサーバのnamed.confのoptionsセクションで、
minimal-responses yes;
にすると、AUTORITY SECTIONとADDITIONAL SECTIONセクションは省略される。(DNSコンテンツサーバとして返す情報に変化はない)
最後に一番下にある色々。
Query time(クエリの応答時間)と、SERVER(応答したDNSサーバのIPアドレスとポート番号)、MSG SIZE(メッセージサイズ)。
;; Query time: 590 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Feb 28 22:33:48 JST 2015 ;; MSG SIZE rcvd: 104
今回はns1.infra.xyzの中でdigを叩いたので、SERVERは自分自身(127.0.0.1)になってます。
という感じなので、何かDNSがうまく引けない・・・というときは、
- STATUSはNXDOMAINか?REFUSEDか?
- flagsにrdがあるか?ないか?
- SERVERのIPはGIPか?LIPか?
辺りを確認して、DNSキャッシュサーバ側の問題なのか、DNSコンテンツサーバ側の問題なのか、を切り分けるようにしています。 +traceオプションつけると、Rootから引いてくれてわーい、とかもありますが、その辺の便利オプションは言い出すときりがないのでまた別途。
最後になりましたが、digはdomain information groperの略です。
参考資料:
- DNSチュートリアル - 初心者のためのDNS運用入門 - ←ものすごくお勧め。ここに書いたことの殆どはここから学んだ。
- Linux教科書 LPICレベル2
グルーレコードの確認方法
いったん、+traceで親のDNSコンテンツサーバを調べて、
$ dig infra.xyz +trace ; <<>> DiG 9.10.0-P1 <<>> infra.xyz +trace ;; global options: +cmd . 346259 IN NS h.root-servers.net. . 346259 IN NS j.root-servers.net. . 346259 IN NS k.root-servers.net. . 346259 IN NS g.root-servers.net. . 346259 IN NS l.root-servers.net. . 346259 IN NS i.root-servers.net. . 346259 IN NS f.root-servers.net. . 346259 IN NS c.root-servers.net. . 346259 IN NS b.root-servers.net. . 346259 IN NS m.root-servers.net. . 346259 IN NS d.root-servers.net. . 346259 IN NS a.root-servers.net. . 346259 IN NS e.root-servers.net. . 347445 IN RRSIG NS 8 0 518400 20150224050000 20150214040000 16665 . 49XDs9Icoki4ReHy1mUexld6E7w8xCb7NTXMlie4bckAQ2p61KjzkhbJ 89DT98Xpc2IcfJy1TWgee2CTthYXXbLuuhEJdZEUrlJW2ku2IjSaEH3L JlriAwtHgrziIKgWseXAxUVJc7/w+QoYd9XV7oIOHwL3Q8MH65ako+z2 nm8= ;; Received 913 bytes from 127.0.0.1#53(127.0.0.1) in 14 ms xyz. 172800 IN NS z.nic.xyz. xyz. 172800 IN NS y.nic.xyz. xyz. 172800 IN NS x.nic.xyz. xyz. 172800 IN NS generationxyz.nic.xyz. xyz. 86400 IN DS 3599 8 1 3FA3B264F45DB5F38BEDEAF1A88B76AA318C2C7F xyz. 86400 IN DS 3599 8 2 B9733869BC84C86BB59D102BA5DA6B27B2088552332A39DCD54BC4E8 D66B0499 xyz. 86400 IN RRSIG DS 8 1 86400 20150226050000 20150216040000 16665 . 2wVBaGY2zO+b1jX12HPs7Ly0za90q+AtGM5tm3fRyOrDpCQt1XD0iJnc ij2jWuXWWXL8005Qqvi5C/gRiGJswfChKuX4J4/OKGGPzSVjxGynuEQu m3hTUtFWNESuGRAqS1zlsypFRP9O8mpaTamHRxamcQuvDSrbZBLpTbb3 sOU= ;; Received 537 bytes from 192.33.4.12#53(c.root-servers.net) in 122 ms infra.xyz. 3600 IN NS ns1.infra.xyz. infra.xyz. 3600 IN NS ns2.infra.xyz. 1h97h2oec2juov8dlbbjj6i7ik26bm8d.xyz. 3600 IN NSEC3 1 1 1 - 1KKABMBG1LO63FOI21UHUBCQJDM5D2RM NS SOA RRSIG DNSKEY NSEC3PARAM 1h97h2oec2juov8dlbbjj6i7ik26bm8d.xyz. 3600 IN RRSIG NSEC3 8 2 3600 20150311130404 20150209214037 38328 xyz. teRlK0XJ4/Z4SmzTdI3idnwN4Zf4rLHYBap/w0KV34CB6ICtkWsBM1bk hWS4jSQ6XrjFO/OrOEKvgl/DcoyYiEsijJkcqo364JYAVUCzK1cdHlJQ efbZjruxLPEoe+34jb6gZvuY15huradsTnEnyDKQraMuOnLCUpqqiKun L9E= jap3nebfhkg51v8uie6lh8n8fm536euf.xyz. 3600 IN NSEC3 1 1 1 - JTBA28MNE9VHFM3561JQOEB66MS83DLK NS DS RRSIG jap3nebfhkg51v8uie6lh8n8fm536euf.xyz. 3600 IN RRSIG NSEC3 8 2 3600 20150315190829 20150213161936 38328 xyz. ctm4qzSZRJt9gww/VHZ7PhDS8bEkpaRdkSi2FqyIf+hBA83Z7nWvQGUN Ubxd/kgR37gd3NDXoFXiJ3jhYBqJn6Ejfv9kPCv08kjEJ2lQ9W6wfSnA z8Fw67+SvQlwOIntcuDGvW7eL7He5B0C2VmQXVhLhI8dBzpbYR8tMove VCc= ;; Received 591 bytes from 185.24.64.42#53(y.nic.xyz) in 137 ms infra.xyz. 600 IN A 153.121.58.159 infra.xyz. 600 IN NS ns2.infra.xyz. infra.xyz. 600 IN NS ns1.infra.xyz. ;; Received 122 bytes from 153.121.58.159#53(ns1.infra.xyz) in 0 ms
親(z.nic.xyz)に向かって問い合わせると、AUTHORITY SECTIONとADDITIONAL SECTIONにグルーレコードの情報が表示される。
$ dig infra.xyz @z.nic.xyz ; <<>> DiG 9.10.0-P1 <<>> infra.xyz @z.nic.xyz ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37776 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;infra.xyz. IN A ;; AUTHORITY SECTION: infra.xyz. 3600 IN NS ns1.infra.xyz. infra.xyz. 3600 IN NS ns2.infra.xyz. ;; ADDITIONAL SECTION: ns1.infra.xyz. 3600 IN A 153.121.58.159 ns2.infra.xyz. 3600 IN A 153.121.58.159 ;; Query time: 55 msec ;; SERVER: 2a04:2b00:13ee::42#53(2a04:2b00:13ee::42) ;; WHEN: Mon Feb 16 23:22:27 JST 2015 ;; MSG SIZE rcvd: 106
ちなみに、何も指定せずに普通に問い合わせた時に出るAUTHORITY SECTIONとADDITIONAL SECTIONは、グルーレコードの値ではなく、実際のDNSコンテンツサーバ(今回の例で言えばns1.infra.xyzとns2.infra.xyz)で設定されているNSレコードとAレコードの値なので注意。
グルーレコードのNSと、DNSコンテンツサーバのNSレコードはどっちが優先されるか?
グルーレコードに
infra.xyz. 3600 IN NS ns1.infra.xyz. infra.xyz. 3600 IN NS ns2.infra.xyz. ns1.infra.xyz. 3600 IN A 153.121.58.159 ns2.infra.xyz. 3600 IN A 153.121.58.159
と登録して、でも実際のDNSコンテンツサーバ(153.121.58.159と54.64.115.59)に置いてあるゾーンファイルには、
infra.xyz. 600 IN NS ns2.infra.xyz. infra.xyz. 600 IN NS ns1.infra.xyz. ns1.infra.xyz. 600 IN A 54.64.115.59 ns2.infra.xyz. 600 IN A 54.64.115.59
と書いてある状態で、
dig infra.xyz @ns1.infra.xyz
したら、153.121.58.159と54.64.115.59のどっちに聞きにいくでしょう?
私、153.121.58.159だと思ってたんだけど、54.64.115.59だった。
$ dig infra.xyz @ns2.infra.xyz ; <<>> DiG 9.10.0-P1 <<>> infra.xyz @ns2.infra.xyz ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16672 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;infra.xyz. IN A ;; ANSWER SECTION: infra.xyz. 600 IN A 153.121.58.159 ;; AUTHORITY SECTION: infra.xyz. 600 IN NS ns2.infra.xyz. infra.xyz. 600 IN NS ns1.infra.xyz. ;; ADDITIONAL SECTION: ns1.infra.xyz. 600 IN A 54.64.115.59 ns2.infra.xyz. 600 IN A 54.64.115.59 ;; Query time: 5 msec ;; SERVER: 54.64.115.59#53(54.64.115.59) ;; WHEN: Mon Feb 16 23:10:30 JST 2015 ;; MSG SIZE rcvd: 122
グルーレコードに書いてあるDNSコンテンツサーバに行って、そこでもう1回NS引いてからA引くんだね。勉強になった。
digの+shortとか+norecursionとかは、後半何文字か省略しても通る
digの+shortは+shorでも通る(さすがに+shoはダメだった)し、+norecurseは+norでも通る。 なんか「あ、いまtypoした?」って時に普通に応答返ってきて、ん?と思ってたんだけど、まさか後半何文字か省略しても通る仕様だったとは。