自堕落な技術者の日記

oauth.jp: Y!J API が止まった日 - GlobalSign の Root 証明書切れから学んだこと
http://oauth.jp/blog/2014/01/30/globalsign-root-cert-expired/
(引用) 昨日あたりから、Yahoo! Wallet や YConnect といった、Yahoo! Japan の API にアクセスできなくなったって人、ちらほらいるかもしれませんね。

というブログの記事を見つけまして、ざっと目を通してみてもよくわからなかったのでちょっと証明書など見てみました。

試しに https://userinfo.yahooapis.jpに繋いでみても問題なさそう。

ちゃんとした説明はYahooデベロッパーネットワークの「WebAPIやOpenIDでSSLエラーが起きる現象につきまして(2014.01.29)」に書いてありました。

GlobalSignのリポジトリには2つのルート証明書があって有効期限が切れたのはこのページの下の方の証明書みたいです。最初は、検証ができないというので相互認証してたり、鍵更新のあたりがおかしいのかと疑って証明書をいろいろみてみたわけです。

最新のブラウザで表示される検証の成功する証明書のチェーンは以下のようでした。

ルートCA証明書
シリアル番号	04:00:00:00:00:01:15:4b:5a:c3:94
署名アルゴリズム	SHA1withRSA
主体者名	C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA
有効期間	1998/09/01-2028/01/28
主体者鍵ID	607B661A450D97CA89502F7D04CD34A8FFFCFD4B
サブCA証明書
発行者名	C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA
主体者名	C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA - G2
有効期間	2011/04/13-2022/04/13
発行者鍵ID	607B661A450D97CA89502F7D04CD34A8FFFCFD4B
主体者鍵ID	5D46B28DC44B741CBBEDF573B63AB7388F759E7E

それじゃぁ、期限切れになった証明書を見てみると

期限切れになったルートCA証明書
シリアル番号	02:00:00:00:00:00:d6:78:b7:94:05
署名アルゴリズム	MD5withRSA
主体者名	C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA
有効期間	1998/09/01-2014/01/28(確かに期限切れ)
主体者鍵ID	607B661A450D97CA89502F7D04CD34A8FFFCFD4B(あれれ？)

これなんだかなぁ。主体者鍵IDが同じ、つまり同じルート鍵を使ったままで、有効期限とシリアル番号と署名アルゴリズムが違う証明書があるわけです。(そういえば前にみたっけ)。こういう事していいんでしたっけ？ルート鍵更新しなくていいんでしたっけ？

結局、クライアント側すなわちYahoo APIを使う側が、ルート証明書ストアをちゃんとアップデートしてなくて、そのために接続できなかっただけという事なんですね。(そう理解してから読むとブログの記事も呑みこめました。)

Debian 5だと問題だったと書いてあるので見てみるとDebianの場合には /etc/ssl/certs にルート証明書ストアがあって、ca-certificatesというパッケージでアップデートされているわけですがDebian 5は2012年2月6日にとっくにサポート終了になっているので、そりゃ文句を言ってもしかたがない。CentOS 5についてはフルアップデートは2014年Q1まで、メンテナンスサポートは2017年3月31日まで提供されるのでCentOS 5では今回の問題にはならないんだろうと思います。

結局、今回の影響はあまりなくて

• ウェブブラウザを使っていてちゃんとアップデートをしている人にはあまり影響はなかったはず
• OSのアップデートもちゃんとしている人にはあまり影響がなかったはず
• CentOSにもOpenSSLトラストリストを持つようなパッケージは確かなかったっぽいので影響はない。CentOS 5もまだサポートされているので問題ないはず。
• 他のLinux、なんとかBSDなんかもOpenSSLのトラストリストを持つパッケージが無いので問題なさそう。
• Debian、Ubuntuだけはca-certificatesというパッケージがあるのでDebian5みたいなサポート終了しているものでは問題になるケースがあった。

というところなのかなと思います。

もっと面白い話が見つかるかと思ったけど、それほどでもなかったorz 鍵更新や相互認証じゃないっていうのはどうなんですかねぇ？

