to site top page

クロスルート証明書って何?

結論だけでいいという方はページ下部へどうぞ.

クロスルート証明書の話に入る前に

下で参照元として提示するCybertrustやVeriSignなんかの証明書もそうなってますが,サーバに設定されてるEndEntity証明書(以下EE)の信頼性は以下の一連の流れによって検証されます.

  1. EEはCA証明書(IM1とする)から確認され,その確認が署名としてEEに記載された上で発行される
  2. IM1は別のCA証明書(IM2とする)から確認され署名されて発行される
  3. IM2は別のCA証明書(IM3とする)から確認され署名されて発行される
  4. -----上記繰り返し-----
  5. IMnは別のCA証明書(以下Root)から確認され署名されて発行される

上記のような「証明書パス」とも言われるこのつながり(以下Chainと表現)の終端(Trust Anchor:トラストアンカーと呼ばれる.Rootの事)を確認する証明書は無いように見えます.ではRootはどうやって確認するかというと,自分自身(つまりRootそのもの)によって確認することになります.これが RFC5280(証明書(と失効リスト)の標準化過程にある仕様)で言う所のself-signed certificates(自己署名証明書)で,一般に「ルート証明書」などと呼ばれます.

たしかにRootはRootによって確認され署名されていますが,そんなものをなんの疑いもなく信用することはできません.「俺俺!俺だけどさ!ちょっと事故っちゃって!お金が必要なんだ!悪いんだけど!一千万振り込んでくれね!?」という電話が信用出来ないのと一緒です.電話なら「じゃあ一千万振り込んでやるからまず俺の口座に一億振り込んでくれや」とでも返せますが,Rootはどうしましょう.

  1. Root発行するために,発行機関としての厳格な審査をしてもらう
  2. 審査合格してRoot発行したら,Microsoft Root Certificate ProgramとかMozilla CA Certificate Storeとかに頑張って登録してもらう

どうするかというと,大雑把に上記のような感じで,第三者から信用出来ると判断してもらいます.これによってRootが信用出来るわけです(社内でのみ使用する証明書のRootはこれとは異なる場合もあります).

クロスルート証明書の話

クロスルート証明書.分からないのでGoogleに頼ります.「クロスルート証明書」で検索.以下検索順.

要するに,あるTrust Anchorを持ったChainに別のTrust Anchorをつなぐような感じです.ではどうやってつなぐんでしょう.

上で引用したベリサインの説明にはClass3PCA G5とかClass3PCA G1とかにつながってると書いてあるので,どうにかしてそこにつながってる証明書をゲットして,ベリサインのページに置いてある証明書とあわせて中身を見てみたい所です.クロスルート方式を使う理由を考えると,携帯端末からのアクセスが多い所(後述)が設定してる可能性が高そうなので,「mixi」とか「GREE」とか「Mobage」でGoogle検索かけて,引っかかった各ページをhttpsでアクセスし直してみます.

「mixi」でGoogle検索→http://mixi.jpがヒット
https://mixi.jpにアクセスして証明書を見ると発行者が「Cybertrust Japan Public CA G2」.......上で引用したページに書いてあるクロスルート方式の証明書ですねこれ.VeriSignにこだわる必要もないので,一つ目ゲットです.
「GREE」でGoogle検索→http://gree.jpがヒット
https://gree.jpにアクセス.証明書のFQDNがアクセスしたFQDNと違うのでSSLエラー.発行者は「UTN-USERFirst-Hardware」で,英国CoMoDo社が所有してるルートですね.ルートから直接Chain構成しています.
$ openssl s_client -CApath /etc/ssl/certs -connect gree.jp:443 | cat -n
depth=1 C = US, ST = UT, L = Salt Lake City, O = The USERTRUST Network, OU = http://www.usertrust.com, CN = UTN-USERFirst-Hardware
verify return:1
depth=0 C = JP, ST = Tokyo, L = Minato-ku, O = "GREE, Inc.", OU = Development-01, OU = "Hosted by CrossTrust, Inc", OU = Comodo InstantSSL, CN = secure.gree.jp
verify return:1
     1	CONNECTED(00000003)
     2	---
     3	Certificate chain
     4	 0 s:/C=JP/ST=Tokyo/L=Minato-ku/O=GREE, Inc./OU=Development-01/OU=Hosted by CrossTrust, Inc/OU=Comodo InstantSSL/CN=secure.gree.jp
     5	   i:/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
     6	 1 s:/C=JP/O=Comodo Japan Inc./CN=Comodo Japan CA
     7	   i:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root
     8	---
     9	Server certificate
    10	-----BEGIN CERTIFICATE-----
    11	MIIFLTCCBBWgAwIBAgIQWj0SsHOn1qs6Zgexec7a1jANBgkqhkiG9w0BAQUFADCB