gregさんが新しいNexus 5をゲットして、ルート証明書リストを Root CA Viewer Lite でエクスポートして送ってくれたので(gregさんありがとう)、 早速比較してみます。

で、比較してみると

差分はこんな感じ。

バージョン	ルート認証局数	追加	変更
Android 4.0.4	134	-	-
Android 4.3.1	146	12	2
Android 4.4	150	4	-

たった 4 つしか増えていないと・・・まぁ、そんなもんか。

新規追加されたのは

以下が、新規に追加された4個のルート認証局の一覧です。

認証局の識別名(DN)	有効期間	署名アルゴリズム	鍵長
CN=ACCVRAIZ1, OU=PKIACCV, O=ACCV, C=ES	2011-2030	SHA1withRSA	RSA 4096bit
CN=Hellenic Academic and Research Institutions RootCA 2011, O=Hellenic Academic and Research Institutions Cert. Authority, C=GR	2011-2031	SHA1withRSA	RSA 2048bit
CN=Entrust Root Certification Auuthority - EC1, OU=See www.entrust.net/legal-terms, OU=(c) 2012 Entrust, Inc. - for authorized use only, O=Entrust, Inc., C=US	2012-2037	SHA384withECDSA	ECC secp384r1
CN=StartCom Certification Authority G2, O=StartCom Ltd., C=IL	2010-2039	SHA256withRSA	RSA 4096bit

ギリシャの認証局と、エントラストの楕円 SHA384withECDSA secp384r1なんかが 特徴的ですかね。

今日はこのへんで

関連記事

• Android 4.0.4 と 4.3.1 のルート証明書リストの違いを見てみたぞ(2013年11月6日)
• Xperiaに搭載されたルート認証局証明書 (2010年4月26日)
• Android 4.0 以降のルート証明書ストアを調べるツールを作ってみたいぞ (2012年09月30日)
• (小ネタ)Android 4.0 ICSのルート証明書ストア (2012年09月04日)
• Windowsルート認証機関の更新(2009.02) (2009年04月03日)

熱があって体調激悪ですが、なんか書いてみましたの第一弾です。

4.4 KitKatが出る前に、手持ちのAndroid 4.0.4と4.3.1の信頼するルート証明書のリストの魚拓(=バックアップ)を取っておこうと Root CA Viewer Lite(for Android 4.x) に手を加えてみたんですが、別の会にでもお話をしようと思うハマったポイントがあり紆余曲折の末、 まぁ何とか半日かけてアップデートができたわけです。

今回のRoot CA Viewer Lite 1.2.2の機能追加では、Android 4.xのルート証明書をシステム登録されたものも、 ユーザ追加したものも全てASN.1 DERバイナリ形式で取り出し、ZIPで固めてこれをSDカードの領域に エクスポートするというものです。 (本当は処理中のグルグルとか表示させないといけないんでしょうけど、 手抜きでホントすみません。)

で、比較してみると

これで無事、ルート証明書は取り出せるようになったので、 比較してみましょう。差分の個数はこんな感じ。

バージョン	ルート認証局数	追加	変更
Android 4.0.4	134	-	-
Android 4.3.1	146	12	2

古いXperiaの時にもルート認証局のリストを調べていますが、 その時はAndroid 1.6 で 52のルート認証局でした その時から比べて随分増えていますよね。

新規追加されたのは

以下が、新規に追加された12個のルート認証局の一覧です。欧州が多い感じがありますが、セコムトラストさんも追加されてますね。 ほぼ、SHA256withRSAなんだなぁっていうのが特徴的かなと思います。

認証局の識別名(DN)	有効期間	署名アルゴリズム	RSA鍵長
CN=D-TRUST Root Class 3 CA 2 2009,O=D-Trust Gmbh,C=DE	2009-2029	SHA256withRSA	2048bit
CN=T-TeleSec GlobalRoot Class 3,OU=T-Systems Trust Center,O=T-systems Enterprise Services GmbH,C=DE	2008-2033	SHA256withRSA	2048bit
CN=Buypass Class 3 Root CA,O=Buypass AS-983163327,C=NO	2010-2040	SHA256withRSA	4096bit
CN=Swisscom Root CA 2,OU=Digital Certificate Services,O=Swisscom,C=CH	2011-2031	SHA256withRSA	4096bit
CN=Izenpe.com,O=IZENPE S.A.,C=ES	2007-2037	SHA256withRSA	4096bit
CN=Certinomis - Autorité Racine,OU=0002 433998903,O=Certinomis,C=FR	2008-2028	SHA1withRSA	4096bit
CN=Buypass Class 2 Root CA,O=Buypass AS-983163327,C=NO	2010-2040	SHA256withRSA	4096bit
CN=EC-ACC,OU=Jerarquia Entitats de Certificacio Catalanes,OU=Vegeu https://www.catcert.net/verarrel (c)03,OU=Serveis Publics de Certificacio,O=Agencia Catalana de Certificacio (NIF Q-0801176-I),C=ES	2003-2031	SHA1withRSA	2048bit
CN=A-Trust-nQual-03,OU=A-Trust-nQual-03,O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT	2005-2015	SHA1withRSA	2048bit
OU=Security Communication RootCA2,O=SECOM Trust Systems CO.,LTD.,C=JP	2009-2029	SHA256withRSA	2048bit
CN=D-TRUST Root Class 3 CA 2 EV 2009,O=D-Trust GmbH,C=DE	2009-2029	SHA256withRSA	2048bit
CN=Root CA Generalitat Valenciana,OU=PKIGVA,O=Generalitat Valenciana,C=ES	2001-2021	SHA1withRSA	2048bit

変更されたのは???

認証局の識別名(DN)	有効期間	署名アルゴリズム	RSA鍵長
CN=Thawte Premium Server CA/emailAddress=premium-server@thawte.com,OU=Certification Services Division,O=Thawte Consulting cc,L=Cape Town,ST=Western Cape,C=ZA	1996-2021	SHA1withRSA	1024bit
CN=Thawte Server CA/emailAddress=server-certs@thawte.com,OU=Certification Services Division,O=Thawte Consulting cc,L=Cape Town,ST=Western Cape,C=ZA	1996-2021	SHA1withRSA	1024bit

両方ともThawteのやつなんですが、証明書の変更された差分を見てみると、認証局の鍵は1024bitのやつ同じものを使ったまま、署名アルゴリズムをMD5withRSAからSHA1withRSAにして、 有効期限を1年延ばして、シリアル番号を変更して証明書をロールオーバーしちゃってます。 鍵長もそうですが、同じ鍵を使い続けててこれ、ホント大丈夫なんですかね。運用規定違反になったりしないのかな。

おまけ

Root CA Viewer Liteで証明書をエクスポートすると、個々の証明書のファイルは「system_4fbd6bfa.0」みたいない感じになっており、JCEの証明書ストアの証明書のalias 「system:4fbd6fa.0」に対応しています。「4fbd6fa.0」はOpenSSLの認証局の証明書ファイルの保管方法によるもので、証明書の識別名のハッシュみたいなものから作られています。 この名前の決まり方はJNSAのセミナー「OpenSSL 1.0.0のリリースについて」でお話しており、 スライドのページ番号32、33をご覧頂ければと思います。 この記事思い出して確認したんですが、 ハッシュファイル名は -subject_hash_old の方、つまりOpenSSL 0.9.8ベースのハッシュファイル名になったままのようですね。 とはいえ、ベースとなっているOpenSSLは0.9.8とは限らないので、どのなのかは調べる方法あるんですかね。

今日はこのへんで

関連記事

• Xperiaに搭載されたルート認証局証明書 (2010年4月26日)
• Android 4.0 以降のルート証明書ストアを調べるツールを作ってみたいぞ (2012年09月30日)
• (小ネタ)Android 4.0 ICSのルート証明書ストア (2012年09月04日)
• Windowsルート認証機関の更新(2009.02) (2009年04月03日)