-----以下略-----
サーバに設定されている中間CA証明書が間違っているため謎ChainというかChainになってません.しかしながら「s:/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware」であるCA証明書を既に閲覧者側(今回の場合私)で信用されたRootとして所持しているためエラー出ません.
$ nslookup gree.jp
Server:		127.0.0.1
Address:	127.0.0.1#53

Non-authoritative answer:
Name:	gree.jp
Address: 116.93.157.76
Name:	gree.jp
Address: 116.93.157.84

$ nslookup secure.gree.jp
Server:		127.0.0.1
Address:	127.0.0.1#53

Non-authoritative answer:
Name:	secure.gree.jp
Address: 116.93.145.81
Name:	secure.gree.jp
Address: 116.93.157.76
まぁ,gree.jpとsecure.gree.jpが同居してるのでしょう.非クロスルート方式.
「Mobage」でGoogle検索→http://mbga.jpがヒット
http://mbga.jpにChromeでアクセスするとhttp://www.mbga.jpに飛びました.https://www.mbga.jpにアクセスするとFQDN不一致でSSLエラー.証明書見てみると発行者は「VeriSign International Server CA - Class 3」.クロスルート方式のCA証明書は「VeriSign Class 3 International Server CA - G3」なのでこれも非クロスルート方式.

VeriSignのクロスルート方式を探したらCybertrustのクロスルート証明書が見つかりました.mixiを例に,証明書をみつつChainを確認していきます.

$ openssl s_client -CApath /etc/ssl/certs -connect mixi.jp:443 | cat -n
depth=3 C = US, O = GTE Corporation, OU = "GTE CyberTrust Solutions, Inc.", CN = GTE CyberTrust Global Root
verify return:1
depth=2 C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore CyberTrust Root
verify return:1
depth=1 C = JP, O = "Cybertrust Japan Co., Ltd.", CN = Cybertrust Japan Public CA G2
verify return:1
depth=0 C = JP, ST = Tokyo, L = Shibuya-ku, O = "mixi,Inc.", OU = develop01, CN = mixi.jp
verify return:1
     1	CONNECTED(00000003)
     2	---
     3	Certificate chain
     4	 0 s:/C=JP/ST=Tokyo/L=Shibuya-ku/O=mixi,Inc./OU=develop01/CN=mixi.jp
     5	   i:/C=JP/O=Cybertrust Japan Co., Ltd./CN=Cybertrust Japan Public CA G2
     6	 1 s:/C=JP/O=Cybertrust Japan Co., Ltd./CN=Cybertrust Japan Public CA G2
     7	   i:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root
     8	 2 s:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root
     9	   i:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root
    10	---
    11	Server certificate
    12	-----BEGIN CERTIFICATE-----
    13	MIIEtzCCA5+gAwIBAgIUY2wOG5LY/x+h0s926+AvSXD5lywwDQYJKoZIhvcNAQEF
-----以下略-----

証明書が3枚落ちてきます.

  1. mixi.jp:EE証明書
  2. Cybertrust Japan Public CA G2:中間CA証明書1
  3. Baltimore CyberTrust Root:中間CA証明書2

Baltimore CyberTrust Root:中間CA証明書2がクロスルート方式の中間CA証明書ですね.Firefoxで見ると「CN=Baltimore CyberTrust Root」の自己署名したRoot証明書が既に組み込まれているので中間CA証明書2(上記コマンド実行結果の<strong>部分の下2行)は無視してChainを構成しました.閲覧1回目は.再度見に行ったら「CN=GTE CyberTrust Global Root」からChainを構成しました.

自己署名証明書の「CN=Baltimore CyberTrust Root」(以下S)とクロスルート方式の「CN=Baltimore CyberTrust Root」(以下C)を比較してみましょう.