JCE Provider Checkerに引き続き、 Android 4.0以降のルート証明書ストアを表示させるための ツール"Root CA Viewer Lite (for Android)"という無料アプリを 昨日公開しました。

標準機能でもルート証明書ストアは見られるんですが、 国名、組織名、部署名といった証明書の識別名の一部と 有効期間、フィンガープリントぐらいしか見られないんですよね。 「それじゃあ証明書の特定はフィンガープリントでしか できないだろー!!!」みたいな••• いくつ証明書が入っているのかも地味に数えないとわからないし•••

とりあえずJavaのX509Certificateクラスをベースに 証明書の基本領域、拡張領域など 取得可能なものは表示できるようにしました。

識別名は文字列で処理してんるんですが、 emailAddressやserialNumberなどのマイナーな属性の相対識別名が OID.1.2.840.113549.1.9.1=#1615616161... みたいな表現になっちゃってた やつを文字列処理で "E=hoge@hoge.com"みたいに見やすいように変換しています。

このツールの残念なのは、 Javaの標準機能だけだとサポートしてない拡張領域の解析が面倒臭くて やってないのと、 楕円の証明書の鍵長が取得できないんですよね。 拡張領域の並び順もわかんなくなっちゃうし、、、 その辺りはちょっとプログラムサイズの大きい無料の PRO版出すかなと思っているので乞うご期待ってことで、、、

クリティカルフラグの表示が"[!]"はクリティカル、"[-]"はノンクリティカルとか ダサ過ぎるのと、基本領域を表すListViewの要素が"*** BASIC FIELD ***" って ダサ過ぎるので、このあたりは色づけしたりアイコンつけたり何とかしたいと思ってます。 (時間があればorz) しっかし、JCE Provider CheckerもRoot CA Viewerも同じようなListViewの 見てくれで芸が無いっすねぇorz。

またDigiNotarと似たような事件とか勃発して「おーい、 どのルート証明書を無効にしていいのかよくわかんないよー」とか いうときに思い出して活用していただければと思います。

ではでは

「恥の多い生涯を歩んできました」

最近、私はPKIな人ではなく、雑用に忙殺される悲しい毎日を送っております。先日、同僚にそそのかされ「中華パッド」なるものを買ってしまいサルのように喜んでつかっております。

組み込みのルート証明書ストア

何やら、Android 4.0 ICSになってからルート証明書ストアの方式が変わってしまったそうで、BouncyCastleプロバイダのJava Key Storeだったものが、OpenSSLのそれに変更になったそうです。

■Android 4.0 より前のルート証明書ストア
/system/etc/security/cacerts.bks ファイル
■Android 4.0 以降のルート証明書ストア
/system/etc/security/cacerts ディレクトリ

ディレクトリの中を覗いてみると、各ルート証明書はPEM形式で、 "00673b5b.0" みたいなファイル名で、まさにOpenSSLの"ca"コマンドで使われるハッシュファイル名形式になっています。

OpenSSL 1.0.0 コマンドでハッシュファイル名の計算方法を見てみましょう。

% openssl x509 -in 00673b5b.0 -hash -noout
2e4eed3c ←うーん一致しない

% openssl x509 -in 00673b5b.0 -subject_hash_old -noout
00673b5b ←おお、一致した

ということは、OpenSSL 1.0.0 で導入されたハッシュファイル名の計算方法ではなく、OpenSSL 0.9.8とかの古いハッシュファイル名の計算方法でファイルが置かれていることがわかります。

初期状態でのルート証明書の数は134個で、最近の多くのブラウザやOSからしてみると割と少ない方かもしれませんね。

ユーザが追加した認証局証明書ストア

前述のストアはシステム組み込みの認証局証明書ストアなようで、例えばPKCS#12などを読み込んだ際の中間認証局証明書は上の場所には入らずに別の場所に入ります。

/data/misc/keychain/cacerts-added/

ユーザの秘密鍵と証明書、パスワードのストア