IssuerDN
S:C=IE, O=Baltimore, OU=CyberTrust, CN=Baltimore CyberTrust Root
C:C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc., CN=GTE CyberTrust Global Root
SubjectDN
どちらも:C=IE, O=Baltimore, OU=CyberTrust, CN=Baltimore CyberTrust Root
公開鍵
どちらも:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:a3:04:bb:22:ab:98:3d:57:e8:26:72:9a:b5:79:d4:29:e2:e1:e8:95:80:b1:b0:e3:5b:8e:2b:29:9a:
64:df:a1:5d:ed:b0:09:05:6d:db:28:2e:ce:62:a2:62:fe:b4:88:da:12:eb:38:eb:21:9d:c0:41:2b:01:
52:7b:88:77:d3:1c:8f:c7:ba:b9:88:b5:6a:09:e7:73:e8:11:40:a7:d1:cc:ca:62:8d:2d:e5:8f:0b:a6:
50:d2:a8:50:c3:28:ea:f5:ab:25:87:8a:9a:96:1c:a9:67:b8:3f:0c:d5:f7:f9:52:13:2f:c2:1b:d5:70:
70:f0:8f:c0:12:ca:06:cb:9a:e1:d9:ca:33:7a:77:d6:f8:ec:b9:f1:68:44:42:48:13:d2:c0:c2:a4:ae:
5e:60:fe:b6:a6:05:fc:b4:dd:07:59:02:d4:59:18:98:63:f5:a5:63:e0:90:0c:7d:5d:b2:06:7a:f3:85:
ea:eb:d4:03:ae:5e:84:3e:5f:ff:15:ed:69:bc:f9:39:36:72:75:cf:77:52:4d:f3:c9:90:2c:b9:3d:e5:
c9:23:53:3f:1f:24:98:21:5c:07:99:29:bd:c6:3a:ec:e7:6e:86:3a:6b:97:74:63:33:bd:68:18:31:f0:
78:8d:76:bf:fc:9e:8e:5d:2a:86:a7:4d:90:dc:27:1a:39
署名
S:
Signature Algorithm: sha1WithRSAEncryption
85:0c:5d:8e:e4:6f:51:68:42:05:a0:dd:bb:4f:27:25:84:03:bd:f7:64:fd:2d:d7:30:e3:a4:10:17:eb:da:29:
29:b6:79:3f:76:f6:19:13:23:b8:10:0a:f9:58:a4:d4:61:70:bd:04:61:6a:12:8a:17:d5:0a:bd:c5:bc:30:7c:
d6:e9:0c:25:8d:86:40:4f:ec:cc:a3:7e:38:c6:37:11:4f:ed:dd:68:31:8e:4c:d2:b3:01:74:ee:be:75:5e:07:
48:1a:7f:70:ff:16:5c:84:c0:79:85:b8:05:fd:7f:be:65:11:a3:0f:c0:02:b4:f8:52:37:39:04:d5:a9:31:7a:
18:bf:a0:2a:f4:12:99:f7:a3:45:82:e3:3c:5e:f5:9d:9e:b5:c8:9e:7c:2e:c8:a4:9e:4e:08:14:4b:6d:fd:70:
6d:6b:1a:63:bd:64:e6:1f:b7:ce:f0:f2:9f:2e:bb:1b:b7:f2:50:88:73:92:c2:e2:e3:16:8d:9a:32:02:ab:8e:
18:dd:e9:10:11:ee:7e:35:ab:90:af:3e:30:94:7a:d0:33:3d:a7:65:0f:f5:fc:8e:9e:62:cf:47:44:2c:01:5d:
bb:1d:b5:32:d2:47:d2:38:2e:d0:fe:81:dc:32:6a:1e:b5:ee:3c:d5:fc:e7:81:1d:19:c3:24:42:ea:63:39:a9
C:
Signature Algorithm: sha1WithRSAEncryption
16:b4:2c:c9:f1:5e:e1:a2:7b:9b:78:20:7a:4a:70:70:86:19:00:b7:05:2a:e8:c9:25:39:0f:c3:64:3c:75:09:
d9:89:15:80:07:c2:8d:bc:29:a5:64:50:cf:71:75:47:23:bd:4d:d8:7f:77:9a:51:10:6e:4e:1f:20:3c:47:9c:
43:74:7f:96:84:10:4c:13:43:be:f8:e0:72:2e:ff:bf:ae:3c:0a:03:60:82:4b:6f:f9:9a:c5:1e:f6:af:90:3b:
9f:61:3b:3e:de:9b:05:1a:c6:2c:3c:57:21:08:0f:54:fa:28:63:6c:e8:1b:9c:0f:cf:dd:30:44:13:b9:57:fe
X509v3 extension
S:
X509v3 extensions:
    X509v3 Subject Key Identifier: 
        E5:9D:59:30:82:47:58:CC:AC:FA:08:54:36:86:7B:3A:B5:04:4D:F0
    X509v3 Basic Constraints: critical
        CA:TRUE, pathlen:3
    X509v3 Key Usage: critical
        Certificate Sign, CRL Sign
C:なし

SubjectDNと公開鍵が同一です.

結局クロスルート証明書って何なのさ

上記でごちゃごちゃ書いたものをまとめると,「Serverへアクセスする側への普及率が低いRoot(A)のSubjectDNと公開鍵が同一で,古いけど普及率が高いRoot(B)から署名されている中間CA証明書のこと」.絵で書くと下記のようになります.緑/赤の矢印はEEからのパスの検証方向です.

(画像が表示出来ません)

Root(A)とクロスルートが同じSubjectDN・同じ公開鍵であるため,どちらでも中間CA証明書からパスを検証していくことが出来ます.うまいやり方ですね.うまいやり方ですが,いいんですか?こんなんで

次回に続く.

can't load my result

前後の記事

最近の記事(5件分)

する事

そのうち記事にするかもリスト

欲しい本