ユーザの秘密鍵と証明書、パスワードは下記のフォルダに保存されます。

/data/misc/keystore/

クレデンシャルには名前をつけて保存されますが、秘密鍵、ユーザ証明書、ルート証明書までのチェーンはそれぞれ下記のファイル名で保存されているようです。ファイル形式は独自のバイナリで、先頭4バイトが0である以外は、どのようにそれらが作られているのかはわかりませんでした。

番号_USRPKEY_名前
番号_USRCERT_名前
番号_CACERT_名前

otacerts.zipファイルの謎

ちなみに、cacertsディレクトリはotacerts.zip なるファイルがあり何が入っているのか気になったので覗いてみました。ただ testkey.x509.pem というマルチRDNの自己署名公開鍵証明書が入っているだけなんですが、

DN: C=US, ST=California, L=Mountain View, O=Android, OU=Android, CN=Android/emailAddress=android@android.com

公開鍵の公開指数がいまどきセキュリティ上問題のある3なのがちょっと気になるところでしょうか。

あと、古いOpenSSL 1.0.0より前のやつでみると有効期間がだと化けちゃうのかなぁと思って見てみたら

Not Before: Feb 8 09:29:20 2012 GMT
Not After : May 21 03:01:04 1903 GMT　＜＜これ

ASN.1レベルでも

UTCTime '120208092920Z'
GeneralizedTime '19030521030104Z'

本当に開始が2012年で終了が1903年というものすごい証明書でした。いろいろ突っ込み所がある証明書を入れとく意義って何なんすかねぇ？

今日はこの辺で

前回からの続きで、docomoのスマートフォンXperiaについて調べています。今回はXperiaに搭載されている信頼するルート証明書について書こうと思います。

XperiaのOSは2009年9月15日にリリースされたちょっと古めのAndroid 1.6なんだそうです。ルート証明書の一覧は "/system/etc/security/cacerts.bks" にあり、ファイルを取り出すにはAndroid SDKのツールを使って母艦にコピーします。

% adb pull /system/etc/security/cacerts.bks cacerts.bks

"cacerts.bks"はJavaのkeytoolで扱える証明書ストアになっているんですが、BouncyCastle JCEライブラリ専用の証明書ストアになっているので、これを指定して取り出します。

で、ルート証明書の一覧を見てみたところ、こんな感じでした。

全部で52のルート証明書が登録されており、Windowsの297に比べてかなり少なめ、下のリストのSun Javaと見比べるとやや古いSun Java J2SE 6.0 Update 5ぐらいの時期のルートをもとにしているのかもしれません。

• Sun JDK 6.0 update 19 - 75
• Sun JDK 6.0 update 18 - 72
• Sun JDK 6.0 update 7 - 55
• Sun JDK 6.0 - 43

登録されているルート証明書をみてみると、ほとんどが2009年11月のMicrosoftのWindows Root Certificate Programに含まれている証明書なんですが、3つだけ

• Global Sign Root CA (C=BEのもの)
• StartCom Free SSL CA
• Sony Ericsson Secure E2E CA

だけがプログラムに含まれないAndroid独自の証明書のようです。(ソニエリ以外はSun Javaには入ってたのかな？)。Global Sign Root CAのkeyUsageのエンコーディングで警告がでますね。時間があるとき、見てみます。

ソニエリが入っているってことは、cacerts.bksは、Android OSに共通なものではなくて、機種毎に違うものなのかもしれませんね。

今日はこんなところで、、、

追記：GlobalSignのkeyUsageの警告

古いGlobalSignのルート証明書でkeyUsage拡張のエンコーディングで警告がでるので見てみました。ASN.1 BIT STRING型の値としてはkeyCertSign(5)とCRLSign(6)のビットが立っていて最上位が一つビットが立たないのでunused bitsが1になり、正しくは

03:02:01:06(BIT STRING 1 unused bits '1100000'B)

となるところが間違えて

03:02:00:06

となっちゃっているのでエンコーディングの警告が出ていたのでした。古い証明書ではたまにこんな間違いがありますよね。