自堕落な技術者の日記 : PKI - livedoor Blog（ブログ）

PKI

2020年11月29日09:46

カテゴリ: SSLTLS; PKI

Mozilla FirefoxのCRLiteで遊ぶ (moz_crlite_queryの話)

OCSPによる失効検証は、先日のApple macOS Big Burrのソフトウェアコード署名の大量の検証で、OCSPレスポンダ高負荷による失効検証の障害が出たのではと推測されるように、通信障害、サーバー障害などでOCSP応答が取れないなどのことがあって、最近非常に評判が悪いです。そのため、ウェブブラウザの世界では、Chromeでは CRLSet、Firefox ではCRLiteという別の失効検証方法を使おうとしているそうです。ChromeのCRLSetについては2013年2月に、CRLSetで本当に大丈夫なんだろうかと思い「将来Google ChromeがSSL証明書のオンライン失効検証をやめて独自の失効情報プッシュを行うという困った話」というブログエントリを書かせていただきました。(が、その後、Chrome CRLSetがどうなっているのかよくわかっていません。)

で、Firefox CRLiteについてですが、先日、「Querying CRLite for WebPKI Revocations」(2020.11.26)という記事が公開されました。Firefox Nightly バージョンで実装されているCRLite失効検証の機能を確認するためのPythonのツール moz_crlite_query が合わせて公開されています。Firefox Nightly 85.0 で実装されているということなので、2021年1月26日リリース予定のFirefox 85正式版ではCRLite失効検証が使われているということなのでしょう。(間違っていたらごめんなさい。) おお、FirefoxのCRLiteがいよいよ実運用されるんだなぁ、、、とwktkしながら、今日はこの moz_crlite_query を試してみたいと思います。

インストール

Python 3.7 以上の環境で


% pip install moz_crlite_query

とすればインストールすることができます。依存するPythonモジュールをビルドするのにgcc、g++が必要になるみたいです。

私のMac Book Airは古くから使っていてPython環境が汚れていて、OSで提供されるPython2.7、Python3?、macportsのPython2、Python3などあり、切り替えがうまくいかず、インストールでとてもハマりました。古いPython setuptoolsだと、2.7等、バージョンが古くてもインストールエラーにならないようで、これでハマりました。最初からpyenv使っときゃよかったんだよなぁ、、、。pyenvでPython 3.9を入れ直して、Windows 10 WSL2でインストールしたmoz_crlite_queryスクリプトをコピーし戻してやっと動くようになりました。pyenvでインストールしたときmoz_crlite_queryスクリプトはどこにインストールされるんだ？？？

Windows 10 WSL2のUbuntuに入れるのは、それほど大変ではありませんでした。aptコマンドで足りてなかった、gcc、g++、python3-devを入れてpipでインストールできました。

サイトで紹介されてる実行例は、いちいちPEM証明書ファイル持ってきてますが、「moz_crlite_query --hosts 調べたいTLSサイトFQDN」で調べられます。例えばMacでwww.nist.govを調べればこんな感じ、
crlite-mac
Windows WSLでec.europa.euを調べればこんな感じで実行できます。
crlite-win
(絵文字使うんじゃね～～！！！)
PEM証明書を指定して「moz_crlite_query PEM証明書ファイル」でも調べることができます。

で、ちょっと見てみるぞ、と

CRLiteのデータベースは一日に4回更新して配布されるそうで、moz_crlite_queryコマンドは、データベースを確認して新しいのがあれば~/.crlite_dbにデータベース一式をダウンロードして使用します。ファイルの一覧はこんな感じ。


2020-11-24T00:08:12+00:00Z-full		2020-11-26T18:08:13+00:00Z-diff
2020-11-24T06:08:12+00:00Z-diff		2020-11-27T00:08:16+00:00Z-diff
2020-11-24T12:08:14+00:00Z-diff		2020-11-27T06:08:13+00:00Z-diff
2020-11-24T18:08:15+00:00Z-diff		2020-11-27T12:08:20+00:00Z-diff
2020-11-25T00:08:23+00:00Z-diff		2020-11-27T18:08:11+00:00Z-diff
2020-11-25T06:08:05+00:00Z-diff		2020-11-28T00:08:14+00:00Z-diff
2020-11-25T12:08:22+00:00Z-diff		2020-11-28T06:08:12+00:00Z-diff
2020-11-25T18:08:11+00:00Z-diff		2020-11-28T12:08:12+00:00Z-diff
2020-11-26T00:08:11+00:00Z-diff		2020-11-28T18:08:21+00:00Z-diff
2020-11-26T06:08:17+00:00Z-diff		intermediates.sqlite
2020-11-26T12:08:14+00:00Z-diff

コマンドを実行すると表示されている通り、2457のパブリックな中間CAが登録されているようで、FAQでは「すべてのCA」とか言っちゃってますが、そういうわけではなさそう。エンドエンティティがSSLサーバー証明書を発行しているような中間CAは概ね登録されているようですが、SSLサーバー証明書発行用でないCAや、中間CA証明書の検証に使うCAは登録されていないようです。登録されてない中間CAに対してクエリをかけると「Enrolled in CRLite: ✕」のように表示され登録されてないことがわかります。(絵文字ヤメロw)

「intermediates.sqlite」が中間CAのSQLiteデータベースになっており、中にはテーブルは一つしかなく、こんな感じでスキーマ定義されています。なんとなく想像つきますね。


CREATE TABLE intermediates (
  id TEXT PRIMARY KEY,
  last_modified TEXT,
  subject TEXT,
  subjectDN BLOB,
  derHash BLOB,
  pubKeyHash BLOB,
  crlite_enrolled BOOLEAN, -- crlite_enrolled = FALSEな中間CAは1656なので、対応してるのは801 CA?
  whitelist BOOLEAN); -- whitelist = TRUEな中間CAは登録されてなかった

とまぁ、こんな感じなんですが、CRLSetのときに書いた疑問は払拭されず、本当に信用できるのかモヤモヤしますね～～～。なんかヤベーーーの見つけちゃった気もするし。ブラウザでどう使われているのか見ないと何ともいえないですが、、、、

今日はこんなとこで。環境も汚れてきたしバッテリーも酷い状況なのでM1 Mac Book Air買うかなぁ、、、

タグ：: #PKI; #Firefox; #SSL; #TLS; #CRL; #失効検証; #OCSP; #Chrome; #CRLite; #CRLSet

2018年08月27日06:27

カテゴリ: PKI

最近の証明書の話題(3): デジタル証明書形式の電子委任状のプロファイルに関する考察

お詫び：この記事は３月に書き始め、５月に大方できていたのですが、なんかボリューム満点な割に、落とし所がなくなってしまい、辛くなって放置していました。これが終わらないせいで、他の記事も何となく書くのが億劫になっていました。やっと８月末の今日、少し書き足して生煮え記事として供養させてくださいm(_ _)m。ただここで言いたいのは
(電子証明書方式の)電子委任状は、お役所への申請だけでなく、企業間の電子契約でも、前より格段に使いやすい証明書なので「ちゃんと普及してください！！！」
ってことだけです。

今日は正確には証明書ハンターネタとは言えないんですが、今後おもしろそうな、「電子委任状」という証明書が出てきそうってことで紹介したいと思います。ちょっと長いです。ご容赦ください。

もくじ
1. 電子委任状とは
 2. 証明書の識別名の構造(おさらい)
3. デジタル証明書形式の電子委任状のサンプル発行
 4. 汎用の証明書ビューアーで主体者別名の表示は問題ないか
　 4.1. Windowsの表示
　 4.2. macOSの表示
　 4.3. Firefoxの表示
　 4.4. Adobe Acrobat Reader DCの表示
　 4.5. Java JCE SUNプロバイダの表示
　 4.6. Java JCE BouncyCastle BCプロバイダの表示
　 4.7. OpenSSLのx509 -textコマンドによる表示
　 4.8. 表示結果サマリ
 5. 電子委任状の識別名に関する考察
　 5.1. 属性タイプについて
　 5.2. organizationIdentifier属性タイプについて
　 5.3. description属性タイプについて
　 5.4. OUを使う事の是非について
　 5.5. ではどの属性タイプを使うのが良かったのか
　 5.6. 似た日本語文字の問題
　 5.7. その他、記載例における細かい課題

1. 電子委任状とは

既にご覧になっている方もいるかもしれませんが、 2018年1月から「電子委任状の普及の促進に関する法律（電子委任状法）」が施行されました。

ある程度の規模以上の会社になってくると、契約や行政手続きなどで、社長さん自らそのような事務処理をすることは少ないと思いますが、ICカード使って電子署名するとか言うと本人しか暗証番号知らないはずなので困っちゃうんですよね。パソコン苦手な社長さんだと、ICカードと暗証番号毎渡しちゃって処理をお願いしたりしてね。
電子委任状fig1
そこで、社長さんが決めた代理の人に対して、電子委任状なるデータを与えることによって、そのような契約や申請手続きをオフィシャルに社長の代理でできるようにして、電子化を促進しようという法律なのだそうです。
電子委任状fig2
ICカードと暗証番号は、本人しか使えないように管理しなければならないというのが利用の原則なんですが、電子委任状によって、ちゃんと申請や契約する本人(=代理人)が管理するICカードができるようになるというのがミソかと思います。

そういえば先日、5月23日に日本ネットワークセキュリティ協会(JNSA)の電子署名WG春祭り「電子署名の世界(SIGN WORLD)」があり、弁護士の宮内宏先生が「個人の電子証明書と法人役職者の電子証明書　～意外と使える電子委任状法～」というタイトルでお話ししてくださいました。電子委任状については、一番良い解説スライドだと思うのでみなさん見て欲しいんですが、一番ストンと腑落ちしたのがこの電子証明書の比較に関するスライドで、マイナンバーカードも、認定認証業務の証明書も、特定認証業務の証明書も、商業登記の証明書しかり、日本の電子署名法で使える証明書は

基本的には会社の代表者(会長さん、社長さん)向けの証明書か、
個人の氏名と住所情報が入っている証明書

しか、使えないんですよね。ビジネスだと、部長さんの自宅住所なんかどうでもよくて、名前も場合によっては必要なく、むしろ肩書きなんかを書いていある方が重要ですよね。こりゃ、これまでの証明書はビジネスで使いにくいわけだなぁ、、、と。これとは違って、省庁の方の官職証明書は名前も、住所も入っていないくて、省庁の名前と役職で、使いやすくなってるのにね。

電子委任状の発行は、誰でも発行できるわけでなく、役所がするわけでもなく、電子委任状取扱業務の資格を持つ第三者のサービスがそれを行うことになるそうで、申請確認プロセスが同じなので、国内の証明書発行サービスが担うようになりそうとの事。電子委任状は普通のPDF(署名)文書のような形式もあるそうですが、X.509デジタル証明書による形式もあるそうです。(ココ、食いつき所ですよっ！！！)

デジタル証明書形式の電子委任状について、どのような項目を記載するか、いわゆる証明書プロファイルについては、総務省が発行している指針の解説書の25ページに記載例があります。この記載例を作る時に、総務省、日本電子認証局会議、日本ネットワークセキュリティ協会(JNSA) 電子署名WGが議論する会合がありまして、私もたまたま声をかけて頂けました。

この記載例には、幾つか課題もあるように思いますが、そこはスルーして、電子証明書方式の電子委任状のポイントは以下かと思います。

社長さんなど委任する側の人(委任者)と委任される人(受任者)の情報はsubjectAltName(SAN)に、 directoryNameとして記載される。
(SAN)のdirectoryNameの属性タイプは、 O、OU、CN、ST(stateOrProvince)、L(Locality)、T(title)、description、organizationIdentifierが使われる。
記載内容の詳細については、定められたプリフィクスも含めて、ディレクトリ属性値に設定している。例えば、社長さんなど組織の代表者には「組織代表者名：」というプリフィクスを使って「組織代表者名：山田太郎」のように設定している。

2. 証明書の識別名の構造(おさらい)

証明書の識別名は

属性1タイプ1=属性値1, 属性1タイプ2=属性値2, 属性1タイプ3=属性値3 ...

の構造になっています。属性タイプはオブジェクト識別子(OID)で、2.5.4.10みたいなやつ、属性値はASN.1の文字列タイプ(DirectoryStringType)になります。

3. デジタル証明書形式の電子委任状のサンプル発行

趣味でjsrsasign という、JavaScriptベースの暗号/PKIライブラリを公開していますが、今回の調査に合わせて、この電子委任状に必要な全属性タイプのサポートを追加しましたので、サンプルのCAページを使えば簡単に電子委任状もどきの証明書を生成し、証明書の表示確認などに使うことができます。
toolca

電子委任状では主体者別名(subjectAltName)に特徴があるので、確認ではこれのみを設定すればよく、タイプを「DN」にし、値に以下をペーストし、
toolca-san

/organizationIdentifier=JCN1111111111111/O=株式会社アイツー/description=組織所在地：東京都渋谷区神宮前３－３/description=組織代表者肩書き：代表取締役社長/description=組織代表者生年月日：1972/04/27/description=組織代表者名：鈴木花子/CN=山田太郎/T=購買部長/description=部門所在地：東京都新宿区西新宿５－５/description=代理権内容：日本国内の1億円以下の購買行為/description=代表権制限：1億円以下の発注購買

気になるならば、主体者名(subject)を以下に設定します。

/CN=Taro Yamada/ST=Tokyo/L=Shinjuku-ku Nishi-Shinjuku 5-5

「Issue Certificate(証明書発行)」ボタンを押せば、証明書データが生成れます。上記の入力では、主体者別名の属性タイプを選択できるものは一般的なOUではなく、表示テストのために珍しいdescriptionを使っています。また、解説書では主体者名の都道府県でS=TokyoのようにstateOrProvinceは"S="を使っていますが、OpenSSLやjsrsasignでは"ST="を使います。

上記の主体者別名の例を見やすいように改行を入れると以下のようになります。


/organizationIdentifier=JCN1111111111111
/O=株式会社アイツー
/description=組織所在地：東京都渋谷区神宮前３－３
/description=組織代表者肩書き：代表取締役社長
/description=組織代表者生年月日：1972/04/27
/description=組織代表者名：鈴木花子
/CN=山田太郎
/T=購買部長
/description=部門所在地：東京都新宿区西新宿５－５
/description=代理権内容：日本国内の1億円以下の購買行為
/description=代表権制限：1億円以下の発注購買

値は、自分の名前など、自由に変更して入力してもらえれば良いかと思います。

4. 汎用の証明書ビューアーで主体者別名の表示は問題ないか

電子委任状でデジタル署名された申請文書やデータの表示には、専用アプリケーションが提供される可能性も高いですが、PDFやWordなど汎用アプリケーションのデータとして交換されることもあるかと思います。OSやブラウザに搭載されている証明書ビューアーで電子委任状用のデジタル証明書を表示させた場合、特に主体者別名の表示に問題がないか、ちょっと見てみましょう。

4.1. Windowsの表示

Windowsでは以下のような表示になり概ね問題なさそうです。スクロールさせなきゃいけないので画像は少し貼り付けしてます。
attorney5_win1merge

4.2. macOSの表示

macOSのキーチェーンをつかって、上記の方法で作成した電子委任状証明書サンプルの主体者別名を表示させると以下のようになります。
cer-attorney-mac

4.3. Firefoxの表示

Firefoxでは以下のような表示になり概ね問題なさそうです。スクロールさせなきゃいけないので画像は少し貼り付けしてます。
attorney5-ff1merge

4.4. Adobe Acrobat Reader DCの表示

デジタル署名したPDFを作成し、Adobe Acrobat Reader DCで表示させると以下のようになります。こちらも概ね問題ありません。
attorney5-pdf1

4.5. Java JCE SUNプロバイダの表示

Java JCEで標準のSUNプロバイダを使って証明書を読み込みオブジェクトをprintln()で表示させた時の、主体者別名部分の表示は以下の通りです。こちらも特に問題はありません。


[4]: ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
  OID.2.5.4.13="代表権制限：1億円以下の発注購買 ",
  OID.2.5.4.13=代理権内容：日本国内の1億円以下の購買行為,
  OID.2.5.4.13=部門所在地：東京都新宿区西新宿５－５,
  T=購買部長,
  CN=山田太郎,
  OID.2.5.4.13=組織代表者名：鈴木花子,
  OID.2.5.4.13=組織代表者生年月日：1972/04/27,
  OID.2.5.4.13=組織代表者肩書き：代表取締役社長,
  OID.2.5.4.13=組織所在地：東京都渋谷区神宮前３－３,
  O=株式会社アイツー,
  OID.2.5.4.97=JCN1111111111111
]

4.6. Java JCE BouncyCastle BCプロバイダの表示

Java JCEで、フリーで有名な暗号ライブラリ BouncyCastleのBCプロバイダを使って証明書を読み込みオブジェクトをprintln()で表示させた時の、主体者別名部分の表示は以下の通りです。ASN.1ダンプとして表示されるだけですが、こちらも特に問題はありません。


Tagged [4]
  DER Sequence
    DER Set
      DER Sequence
        ObjectIdentifier(2.5.4.97)
        UTF8String(JCN1111111111111) 
    DER Set
      DER Sequence
        ObjectIdentifier(2.5.4.10)
        UTF8String(株式会社アイツー) 
    DER Set
      DER Sequence
        ObjectIdentifier(2.5.4.13)
        UTF8String(組織所在地：東京都渋谷区神宮前３－３) 
    DER Set
      DER Sequence
        ObjectIdentifier(2.5.4.13)
        UTF8String(組織代表者肩書き：代表取締役社長) 
    DER Set
      DER Sequence
        ObjectIdentifier(2.5.4.13)
        UTF8String(組織代表者生年月日：1972/04/27) 
    DER Set
      DER Sequence
        ObjectIdentifier(2.5.4.13)
        UTF8String(組織代表者名：鈴木花子) 
    DER Set
      DER Sequence
        ObjectIdentifier(2.5.4.3)
        UTF8String(山田太郎) 
    DER Set
      DER Sequence
        ObjectIdentifier(2.5.4.12)
        UTF8String(購買部長) 
    DER Set
      DER Sequence
        ObjectIdentifier(2.5.4.13)
        UTF8String(部門所在地：東京都新宿区西新宿５－５) 
    DER Set
      DER Sequence
        ObjectIdentifier(2.5.4.13)
        UTF8String(代理権内容：日本国内の1億円以下の購買行為) 
    DER Set
      DER Sequence
        ObjectIdentifier(2.5.4.13)
        UTF8String(代表権制限：1億円以下の発注購買 )

4.7. OpenSSLのx509 -textコマンドによる表示

OpenSSLの以下のコマンドで証明書情報を表示させた場合、

% openssl x509 -in aaa.cer -noout -text

結果は以下のようになります。


X509v3 Subject Alternative Name: 
  DirName:
    /2.5.4.97=JCN1111111111111
    /O=\\xE6\\xA0\\xAA\\xE5\\xBC\\x8F\\xE4\\xBC\\x9A\\xE7\\xA4\\xBE
       \\xE3\\x82\\xA2\\xE3\\x82\\xA4\\xE3\\x83\\x84\\xE3\\x83\\xBC

日本語部分は16進数表示されてしまいました。

4.8. 表示結果サマリ

調査した複数の汎用アプリケーションにおいて、証明書ビューアーで電子委任状のデジタル証明書を表示した結果のまとめは以下のようになりました。問題のある箇所を赤系のセルにしています。

	macOS	Windows	Firefox	Acrobat	Java SUN	Java BC	OpenSSL
読み込み	問題なし	問題なし	問題なし	問題なし	問題なし	問題なし	問題なし
表示崩れ	なし	なし	なし	なし	なし	なし	あり^(※1)
stateOrProvince(ST)属性表示	都道府県/州	S=^(※2)	ST=	st=	ST=	OIDまま	ST=
locality(L)属性表示	所在地	L=	L=	l=	L=	OIDまま	L=
organization(O)属性表示	組織	O=	O=	o=	O=	OIDまま	O=
organizationalUnit(OU)属性表示	部署	OU=	OU=	ou=	OU=	OIDまま	OU=
commonName(CN)属性表示	通称	CN=	CN=	cn=	CN=	OIDまま	CN=
description属性表示	説明	Description=	OIDまま	OIDまま	OIDまま	OIDまま	description=
title(T)属性表示	タイトル	T=	OIDまま	title=	T=	OIDまま	title=
organizationIdentifier属性表示	その他名前^(※9)	OIDまま^(※3)	OIDまま^(※4)	OIDまま^(※5)	OIDまま^(※6)	OIDまま^(※7)	OIDまま^(※8)
※1：OpenSSLコマンドではSANの全てのRDNは表示されない。日本語属性値が16進数表記で可読性がない。 ※2：WiindowsのみstateOrProvinceを"S="のように省略表記する。 ※3：WindowsのOID表記例「OID.2.5.4.97=値」 ※4：FirefoxのOID表記例「Object Identifier (2 5 4 13) = 値」 ※5：Adobe Acrobat Reader DCのOID表記例「2.5.4.13=値」 ※6：Java JCE SUNプロバイダーのOID表記例「OID.2.5.4.97=値」 ※7：Java JCE BCプロバイダーのOID表記例「DER Sequence ObjectIdentifier(2.5.4.13) UTF8String(値)」 ※8：OpenSSLのOID表記例「2.5.4.97=値」 ※9：macOSでは「その他名前」となり元OIDが何であったか情報が無くなる。

5. 電子委任状の識別名に関する考察

解説書に基いてサンプルの電子委任状を発行してみましたが、主体者名、主体者別名における課題について考察したいと思います。

5.1. 属性タイプについて

主体者名(subject)や主体者別名(subjectAltName)の識別名において、属性タイプはITU-T X.509としては何でも構わないが、標準的なものはITU-T X.520で定義されていて、 X.500 attirube typesの一覧はここでも見られます。ただ、ITU-T X.520では、X.500ディレクトリやLDAPで使用可能な属性タイプが全て含まれていて、例えばLDAPエントリとして、ユーザーのパスワードを格納する id-at-userPassword属性や、 CA証明書を格納する id-at-cACertificate 属性が定義されていたとしても、証明書でこの属性タイプを使うことは常識的にないでしょう。

そこで、インターネットで証明書を含むデータを交換する場合のために、 ITU-T X.509では、選択肢が広すぎて困っていたものを、利用可能なオプションを制限するためのプロファイルを RFC 5280として定義しています。

属性タイプに関する記述は、 4.1.2.4節発行者(Issuer)の節に書かれており、これと同じルールが主体者名、主体者別名にも適用されます。ルートしては、実装が処理または受理できる属性タイプについて述べられています。

C、O、OU、distinguishedNameQualifier、ST、CN、serialNumber、DCは受理できなければならない(MUST)。
L、T、surname、givenName、initials、pseudonym、generationQualifierは受理できるべきである(SHOULD)。

これらにない属性タイプが全く使われないわけではなく、例えばEV証明書でjurisdictionOfIncorporationC(登録管轄国)などの属性が使われているが、別のガイドや標準で規定しない限りは、上記以外の属性タイプを使って、プログラムが異常終了したり、エラーが発生したとしても文句は言えないわけです。相互運用性の問題が発生するので、RFC 5280で記載された属性タイプを使う方が安心かと思います。

5.2. organizationIdentifier属性タイプについて

organizationIdentifier属性タイプは、一般には企業や組織の番号を表すために用いられ、電子委任状では「国税庁が指定する法人番号」を記載するとしています。欧州の国民IDであるeIDAS規則の電子証明書でも、organizationIdentifierが使われており、徐々に浸透していくであろう属性ではありますが、

5.1節で述べた通り、RFC 5280には無い属性であり
4.8節の汎用証明書ビューアーでも表示されない属性タイプである
他のほとんどの属性では、「代理権内容：」のようなプリフィクスを使った表記にしている

などの事から、この属性だけを、無理に厳格にorganizationIdentifierを使う必要もなかったのではないかという気がします。

5.3. description属性タイプについて

電子委任状の主体者別名(subjectAltName)に記載される多くの属性は、 description(2.5.4.13) もしくは organizationName(2.5.4.10)のいずれかの属性タイプを用い、「代理権内容：」のようなプリフィックスを値に含めて記載することになっています。私は、様々な変わったX.509証明書を収集するのが趣味で、いろんな証明書をこれまで見てきましたが、識別名にdescription属性タイプを使用した証明書を見たことがありません。 descriptionは一般には、LDAPなどのディレクトリにおいて、あるエントリの補足情報や備考情報をメモ的に記載するために用いるのが一般的な使用法かと思います。相互運用性の観点から、あまり使用しない方が良かったのではないかと考えます。海外のPKI有識者も「日本はヘンな事やっちゃってるなぁ、、、」と考えるんじゃないかと思います。

5.4. OUを使う事の是非について

前述のように電子委任状の多くの属性では、その属性が本人に帰属するものか、組織に帰属するものかに関わらず、識別名の属性タイプがOUもしくはdescriptionのいずれかを使うことになっています。

一般に、OUは人事部、総務部、開発部、採用課といった部署名を表すための属性ですので、主体者に紐づく雑多な属性を記載するためのふさわしい属性タイプではありません。 OUを使った場合に、特に違和感がある電子委任状の属性は、以下のところかと思います。

委任者する側の法人の商業登記における本店所在地：(例)OU=組織所在地：本町３－３
委任者する側の法人代表者の肩書き：(例)OU=組織代表者肩書き：代表取締役社長
委任者する側の法人代表者名：(例)OU=組織代表者名：山田太郎
委任者する側が個人事業主の場合、その生年月日：(例)OU=組織代表者生年月日：1970/04/01

主体者の属性であれば、CN(commonName)を使うべきだったのではと思います。

5.5. ではどの属性タイプを使うのが良かったのか

以上で示してきたように、

description属性タイプの利用は、過去に使用例が見当たらず相互運用性の観点からも問題があるのではないか。
OU属性タイプの利用は本来、部署名を表す属性であるため適切ではないのではないか。

いずれも、多少なりとも問題があるように思います。主体者個人に帰属する属性はcommonName(CN)を使用するのが良かったのではないかと考えています。

EV証明書のように、個々の属性に対し、個別の属性タイプ、例えば「組織代表者生年月日」に対して「0.2.440.100145...23」を定義する方法もあったわけですが、そのような特殊な属性は汎用の証明書ビューワーでは表示されず視認性が悪いので、descriptionやOUを使い、「組織代表者生年月日：」のようなプリフィクスを用いて表記するのは、それほど悪くない方法だったのかなと考えています。

5.6. 似た日本語文字の問題

プリフィクスに「組織所在地：」のようにコロン「：」が使われていますが、解説書のページでは全角文字を使う事になっているようです。表記の揺らぎがないように、プリフィクスはUTF-8でどのようなバイト列(オクテット列)になるのか、明記しておくのが良いように思います。

また、ある文字と異なる文字、非常ににた形の文字がバイト列上(=Unicodeコードポイント上)別の文字にされてしまうことがあります。これを攻撃に使った場合ホモグラフ攻撃と呼ばれており、これを不正な証明書の発行に使われてしまうかもしれません。例えば、下の「日」文字は形が似ていますが別の文字です。

日野市 (日=U+65E5 正しい)
曰野市 (曰=U+66F0)

日本、中国、韓国で使われる文字でこのような似たような形で、異なる文字はあるようで、電子委任状においては解説書別表に

日本語で記載する場合、JIS第１水準・第２水準、補助漢字以外の文字は、代替文字に変換すること。このとき、代替文字仕様位置情報を証明書に付与することが望ましい。

と記載されており、上記の「日」も正しい「日」で統一されるように代替文字の変換情報が提供されるかもしれません。認証局は「JIS第１水準・第２水準、補助漢字」の範囲内であるかの確認が必要になりますね。

アパートやマンションの名称でローマ数字(IV等)が使われることがありますが、これは拡張漢字となるので注意が必要で、アルファベットで表記する必要があります。(「I」+「V」=「IV(二文字)」)

5.7. その他、記載例における細かい課題

解説書別表の記載例で、他に少し気になったところをまとめておきます。

CRLDistributionPointsの記載例がCRLを参照しておらずHTMLへのURLになっています。*.crl のように正しい拡張子にするのが良いかと思います。
組織代表者生年月日が「yyyy/mm/dd」となっているが、スラッシュ"/"はOpenSSLでのディレクトリ名表記と相性が悪いので無い方がよかったでしょう。

記載例は、どこに何が記載されているのかバラバラで見辛く、ちゃんと証明書プロファイルの構造で記載するのが良かったかなと思います。一部、アルゴリズムやシリアルなどプロファイルのみに記載すべき情報も記載されており、混乱しやすいように思います。以下のようなプロファイルの基本構造を示すとわかりやすかったかと思います。

フィールド/拡張名	内容
発行者名	電子委任状取扱サービス(=発行者)の英語名称
有効期間	委任される期間
主体者名	(部長さん等)受任者に関する主要な英語情報(氏名、所在地等)
発行者別名	電子委任状取扱サービス(=発行者)の日本語名称
主体者別名	・(部長さん等)受任者に関する日本語の情報・(社長さん等)委任者に関する日本語の情報・(部長さんの権限範囲等)代理権の情報

なんか、長々と取り留めもない話を書いちゃってごめんなさいね。

タグ：: #X.509証明書; #電子委任状; #総務省; #X.500ディレクトリ名; #主体者別名; #ディレクトリ属性

2017年06月09日23:22

カテゴリ: S/MIME; iPhone

GmailアカウントでS/MIME 署名/暗号メールを使う(その1 iOS標準メーラー編)

とある匿名の紳士がご厚意で、JCANのS/MIME証明書をわたしのGmailのアドレスに発行してくださり、iOSの標準メーラーのGmailアカウントからS/MIME署名/暗号メールが送れるようになりました。 docomoアカウントのメールはS/MIME使えないので渡りに船でした。(匿名の淑女からいただいていたS/MIME証明書はとっくに期限切れになり困っていました。)

「ブログに書いて下さいよ～～～」とその紳士に言われていたので、ちょっと書いてみたいと思います。

ここに書いてあるのは、JCAN証明書に限った話ではないので、iOS標準メーラーの任意のアカウント向けの証明書で使える話です。現時点で最新のiOS 10.3.2で試しました。

①まずは自分のS/MIME証明書のインストール

発行された証明書と秘密鍵のファイルである「*.p12」や「*.pfx」を添付ファイルにしてiOS標準メーラーのアカウントに送り、添付ファイルを開きます。
IMG_2600m
表示されている「インストール」のリンクをクリックし、iOSのロック解除パスコードを入力し、続いて *.p12 または *.pfx ファイルのパスワードを入力すれば証明書がインストールされます。
IMG_2601m

②次にGmailアカウントへのS/MIME証明書の設定

次に、iOSの標準メーラーからGmailのアカウントでS/MIME署名メールを送れるように、証明書(と鍵)の設定をします。「設定＞メール＞アカウント＞Gmail＞アカウント＞詳細」の一番下の方にS/MIMEの設定があります。S/MIMEをオンにして「署名」を開き、
IMG_2602m
「署名」をオンにして証明書を選択します。JCANからの証明書は「BN-英語氏名」となっていると思います。
IMG_2603m
この時点では「デフォルトで暗号化」は「いいえ」のままがいいです。

③iOS標準メーラーからS/MIME署名メールを送ってみる

iOS標準メーラーからGmailアカウントを選んで新規メールを送ってみましょう。
IMG_2604m
宛先が空欄の時には、錠前アイコンは「グレーで開いた」状態です。錠前が開いている状態は「相手に対して暗号化しませんよ」という意味です。また、グレーの錠前がある状態は「S/MIMEが利用可能」な状態にあるということです。次に、S/MIME署名メールを送りたい相手を選んでみましょう。
IMG_2606m
青い錠前が開いている状態は「メールの送信が可能で、相手にはS/MIME暗号化をしない」ということを意味しています。初期状態では相手の証明書をもらっていないので、暗号化できないのは当然です。ここで、無理やり「開いた青い錠前」をクリックしてみましょう。
IMG_2607m
相手の証明書を持っていないので、宛先が赤くなり「赤い錠前」のアイコンになり「暗号化できません」と表示されます。もう一度クリックして青に戻し、送信してみてください。

④送られてきた署名メールを受けてみる

iOSのメーラーから送られてきたメールをS/MIME対応のメーラー、例えばOutlookで見てみましょう。
zzz01m

⑤パソコンユーザのS/MIME署名メールから証明書を登録する

iPhoneから暗号メールまたは、署名暗号メールを送る場合には、iOSの標準メーラーのS/MIME関係の利用方法はいろいろイマイチな面が多いですが、署名メールに単純に返信する形では送れず、iPhoneでの相手証明書の事前登録が必要です。ここでは、その「相手の証明書」の登録方法を紹介します。

まず、送られてきた署名メールを開きます。
IMG_2606m
青い錠前をクリックしても、証明書が無いので赤くなるだけなので、もう一度タッチして青になるように戻します。
IMG_2607m
ちなみに、送られてきたメールが署名暗号メールだと、以下のようにバッジ(署名)と錠前(暗号化)の2つのアイコンつきます。
IMG_2609m
ちなみに、このメールをiPhoneの標準メーラーではなく、Gmailのウェブアプリで見てみると以下のようになっています。smime.p7mというファイルが添付されているだけで、暗号化されており、バイナリファイルを見ても内容はわからないでしょう。(そのうち、この中身のバイナリファイルの形式について述べることもあるかもしれません。) Googleにもメールの内容を知られることなく、安心ですね。
スクリーンショット 2017-06-09 22m
そこで、相手のアドレスをタッチすると、相手の連絡先が表示され、証明書に関する記述も書かれています。
IMG_2597m
「証明書を表示」のリンクをタッチすると、相手の証明書が表示されますので、「詳細」を表示などして、内容をざっと確認して「インストール」をタッチするとインストールされます。
IMG_2598m
IMG_2610m
以上で送信先の証明書を登録することができました。

⑥iPhoneからS/MIME署名暗号メールを送る

先ほど証明書を登録した人に新規にメールを送ってみます。宛先にメールアドレスを入力すると、最初は青い錠前は開いている状態です。
IMG_2613m
青い錠前をクリックすると、無事「暗号化済み」と表示されています。あとは送信ボタンを押すだけです。
IMG_2614m
パソコンのOutlookで受け取ってみると無事、署名暗号化メールを見ることができます。
zzz07m

おわりに

以上、JCANのS/MIME証明書をいただいたので、iPhone標準メーラーのGmailアカウントに設定し、署名暗号メールを送受信してみました。すこし、登録などまどろっこしい所もあるんですが、AndroidではまともなS/MIMEメーラーは無いので、 iPhoneの標準メーラーはS/MIMEを「ちゃんと」使えて大したもんだなぁ、、、と思います。今回の証明書はJCANさんのでしたが、英語の申請が気にならなければCOMODOからも無料のS/MIME証明書を発行してもらえます。よかったらトライしてみてください。

これで、~~Googleはユーザーのメールの内容を監視していたりするんでしょうが、~~安心してムフフなメールのやり取りを他の人には決してみられることなく送れるわけです。いや～～、素晴らしいですね。

Gmailアカウント用のS/MIME証明書を欲しかったのは、実は GoogleのG-Suite Enterpriseではサーバーに秘密鍵と証明書を設定してクラウド型でS/MIMEの署名暗号メールが使えるそうで、それを使ってみたかったというのがあります。最近、インシデント対応に追われてなかなか時間が取れないんですが、なんとか時間作って試したいなぁと思っています。ではでは。

タグ：: #SMIME; #iPhone; #iOS; #Gmail; #証明書; #署名メール; #暗号メール; #署名暗号メール; #JCAN; #COMODO

2017年05月02日22:14

カテゴリ: SSL証明書; PKI

Amazon AWSの認証局が少し怪しい件

Amazon AWSのELBとCloudFrontで使えるらしい、無料の証明書発行サービスで、AWS Certificate Manager(ACM)というのがあるそうです。([参考1])。ちょっと気になったきっかけはJavaからHTTPSで繋ぐと検証失敗するケースがあった

はてブを垂れ流すだけのフレンズ@matsuu
ん？これJRE同梱のルート証明書にACMのルート証明書が含まれてなかったってことか。どのバージョンから対応してるんだろ。決済連携などで決済会社の環境が古くてACMが使えないパターンありそう。 / “JavaクライアントからAWS…” https://t.co/pf9J6QRSTD
2017/04/30 11:57:07

というので、ちょっと見始めたらドツボにはまったので、少しメモを書き残しておこうかとおもいます。

ACMの証明書を使ったサイトにブラウザで繋いでみると、、、

Javaで繋がらないとなると、ルート証明書や中間CA証明書が入ってないんだろうと疑ってみるとおもいます。とりあえず、ブラウザで繋いだりしてみました。Windows 7のChromeやIEだとこんなパス。
view-ch-ie
Mac OS X(や多分iOSも)だとSafariでもChromeだとこんなパス。
safari-view
FirefoxだとOSによらず、WindowsでもMac OS Xでもこんなパス。
view-ff-chain
クライアント毎に使われている信頼するルート証明書が違うようです。 Starfieldルートになっているケースもありますね。調べてみると、AmazonはGoDaddyからStarfieldルート認証局を一つ買ったのだそうです。

ACMの証明書を使ったサイトにブラウザで繋いでみると、、、

Amazonの証明書発行サービスはAmazon Trust Servicesというのだそうで、証明書ポリシ、認証実施規程などの文書、ルート証明書、中間CA証明書などが置いてあるリポジトリはこちらにあるようです。

リポジトリをよく見てみると、クロス証明書(片方向相互認証証明書、中間CA証明書)のリストがあるんですが、ハッシュと証明書のリンクが張ってあるだけで、大した説明もなくえらく不親切なページですよね。認証局の構成がよくわからなかったので、これを元に図にしたのがコレです。(かなりの力作だとおもいます。)
ca-structure

なんかCAの鍵使いまわしてないですか？

このクロス証明書のリストで気になったのが、各Amazon Root 1～4に対して、origとそうじゃないやつ、Starfieldに関してはv2とそうじゃないやつがある所です。例えば、Amazon Root 1のorigとそうじゃないやつを比較してみると以下の3点が違うだけで、

シリアル番号が違う
notBeforeが違う(origが2015年10月で、orig無しが2015年5月)
authorityInfoAccess拡張のcaIssuerのURLが少し違う。 http://{crl,crt}.rootg2.amazontrust.com/rootg2.cer となっている。origがcrlで、origなしがcrt。

とほとんど同じで、caIssuerを直したいだけのつまらない理由のために、中間CA証明書を再発行したようです。これって中間CAの鍵を使いまわしてますよね。マズくないんですかね？さらに問題なのは、

どちらが正しい証明書なのかわからない。
ファイル名からはorigが古いように見えるが、 notBefore的には逆にorigが新しいようにも見える。
どちらか一方を失効しているわけでもなく、どちらも有効。
パス検証としてはどちらを使っても検証成功となるが、そんな事でいいのか？
将来、{crl,crt}.rootg2.amazontrust.comのいずれかを無くす計画があると思うが、それが明らかになっていない。

といった所です。ちなみに、caIssuerに記載されたURLは、今の所はどちらもアクセス可能なようです。両方にアクセスできるなら、なおさら中間CA証明書再発行の必要があったんですかねぇ？単に、DNSの別名、CNAMEレコードの設定だけの問題なんじゃないですかねぇ。また、本当はどちらに寄せたいと思っているのかも明らかにされてませんよねぇ。

同様に、Starfield Class 2 CAからStarfield Services Root CA G2に発行している中間CA証明書も怪しくて、シリアル番号とnetBeforeだけが違う証明書があります。どちらも失効していません。こんなことして大丈夫なんですかねぇ？最近、Certificate Transparency(CT)でSSLサーバー証明書全ての発行履歴残されており、 (私は最初はCTは嫌いだったのですが、) 認証局が問題あると、 (シマンテックのように、、、、) いろんな人が指摘してくれます。中間CA証明書の発行についても、CTログに残しておかないと、ヤバイ運用があるんじゃないかなぁ、、、、と思います。

Amazonの認証局はWebTrust認定もしており、Ernst Youngが監査しているそうですが、こんなんで本当に大丈夫なんですかね？

Java 8?のcacertsのaliasについて

Amazon AWSやACMとは全く無関係ですが、最近自分は、Javaはめっきり触らなくなってしまい、今回の件でかなり苦労しました。Javaの信頼する認証局のためのキーストアファイルであるjre/lib/security/cacertsファイルなんですが、中のファイルを取り出そうとすると、そんなファイルは無いと怒られてしまいました。よく見ると使ってみた新しい8u121では、aliasはこのようになっており、


% keytool -list -keystore jre/lib/security/cacerts
　　：中略
globalsigneccrootcar5 [jdk],2016/08/26, trustedCertEntry,
証明書のフィンガプリント(SHA1): 1F:24:C6:30:CD:A4:18:EF:20:69:FF:AD:4F:DD:5F:46:
3A:1B:69:AA
starfieldservicesrootg2ca [jdk],2016/08/26, trustedCertEntry,
証明書のフィンガプリント(SHA1): 92:5A:8F:8D:2C:6D:04:E0:66:5F:59:6A:FF:22:D8:63:
E8:25:6F:3F
ttelesecglobalrootclass2ca [jdk],2016/08/26, trustedCertEntry,
証明書のフィンガプリント(SHA1): 59:0D:2D:7D:88:4F:40:2E:61:7E:A5:62:32:17:65:CF:
17:D8:94:E9
addtrustqualifiedca [jdk],2016/08/26, trustedCertEntry,
証明書のフィンガプリント(SHA1): 4D:23:78:EC:91:95:39:B5:00:7F:75:8F:03:3B:21:1E:
C5:4D:8B:CF
　　：後略

例えば「starfieldservicesg2ca」だけではだめで、表示されている通り「starfieldservicesg2ca [JDK]」のようにちゃんと[JDK]までつけないといけなくなったのだそうです。知らなかったし、ハマりました。

GWなもんで、今日はこんなとこで。

参考リンク

A look at AWS Certificate Manager: ACMを使い始めるときに参考になる。ACMを使ったサイト。
Free SSL With Amazon’s AWS Certificate Manager (ACM): ACMを使い始めるときに参考になる。(その2)
ACM FAQ: 公式サイトのFAQ

タグ：: #Amazon; #AWS; #ACM; #AWS-Certificate-Manager; #Starfield; #ルート認証局; #認証局; #証明書チェーン

2017年03月07日23:20

カテゴリ: PDF署名; ルート認証局リスト

追悼 Adobe CDS

PDF署名の利用拡大につながると、密かに期待していた、とても先進的なサービスだったAdobe CDSが、いよいよサービスを終了し、AATL (Adobe Approved Trust List)に移行すると知りました。まぁ、移行とは言えず、いろいろなものを捨て去っているわけですが、、、かつて自分も人柱としてAdobe CDS対応の証明書とトークンを購入し、使ってみたりもし、幾つかブログで書かせてもらい、良いサービスだったのですがとても残念です。悲しすぎるので追悼記事のようなもの書いてみたいと思います。

Adobe CDSとは何か

Adobe Acrobat には誰が署名をしたか、それが改ざんされていないかを示すためのPDF署名機能があり、Adobe Acrobat ReaderにはPDF署名の検証機能がついています。PDF署名の運用を厳格化し、Adobe Acrobat Readerのデフォルトであっても、ちゃんと本人確認をした証明書とハードウェアデバイスをつかって署名したPDF署名が検証できるようにするサービスがAdobe CDSでした。Adobe CDSには

HSMを使った組織によるサーバー向けPDF署名
USBトークンを使った個人によるPDF署名

の2種類に対応していました。ただのPDF署名とはどう違うのか、比較表にまとめてみました。

一般的なPDF署名	Adobe CDS PDF署名
証明書発行の際、本人確認をしようがしまいが構わない	証明書発行の本人確認はかなり厳格。例えば、パスポートのコピー、メールアドレスの送付と電話による(英語での)本人の意思確認など
秘密鍵の管理はなんでもよい	秘密鍵は必ずサーバー型ならHSM、個人型ならUSBトークンに格納され、エクスポート不可。(スマートカード対応の認証ベンダーはなかったはず。)
証明書はデジタル署名が可能ならなんでも良い。例えば、SSLサーバー証明書と秘密鍵でもよい	Adobe CDS署名専用の証明書であり、拡張領域に専用の拡張がある。証明書ポリシもCDS対応のものでないとAdobe CDSに登録できるCAとはならない。
PAdESタイムスタンプつきPDF署名である必要はなく、普通のPDF署名でもよい	署名するとPAdES署名タイムスタンプ付きのPDF署名となる
タイムスタンプをつけようとする場合、日本では一般に別途、タイムスタンプ事業者との利用契約が必要	Adobe CDS対応の認証局では、証明書を購入すればタイムスタンプサービスが合わせて提供される。Adobe CDSでは、認証サービスごとに、どのタイムスタンプサービスを使用するかが、証明書拡張に記載されており、固定である。認証サービス自体がタイムスタンプサービスを提供しているケースが多い。
信頼するルート証明書のリストはAdobe独自のものだった。この度これが、Adobe Approved Trust List(AATL)というルート証明書プログラムとして定義され、現時点で58のルート証明書が登録されている。WindowsやMac OS Xなどのルート証明書の数は400程度とこれよりかなり多いが、OSの持つルート証明書はAcrobat Readerのデフォルトでは信頼しておらず、これを信頼するようにするには設定変更の必要がある。	Adobe CDSのルート認証局はAdobeのルート一つであり、中間認証局としてAdobe CDS対応の認証ベンダー6つ程度があり、そこからユーザ用の証明書が発行される。Adobe CDS用の専用の運用ポリシ(CP/CPS)で運用されている。どのようなOSのAcrobat ReaderでもOSのトラストリストに関係なく同じ検証結果となる

Adobe CDSサービスのポイントは以下のようになると思います。

確かに本人が署名したと見なせる印鑑で言えば実印レベルのPDF署名ができる
(最近いろんな認証局が問題起こしていますが)運用のしっかりしていない認証局が紛れ込む可能性が比較的低い(けど、この中にも問題起こしたところありましたよね)
Adobe CDS専用の証明書で署名する
電子署名では、証明書が有効だった時刻に署名されたことを示すために、タイムスタンプが必須とされるが、Adobe CDSではデフォルトで署名タイムスタンプつきPDF署名となる
USBトークンなどのハードウェアデバイスを持っているはずの本人署名できず、他人がなりすまして署名をされる可能性は極めて低い

Adobe CDSのナイスなところ

タイムスタンプ付きPDF署名をしようとした場合に、日本では一般に署名用のクライアント証明書と、タイムスタンプサービスの利用がそれぞれ必要になります。これって、それぞれお金がかかるし、煩わしいですよね。日本でタイムスタンプ付き署名が流行らない理由の一つなのではとも思ってたりもします。海外の署名用証明書発行サービスでは、タイムスタンプサービスとセットで提供するものが多いですし、Adobe CDSもセット提供で、とても使いやすいです。

コード署名用証明書なんかも、RFC 3161タイムスタンプとは違いますが、似たようなカウンタ署名によるタイムスタンプの仕組みがセットで提供されるので、デフォルトでコード署名にはタイムスタンプがつきます。

Adobe CDSの何がいけなかったのか

Adobe CDSを使っているかどうかで、PDF署名に対する信頼の度合いは全く異なると思うのですが、Acrobat Readerでは、普通のPDF署名とAdobe CDS PDF署名との違いはありません。違いもないのなら、高いお金を払ってまでAdobe CDSを使うメリットも薄いですよね。

また、認証局にとっても、独立した中間CAを運用しなければならない。特別な証明書プロファイルも必要で、認証局にとってもとても負担となるプログラムだったと思います。相当利用が伸びないとサービスを維持するのは難しいと思います。

Adobe CDSのようにUSBトークンを使ったり、マイナンバーカードのようにスマートカードを使ったり、ハードウェアデバイスを使用して、厳格な本人確認のもと発行された証明書に関しては、共通の専用の証明書拡張を持たせるようにし、普通の署名とは区別し、EV証明書の緑のアドレスバーのような表示上の区別をしないと、ハードウェアデバイスを使った署名がなかなか普及しないのかなとも思います。

最近では、クラウド上で秘密鍵の管理をし、リモートで署名を行うような運用形態も増えており、ハードデバイスを本人が管理して署名するというのは、だんだん時代にも合わなくなってきたのかもしれません。

おわりに

Adobe CDSは、維持費用も結構かかるので、結局持ち続けることはできませんでしたが、「実印レベルのちゃんとした」PDF署名であるAdobe CDSは、なくなって欲しくはなかったです。ホントさびしい。バイバイ Adobe CDS。

タグ：: #Adobe; #CDS; #タイムスタンプ; #ルート認証局リスト; #トラストリスト; #USBトークン; #PDF署名; #PDF; #Acrobat; #AdobeCDS

2017年02月23日20:00

カテゴリ: SSL証明書; PKI

HPKP(HTTP Public Key Pinning)公開鍵ピニングについて考える

もくじ
1. はじめに
 2. HPKPが生まれた背景
 3. HPKPの仕組み
 4. ピンの設定の考察
　 4.1. ピンの値の取得方法
　 4.2. 証明書チェーンに一致するピンの選択
　 4.3. 証明書更新とHPKPヘッダの設定変更の運用方法
　 4.4. バックアップピンという名前のイケてなさ
　 4.5. CA鍵のバックアップピンのオススメの値
　 4.6. 証明書チェーン中で複数ピンをつけても意味はない
　 4.7. 同じCA証明書にPinし続ける場合の課題
　 4.8. 2つのCA証明書にPinする場合の課題
　 4.9. max-ageのオススメ値を考える
 5. HPKPはどの程度使われているのか
 6. 今のHPKPの何がいけなかったのか
 7. おわりに
 8. (参考) HPKP関連の勉強になるリンク
 9. 追記
　 9.1. 追記(2017.02.26) HPKPのブラウザサポート状況
　 9.2. 追記(2017.02.26) smashingmagazine.comで発生したHPKP障害

1. はじめに

HPKPとはHTTP Public Key Pinningの略で、RFC 7469 Public Key Pinning Extension for HTTPで規定されており、ウェブサイトのオーナーが、ニセのサイトで意図しない証明書チェーンが使われないように保護するための仕組みです。

日本語解説は少ないですが、敬愛する jovi0608さんの記事やJxckさんの記事などでも解説されています。

私も3年ちょい前、IPAのガイドを書いていた前あたりから、HPKPの運用上の課題について、何かブログ等で書きたいと思っていたのですが、なんか日頃のヘンなことに忙殺されて、これまでまとめて書くことができませんでした。(なんか書こうと思ってたらjoviさんのが出ちゃって、まぁいいかと思っちゃったっていうのもありますw) IPAのガイドの時も書かせてもらおうとしたんですが、なんだか大人の事情で追加させてもらうことができませんでした。とほほ。

今回は、HPKPとは何かといった基本的なことは、他の方のブログに譲るとして、HPKPの現状やHPKPの運用上の課題についてフォーカスして書きたいと思っています。長くなりそうですが、ごめんなさいね。

結論から言えば、本番サイトで安易にHPKPを使うのはやめた方がいいと考えています。それは、HPKPの仕様自体が運用をしっかり考えて設計されておらず、一般的なサイトでは大したセキュリティ上の効果が無い割に、長期の運用でサービスを提供できなくなる期間が発生するリスクが高すぎるし、証明書のコストも余計にかかるからです。

おそらく、HPKPの運用について深く突っ込んでかいた、世界では初めての解説資料かなと思います。ご笑納くださいw

2. HPKPが生まれた背景

2011年頃から、認証局を対象にしたサイバー攻撃や、認証局の運用上の不備などで、攻撃に利用しやすいGoogleやFacebookといった有名サイト向けのワイルドカード証明書(*.google.com等)を取得されてしまうという事件が増えてきました。Googleを怒らせちゃったのは2011年のオランダの認証局DigiNotarが不正侵入を受け、*.google.comのワイルドカード証明書を発行され、イランのプロバイダの盗聴や攻撃に使われたという事件がありました。
hpkp-digi
このような事件を防ぐためには、ウェブサイトに対して、サイトオーナーの意図しない証明書が使われた場合に、警告を発する仕組みが必要です。そこで開発されたのが、HPKPです。HPKPでは、証明書チェーンの証明書公開鍵のハッシュの一致を確認することにより、ウェブサイトオーナーの意図した証明書かどうか検証することができます。
hpkp-hpkp1
joviさんのブログの1章で背景と仕組みをわかりやすく解説されているので、そちらもご覧頂ければと思います。

3. HPKPの仕組み

HPKPの実装方法には2つの方法があります。

1) Google、Facebook、Twitterなどの有名サイト向けの、Chrome、Firefoxなどブラウザに組み込まれたピンのリスト(Preloaded Known Pinned Host List)と照合する方法
2) HTTPSで通信する際に、サーバーからピン情報のHTTPヘッダを取得し、それをブラウザに保管しておき、以降の通信で照合に使う方法

1) の方法は、ブラウザを最新になっているならば何も設定しなくても、有名なサイトについてはHPKPを使って安全に接続することができます。今回の記事で議論したいのは2)のサイトオーナーが設定する場合についてなので、2)の仕組みについて説明します。
hpkp-sethead

ウェブサーバーに不正な証明書チェーンに接続させないためのHPKP HTTPヘッダを設定するのですが、これはウェブサーバーのHTTPS設定で使用するルート証明書からSSLサーバー証明書までの証明書チェーンを元に設定します。HTTPヘッダとその値の書式は以下のようになっています。


Public-Key-Pins: \
　　pin-sha256="チェーン中の公開鍵のどれかのSHA256ハッシュ値のBase64"; \
　　pin-sha256="チェーン中の公開鍵のどれにも一致しないSHA256ハッシュ値のBase64"; \
　　[pin-sha256="その他ハッシュ値1"; ...; ] \
　　max-age=ブラウザにこのHPKPヘッダが保管される秒数; \
　　[includeSubDomain;] \　　　　サブドメイン(example.comならsub.example.com)もHPKPの対象にするか
　　[report-uri="JSON形式のエラーレポートがPOSTされるURL"; ]

[...]はオプション

pin-sha256は証明書チェーンを元に設定しますが、その設定方法や考察については後で述べます。
max-ageの保存期間はRFCの4.1節で考察しており60日(=5184000秒)が良いのでは？としていますが、その考察も後で述べさせて下さい。
includeSubDmainは、サブドメインまで含めるか、例えば example.com にHPKPを設定したら、sub1.example.comも、www1.sub2.example.comもHPKPの対象にするというフラグです。現時点で持っていないなら安易に設定しない方が良いように思います。
HPKPは、CSPなどと同様ににブラウザ側で検証するので、サーバー側にはエラー原因が把握できず困ることがあります。report-uriを使えば、ブラウザでHPKPのエラーが発生した際に、指定したURLのウェブサーバーにJSON形式のエラーレポートをPOSTすることで送信しますので、設定上の問題を知るのに役立つかもしれません。Jxckさんのブログで設定を試してみたという詳しい報告がされているのでご覧になると良いでしょう。ブログでも書かれていますが、レポートが出力される条件がよくわからず、ブラウザやバージョンにも依存するようで、私もレポート生成がうまくできていません。

また、HTTPヘッダについて "Public-Key-Pins" ではなく、"Public-Key-Pins-Report-Only" と設定すれば、ブラウザではエラーを発生させることなく、エラーレポートの収集はできますので、テストの際にこれを使うと良いでしょう。

4. ピンの設定の考察

pin-sha256属性を使ってピンを設定することにより、サーバーオーナーが意図しない証明書が使われることを防ぐことができます。ピンの値は、証明書チェーンの証明書の何れかの証明書に一致するものを最低一つ、どれにも一致しないものを最低一つの計2つ以上により構成されます。
hpkp-intersect

4.1. ピンの値の取得方法

さて、一番簡単なハッシュ値の取得方法ですが、すでにウェブサーバーのHTTPS設定が完了しているならば、Scott Helme氏のHPKPハッシュの所得ページを利用するのが良いです。自分のでも他人のでもHTTPSサイトのURLを入力すれば、証明書チェーンの各証明書のピンのハッシュ値を計算してくれます。

SSLサーバー証明書から順にルート証明書まで、ピンのハッシュ値が

pin-sha256="hUIG87ch71EZQYhZBEkq2VKBLjhussUw7nR8wyuY7rY="

のように表示されますので、どのピンを使うのかを決めてHTTPヘッダに設定するだけです。

一つのピンのハッシュ値の計算ですが、証明書からでも、証明書発行要求(CSR/PKCS#10)でも、秘密鍵と鍵アルゴリズムによっては鍵パラメーターから抽出されたPKCS#8公開鍵からでもハッシュ値を計算することができます。ただ、いろんな人のブログでは、わざわざCSRを作ってからハッシュ値を計算しているようですが、特に証明書のまだ無いバックアップピンの場合には、そんなことをしなくとも、公開鍵からハッシュ計算するのが良いように思います。先ほどと同様に、Scott Helme氏のツールでPEM形式のPKCS#8公開鍵、CSR、X.509証明書を入力すれば、ピンのハッシュ値を計算してくれるページがあるので、これを使うのが簡単です。

手作業でピンを取得する場合には、以下を実施すれば公開鍵のSHA256ハッシュであるピンの値が取得できます。他の解説記事では、base64コマンドを使ったり、CSRをいちいち生成するのを強制させたりしているようですが、ここで紹介する方法はOpenSSLコマンドしか使わず、いろいろなケースに対応して、ピンの取得ができるように、例を示しておきました。


X.509証明書からsubjectPublicKeyInfoフィールドにあるPKCS#8公開鍵のピンの入手
% openssl x509 -in PEM証明書 -pubkey -noout | openssl rsa -pubin -outform DER |  \
    openssl dgst -sha256 -binary | openssl enc -base64
te4kc4F/5BhtIosKLOS9sy049x7a/LQHNRRG1WHfvyU=

CSRからsubjectPKInfoフィールドにあるPKCS#8公開鍵のピンの入手
% openssl req -in PEMCSRファイル -pubkey -noout | openssl rsa -pubin -outform DER |  \
    openssl dgst -sha256 -binary | openssl enc -base64
te4kc4F/5BhtIosKLOS9sy049x7a/LQHNRRG1WHfvyU=

PKCS#8秘密鍵からピンの入手
% openssl rsa -in PKCS#8秘密鍵 -pubout -outform DER |  \
    openssl dgst -sha256 -binary |  openssl enc -base64
te4kc4F/5BhtIosKLOS9sy049x7a/LQHNRRG1WHfvyU=

PKCS#8公開鍵からピンの入手
% openssl rsa -pubin -in PKCS#8公開鍵 -pubout -outform DER |  \
    openssl dgst -sha256 -binary | openssl enc -base64
te4kc4F/5BhtIosKLOS9sy049x7a/LQHNRRG1WHfvyU=

得られた値を
pin-sha256="te4kc4F/5BhtIosKLOS9sy049x7a/LQHNRRG1WHfvyU="
のようにヘッダに設定する。

値を取得したら、ウェブサーバーのHTTPヘッダに設定します。例えば、Apache HTTP Serverの場合には、以下のように設定します。


<VirtualHost _default_:443>
...
Header set Public-Key-Pins \
  "pin-sha256=\"MRnxhYBVCMAxZHwalTJ7ZVl6P2005lll4ttWr+RN1Ro=\"; \
   pin-sha256=\"633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q=\"; \
   max-age=2592000; \
   report-uri=\"https://report.example.com\""
...
読みやすさのためにバックスラッシュと改行を入れています。2592000秒は30日です。

4.2. 証明書チェーンに一致するピンの選択

HPKPでは、証明書チェーンに一致するピンを1つ以上設定する必要があります。本節では、次の2つに分けて考察してみたいと思います。

1) 証明書チェーン中のどれか一つのみを選択する場合の比較検討
2) 証明書チェーン中の2つ以上、または全部を選択する場合の考察

4.2. 証明書チェーンに一致するピンの選択

証明書チェーンで、SSLサーバー証明書、中間CA証明書、ルート証明書のような3段の証明書になっている場合、不正な意図しない証明書チェーンになっていないかどうか検証するために、どれか一つのピンを選ぶとすれば、どれを選べば良いでしょうか。これら3つのケースで、それぞれ長所、短所があるので、考察してみたいと思います。 SSLサーバー証明書については、数年後証明書更新の際に使用する鍵ペアがあらかじめ決まっている場合(=鍵事前生成)、決まっていない場合(=鍵事前生成なし)のケースに分けて考察します。

証明書	長所	短所	安全性	運用負担
①ルートCA証明書	有効期間が長いためピン変更の頻度が少なくて済む。おそらく10年程度は変更不要ブラウザ組み込みのプリロードピンではルート証明書を使用	鍵更新後の公開鍵は事前にはわからずバックアップピンは使えない新しいSSLサーバー証明書を購入した場合に、同じルート認証局とは限らず、その際はピンの移行が必要ルート証明書配下の証明書の数は非常に多く、その認証局が不正な証明書を発行された場合に、攻撃を防げないリスクは高い。例えば、シマンテック社がGoogleに許可なくGoogleの証明書を発行する事件があった。証明書更新でルートCAが変更になる可能性は低いが、変更になった場合には、max-ageに配慮した面倒な移行が必要で運用負荷が高い	低	高
②中間CA証明書	有効期間がやや長いためピン変更の頻度が若干少なくて済む。おそらく5年程度は変更不要安全性と運用負担の面でバランスが取れているか？ピンする中間CAの公開鍵に変更がなかった場合のSSLサーバー証明書の更新は比較的楽	ピンしている中間CAの公開鍵が、次回のSSLサーバー証明書更新時に同じであるという保証はない。 SSLサーバー証明書の更新時に、中間CA証明書が変更になるリスクがあるが、それが事前周知されないために、SSL接続不具合によるサービス停止リスクが高い中間CA証明書が変更になった場合の移行に係る運用負担は、回数も、作業負荷も非常に高い同じ中間CAから、不正に同じドメインに対する証明書が発行された場合にも検証有効となってしまうリスクがある。①よりはリスクは低いが、③④よりは高い証明書更新で中間CAが変更になる可能性はある程度あり、①よりは確率が高い。変更になった場合には、max-ageに配慮した面倒な移行が必要で運用負荷が高い	中	中
③SSLサーバー証明書(鍵事前生成)	SSLサーバー証明書の更新時に、ピンした公開鍵のマッチング設定に失敗する可能性が低く、HPKP設定不備によるサービス停止のリスクは最も低い HPKPのRFCでは、(さらっと簡単にできると取れるような記述がされており)推奨されているように取れる方法不正証明書チェーンが使われるリスクは、(秘密鍵漏洩のリスクを除けば)④と同程度に、①②より高い証明書更新の前後で、変更されるピンがあらかじめわかっているので、(max-age内に再度証明書更新をすることをしなければ)max-ageをあまり気にせずに証明書の更新ができる	SSLサーバー証明書の更新時に、鍵ペアの事前生成が可能なのは、OpenSSL等により手作業で鍵ペア生成した場合のみであり、証明書の発行時に、CSRを自前で生成する必要がなく、ブラウザのコンポーネントで自動的に鍵ペア生成するような証明書発行サービスの場合には、本方式は使えない Let's Encryptは使えず、SSLサーバー証明書自動更新に係る運用負担の軽減は見込めない鍵ペアは一般に、証明書の更新時に行われるものだが、それを2年程度前に実施することになる。事前生成しておくと、その分、SSLサーバー証明書の秘密鍵が漏洩するリスクは高く、機密保管の運用負担は大きい証明書の更新時には、それなりに設定変更に気を使う必要がある。また、その回数も2年弱程度おきであり、運用負担は比較的高い	中	中
④SSLサーバー証明書(鍵事前生成なし)	全てを自己制御でき、設定不備によるサービス停止リスクは③と同程度に高い ③に比べてSSLサーバー証明書の秘密鍵が漏洩するリスクも低い不正証明書チェーンが使われるリスクは、(秘密鍵漏洩のリスクを除けば)④と同程度に、①②より高い	SSLサーバー証明書を使える期間が、必ず (max-age + α)×2 分だけ減る。2年物証明書の場合、max-ageを2ヶ月とした場合、テストや余裕も含め4～5ヶ月程度は短くなることになり、証明書の費用負担が増える証明書更新の前後で証明書の有効期間をmax-age+αでオーバーラップさせれば、必ずmax-ageに配慮しながらピンの変更を行うことになる。運用の負担はあるが、ピンが変更になるか認証局次第でどうなるかわからない①②に比べて、必ずmax-ageに配慮した、証明書更新、HPKP設定変更のスケジュールが組めるので、定型運用にできるため運用の心理的負担は①②よりは若干少ない	高	中

では、①～④では、何を選択するかですが、ブラウザ組み込みのピンが使えない一般サイトの場合は、 ②～③のいずれかが妥当だと思いますが、どれも運用の負担や、サービス提供不能になるリスクがあり、個人がテスト目的で設定する場合は何でも良いとして、自分が商用サイトの運用を任されているならば、もっとも懸念すべきは長期間サービス提供不能になりクレームが起きることなので、 HPKPは使わないという判断をすると思います。

4.3. 証明書更新とHPKPヘッダの設定変更の運用方法

4.2節では、証明書チェーンのどこにピンを設定するかで、どのような違いがあるのかについて考察しました。

本節では、4.2節の考察を受けて、設定不具合によるサービス利用不能を防ぎながら、HPKPを使ったサイトの証明書更新、HPKPヘッダの変更を、どのように運用すればよいのかについて考察します。

HPKPを使った場合の証明書更新の運用の仕方は4つのケースにわけることができます。

a)証明書更新のmax-ageより前に確認し、ピンを行っている鍵に変更がない場合
b)証明書更新のmax-ageより前に証明書更新の前後でピンを行う公開鍵が何に変更されるかわかっている場合
c)証明書更新のmax-ageより前に証明書更新の前後でピンを行う公開鍵が何に変更されるかわからない、もしくは変更が明らかだが、更新の前後の証明書の有効期間をmax-age + αオーバーラップできる場合
d)証明書更新のmax-ageより前に証明書更新の前後でピンを行う公開鍵が何に変更されるかわからない、もしくは変更が明らかだが、更新の前後の証明書の有効期間をmax-age + αオーバーラップできない場合

このような説明では、具体的なイメージがわかないと思いますので、証明書チェーン中の証明書に分けて具体例を示してみましょう。

a-1) ルート証明書や中間CA証明書にピンを設定しており、顧客サポートに問合せたら、次回、max-age後の証明書更新では、使用するルート証明書、中間CA証明書には変更がないことがわかった場合。(顧客サポートに嘘をつかれたら、一部ユーザに2ヶ月(=max-age)サービス障害になるリスクあり。)
b-1) ルート証明書や中間CA証明書にピンを設定しており、顧客サポートに問合せたら、次回、max-age後の証明書更新では、使用するルート証明書、中間CA証明書がどれに変更されるか教えてもらえた場合。もしくはサポートページなどで告知されている場合。証明書発行サービスの変更、EVへの変更なども同様。
b-2) SSLサーバー証明書にピンを設定しており、OpenSSL等で次回の証明書更新で使用する鍵ペアがすでに事前生成され、保管されている場合
c-1) ルート証明書や中間CA証明書にピンを設定しているが、次回証明書更新後のルート証明書、中間CA証明書の変更について、顧客サポートからの回答が得られず、変更されるかどうか判断がつかないため、仕方なく、証明書更新をmax-age + α前に実施して有効期間を重ねるよう事前証明書発行したら、やはりルート証明書、中間CA証明書は変更になっていた場合(変更がなければa-1のケースとなる。)
c-2) SSLサーバー証明書にピンを設定しているが、OpenSSLを使わず、ブラウザの機能で鍵ペア生成するタイプの認証局であるため、事前に更新後の公開鍵はわからず、証明書更新をmax-age + α前に実施して有効期間を重ねるよう事前証明書発行できる場合
c-3) SSLサーバー証明書にピンを設定しているが、HSM機能を使うSSLアクセラレーターを使っており、事前に更新後の公開鍵はわからず、証明書更新をmax-age + α前に実施して有効期間を重ねるよう事前証明書発行できる場合。移行の図はc-2と同じになります
d-1) SSLサーバー証明書にピンを設定しているが、Let's Encryptや一部の認証局のように、証明書更新後、前の証明書は即時に失効処理がされ、max-age + αの期間の有効期間のオーバーラップができない場合

自分の運用がどのケースにあてはまるか、上記の説明でわかったでしょうか。さて、a～dのケースで、どのように対応するかを以下に示します。

aの対応) 証明書更新に際し、ウェブサーバーのHPKPヘッダの設定は変更しなくてよい
bの対応) max-ageをはあまり気にせず、証明書更新後の、ウェブサーバーの証明書設定、HPKPヘッダを設定変更してよい
cの対応) もっとも神経を遣う、max-ageに配慮した、証明書更新、HPKPヘッダ設定が必要。証明書の更新の前後で、有効期間のオーバーラップが必要
dの対応) このケースではHPKPは使えない。他の証明書、証明書発行サービスへのピン設定の変更を検討する必要がある。使っても、一部ユーザにサービス接続不能障害がmax-age程度発生する。

どんな証明書更新、HPKPヘッダ設定の移行を行うにしても、証明書の有効期限、max-age、秘密鍵の保管など、様々なことに気を遣いながら、移行計画を立て、移行しないとならず、きちんと考えないと長期のサービス障害発生するという運用上の負担やリスクは大きいと思います。

4.4. バックアップピンという命名のいけてなさ

先に述べたように、何か一つ、証明書チェーンとはマッチしないピンを必ず含めなければいけません。SSLサーバー証明書にピンをする場合は、現在使っているSSLサーバー証明書の秘密鍵に対して、将来、証明書更新で使う予定の秘密鍵も事前に生成しておけるなら、その公開鍵をバックアップピンとして設定しておけば、まさしくバックアップとして使用でき、(後述の問題ありありですが)スムースな証明書とピンの移行が可能です。

しかしながら、秘密鍵を移行先のバックアップとして事前生成しておき、これが利用できるというケースはレアケースです。例えば以下の一般に起こりうるケースでは、証明書更新の際に、その事前生成した秘密鍵を使用することはできません。

CA証明書のバックアップPin: 認証局が行う証明書更新もしくは鍵更新において、事前に移行先の秘密鍵が存在するということもありませんし、移行先の公開鍵のPinをユーザに公開してくれる認証局もありません。
HSMを使っている場合のバックアップ: 認証局やSSLアクセラレーターを使っているケースでは、秘密鍵を取り出し不可能なハードウェアセキュリティモジュール(HSM)で管理するのが一般的です。HSMを使用した鍵更新、証明書更新では、事前に秘密鍵を幾つか生成しておき、更新時にそれを指定して更新に使用するということができません。更新時には、新たに鍵ペアを生成して、これを使用します。このために、認証局ではバックアップPinを公開することができないのです。
ウェブ画面で鍵ペア生成してSSLサーバー証明書発行する認証局の場合: 認証局によっては、ウェブブラウザの機能を使用して、ボタンを押せば自動で鍵ペア生成を行い、これを用いて証明書を発行し、新しい証明書を格納するものがあります。そのような認証局では、事前に生成しておいた鍵を発行時に使用するということができません。
Let's Encryptを使う場合: 無料で世界一の発行数を誇る証明書発行サービスであるLet's Encryptでは、証明書の発行プロセスがスクリプトにより自動化されていますが、これも証明書の更新時には自動で鍵ペア生成されるので、事前に生成していた鍵ペアを使用することができません。

本当の意味での「バックアップPin」が使えるのは、以下の場合にのみ可能であるということです。

SSLサーバー証明書に対してPinをする場合で、かつ、
OpenSSLなどのコマンドで鍵ペア生成し、マニュアルで証明書発行要求を生成して、証明書発行してもらえる認証局を使用する場合

従って、証明書チェーンにマッチしないものを、「バックアップPin」と呼ぶのは、上述のほとんどのケースで適切でないので、名称には問題があると考えています。

4.5. CA鍵のバックアップピンのオススメの値

ルート証明書や中間CA証明書にピンを設定する場合、一致しないピンは、将来の更新先がわからない場合には何でもよく、さらには、本物の公開鍵のハッシュである必要もありません。 SHA256なので、単に32バイトの値であれば何でも良いわけです。

ただ、HPKPヘッダで一見して一致しないピンだとわかったほうが、誤って削除するなどの運用ミスを防ぐ意味でも良いと考えており、そこで、オススメしたいのが、以下の値です。


pin-sha256="AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=";
これは、16進数で
0000000000000000000000000000000000000000000000000000000000000000 (32バイト)

となります。流行るといいなと思っていますw

4.6. 証明書チェーン中で複数ピンをつけても意味はない

これまで、証明書チェーンと一致するピンの数は1つを前提に議論してきましたが、これを複数、例えば、ルート証明書と、中間CA証明書と、SSLサーバー証明書のピンを一致させた場合には、どうなるのかを考察したいと思います。

まず、SSLサーバー証明書にピンを打って、次に中間CA証明書、次にルート証明書のピンを追加していくことを考えてましょう。同じ鍵ペアを複数の認証局からのサーバー証明書発行で使用しないという、当たり前の事を前提とします。 SSLサーバー証明書にピンを打つ事が最も、範囲が限定的でニセHTTPSに対する最も強い対策であると、4.2節③④で述べました。

そこに中間CA証明書の一致するピンを足してみたらどうでしょうか。ピンで特定する証明書の範囲は全く変わりませので、中間CA証明書のピンを足すことで、ニセHTTPSサイト作りが難しくなったりはせず、セキュリティの強度も上がりません。また、運用面では、ピンの一致の配慮がピン一つと比べて難しく、また、ウェブサイトオーナーだけで管理できない範囲となるので証明書やピンヘッダ変更の運用は格段に複雑で面倒になります。これに対し、ルート証明書のピンを加えた場合でも全く同じことです。セキュリティ強度は上がらず、移行の運用は複雑になるのです。
hpkp-multipin

従って、証明書チェーン中で複数のピンをつけても意味がなく、かえって運用が複雑になるだけなので、止めたほうがよいということが言えます。

4.7. 同じCA証明書にPinし続ける場合の課題

今後当面は、同じルート認証局、中間認証局から発行してもらう場合に、その認証局の証明書の公開鍵にPinすることができます。その場合には、バックアップPinは、認証局から移行先のPinを教えてもらえるわけではないので、なんでも適当な値で良いことになります。公開鍵のハッシュである必要もなく、32バイトの値のBase64表現であれば(衝突しなければ)何でも良いことになります。

ただし、「当面は」と書きましたが、SSLサーバー証明書を発行する使用していた中間認証局が、次の証明書発行時にも同じ中間認証局、同じ公開鍵であるという保証がありません。以下の理由により、同じ中間CA証明書が使われない可能性があります。

中間CA証明書の有効期限は、5年から10年程度です。その有効期限の半分程度から、最長でも2、3年を残して、その中間認証局からは証明書が発行されなくなり、利用者は別のCAから証明書を発行してもらうようになります。
証明書の発行数枚数が多くなると、それだけ、証明書失効リスト(CRL)のサイズも大きくなりますので、一つの中間CAから発行枚数を制限して、以降の証明書発行は、新しい中間CAから発行させるケースがあります。
近年、認証局の運用上の不備、サイバー攻撃などから証明書発行サービス全体や、特定の中間CAが運用停止、サービス終了になることがあります。

このような場合には、同じ中間CAのPinを使うことができません。

有効なPinを設定した同じルートCAもしくは中間CAから、新しい証明書が発行してもらえないとわかった際に、別の証明書の移行は、すぐにはできず、max-ageで指定した期間、一般には1ヶ月から1年程度は、証明書の入れ替えができません。最悪の場合、その期間、有効なHTTPS通信ができないという事もありえます。

このような影響を、軽減する方法が無いわけではありません。証明書を更新すると判断し、同じ中間CAから証明書が発行できないとわかった時点Aで、そこからmax-age経過した時点Bを記録しておき、新しい証明書を取得します。(が使いません。)。バックアップPinとして、その新しい証明書の別の中間CA証明書の公開鍵のPinをウェブサーバーのヘッダに設定します。時点Bになって、初めて新しい証明書への入れ替えを実施します。この事から、max-ageを1年等、長くとれば偽サイトの防止には役立ちますが、今述べたような証明書更新のリスクもあり、半月から1ヶ月程度に設定するのが妥当なように思います。

4.8. 2つのCA証明書にPinする場合の課題

SSLサーバー証明書の更新の際に、2つの証明書発行サービス、例えばSymantecとGlobalSignを交互に乗り換えるとして、これら2つの中間CA証明書のPinをヘッダに設定し、使用してないない方をバックアップPinとするのは、なかなか賢い方法だと思います。
hpkp-two

しかしながら、前述の理由により、Symantecの次に発行してもらおうと予定していたGlobalSignの中間CA証明書のPinが使えないケースがあります。

以上のように、CA証明書にPinを打つケースでは、証明書発行サービスの気まぐれにビクビクしながら、ウェブサーバーのHPKPを運用するのはとても面倒だと思いませんか? それなら、まだ、自分でコントロールできるSSLサーバー証明書にPinを打つ方が、面倒でも良いような気もしてきます。

4.9. max-ageのオススメ値を考える

RFC 7469 4.1節のセキュリティ考察において、max-ageの最大値について以下のように記載されており、「60日がバランスの取れた値かもね」と言っています。

RFC 7469 4.1. Maximum max-age より
However, a value on the order of 60 days (5,184,000 seconds) may be considered a balance between the two competing security concerns.

ただ、5章のScott Helme氏のHPKP対応ドメインリストに基づいた私の調査では、まともな運用をしている設定の中では、 30日が26%、次いで60日が19%と多いです。

max-ageの値が長すぎると、

設定ミスによる障害発生時に長期間接続できないユーザが出てしまう
有効期間のオーバーラップが必要な場合、実質的な証明書有効期間が目減りして運用コストに影響する

というリスクについて、4.2節で説明させて頂きましたが、逆に、max-ageが短すぎるとどうなるのでしょうか？

簡単には、ニセのHTTPSサイトに乗っ取られる可能性が高くなるという事かと思います。本物サイトのmax-ageが短くて、有効期限が切れたタイミングで、ドメイン乗取り等の被害にあって偽サイトが作られ、そこで1年等長いmax-ageのHPKPヘッダ対応のニセサイトが作られたとすると、一度そのようになれば、当面1年間は、ニセサイトにしか繋げないようなユーザが発生することがあります。
hpkp-maxage
max-ageが短いと、それだけ攻撃のチャンスは増えるため、max-ageはある程度長くしておく必要があります。

様々な情報ソースから、ニセサイトを作られていたと気づくまでに、それほど時間はかからないと思います。数日から1週間もあれば問題に気づくと思います。半月や1ヶ月も気づかないままいる事はないでしょう。「ニセHTTPSサイト問題に気づくまでに遅くともどれくらいかかるか」によって max-ageの最小値を決めるのがよいと思います。

従って、攻撃と可用性のリスクのトレードオフで、私はmax-ageを15日か30日程度に設定するのが良いように思っています。

5. HPKPはどの程度使われているのか

2016年3月のNetcraft社のSSL利用調査によれば、世界でわずか0.09%の4100サイト以下ぐらいしか、HPKPを設定しておらず、設定の誤りも多いそうで、正しく設定できているのは、そのうち3000サイト程度なのだそうです。

また、CSP(Content Security Policy)やHPKPに詳しく、HPKPの検証やレポート先サイトを運営しているScott Helme氏のブログによれば、Alexa上位100万のサイトのうちHPKPを設定しているのは、わずか375サイトであったという報告もあります。

Scott Helme氏は、調査の際のデータも公開しており、2016年8月時点でのHPKP対応サイトのドメイン名リスト448件があったので、それをベースに2017年2月現在でもHPKPヘッダを返すサイト283件に対して少し調査してみました。

	まず、HPKPヘッダとして正しいフォーマットになっているか、また、仕様上PINのハッシュ値は2つ以上必要ですが、2つ以上あるかという観点で、ヘッダがどの程度正しいかを調べました。16%は設定が正しくないことがわかりました。間違っているものの中には、pin-sha256属性が無い、pin-sha256の値が不適切、pin-sha256属性が一つしかない、など様々です。例えばこんなものがありました。 `...` `pin-sha256="base64+info1="; max-age=3`
	次に、HPKPヘッダのPINのハッシュ値の個数です。一般にはPINのハッシュ値は2つで十分で、2つとなっているサイトが多く占めますが、1個しかない誤ったサイトや、3つ以上を設定しているサイトも相当数あります。15個設定しているという猛者もありました。
	HPKPで有効な公開鍵ハッシュの保存期間を定めているのが、max-ageの値です。RFCでは、60日を推奨しているようですが、実際には30日を設定するサイトが多いとわかります。また、テスト中なのか1日以下にしているサイトも相当数あります。短いとサイトを乗っ取られる可能性が高まりますし、長すぎると設定に失敗した場合その期間接続不能になってしまいます。1年などと設定すると、設定失敗していたら1年間接続できないユーザーが出てクレーム確実なのに恐ろしいですね。
	report-uriを設定すると、対応ブラウザならば、HPKPのエラーの際に指定したURLにレポートを送ることができます。Jxckさんのサイトでは設定されているそうですが、まだまだ設定しているサイトは少なそうです。
	HPKPヘッダの値には、includeSubDomainというプロパティをつけることができます。これをつけるとexample.comにHPKPを設定しておけば、sub1.example.comドメインに対しても適用されるようになります。
	HPKPヘッダとして、通常は"Public-Key-Pins"を使いますが、"Public-Key-Pins-Report-Only"を使えば、ブラウザはHPKPを検証せずに、エラーとなってもHTTPS接続は続けられるテスト用の機能があります。約10%のサイトがこのテスト用の設定を使っているとわかります。
	Scott Helme氏の2017年時点で接続可能なHPKP対応サイト283件のうちgTLD(com、org等)、ccTLD(de、ru、jp等)別に件数を調べてみると、comが多いのは当然でとして、実際の各TLDの登録件数に比較して顕著に多いTLDが見られました。comは1.3億、netとdeは1600万、ruは540万ドメインが登録されていますが、ドメイン登録数に比べて、比率的にru、org、deは突出して多くまた、グラフ上はその他としていますが、マイナーなccTLDの国についても、比較的HPKP設定が多い国があります。また、eduが異常に少ないのも気になりました。その他には、ar/br/cl/il/pt/nl/tn/skなど、マイナーなものが 50近くありました。

6. 今のHPKPの何がいけなかったのか

hpkpの発想自体は、不正発行された証明書を使った偽サイトを防ぐための仕組みとして有用であり、ChromeやFirefoxのブラウザ組み込みのプリロートピンはうまく機能しているように思えます。その一方でHPKPヘッダを使った方式は、かなり運用が複雑で難しく、失敗すると 2ヶ月といった、長期間、一部のユーザは接続できないという、障害が発生するリスクも高いことがわかりました。

個人や中小のサイトで不正証明書を使ってまで偽サイトを作るメリットは見当たらず、攻撃を受ける可能性も極めて低いため、HPKPを使ってサービス障害のリスクを取ってまでHPKPを導入する必要はないと思います。

では、一般サイト向けにHPKPの普及が進むためには、運用のしやすいサービス障害が起きにくい仕様の変更が必要だと思いますが、どうすればこれが可能になるでしょうか？

max-ageを2ヶ月と仮定して、 HPKPヘッダで運用上の課題なのは、証明書更新の2ヶ月前に、ピンが変更になるなら設定を事前設定しなければならず、間違えに気づいてヘッダ設定を直しても、2ヶ月は通信障害が発生するということです。

そこで、間違えに気づいた時には、すぐに設定変更が反映できたり、サーバー側で暫定的にブラウザのHPKP検証を無効化できるキルスイッチがあるとよいと思うのです。深く考察した訳ではありませんが、例えば、HPKP更新日をヘッダに記載するなどして、設定に更新があればmax-ageに関わらず更新し、無効化するなら、無効化するといった機能を提供すれば、運用はmax-ageや設定ミスの呪縛から解放されるように思います。

他にもこの問題の解決方法はあるかもしれませんが、何らかの手当てをしない限り、HPKPは普及しそうにはありません。

7. おわりに

以上、HPKPについて、どこにピンを打つか、max-ageはどうするかなど運用面から、いろいろ考察や整理をしてみました。現時点では、HPKPを導入するのは時期尚早で、運用に負担をかけ、サービス停止のリスクも高いということもご理解いただけたのではと思います。

これで、自分がHPKPについて前から書きたいと思っていたことを、落ち着いて整理でき、3年越しぐらいに吐き出せました。わかりにくかったり、理解が間違っていたらすみません。個人的には、HPKPについては、これでわだかまりとかモヤモヤ感というは概ね払拭されたように思います。まぁ、「ブログなんてそんなモノよね」ってことで、、、ｗ

8. (参考) HPKP関連の勉強になるリンク

Netcraft: Secure websites shun HTTP Public Key Pinning: HPKPが流行っていないことの統計。なぜ流行らないかの解説。良記事。
Netcraft: HTTP Public Key Pinning: You're doing it wrong!: Netcraft社の、世の中のHPKP対応サイトの設定誤りに関する解説。良記事。
Scott HelmeさんのHPKPブログ記事: CSPやHSTSやHPKPなどSSL関連技術の専門家で、HPKPなどのレポート先サイト report-uri.io を運営しているScott Helmeさんのブログ。HPKP対応サイトのドメインリストなどのデータもあります。
Qualys Blog: Is HTTP Public Key Pinning Dead?: Ivan Ristic氏の、「HPKPが終わっているか？」に関する議論。
Raymii.org: HTTP Public Key Pinning Extension HPKP for Apache, NGINX and Lighttpd: 解説は充実。各サーバー毎のHPKPヘッダの設定例。
MDN: Public Key Pinning: MozillaによるHPKP解説。ChromeやFirefoxでのHPKP対応バージョンの記述。サーバー設定例レポート機能は新しいChromeしか使えない事の言及など、参考になる。
Public Key Pinningについて - Chris Palmer (原文): Chris PalmerによるHPKP解説。誤解もあるが、初めて証明書チェーンのどこにピンを設定するか、そのケース分けについて考察した記事。
ぼちぼち日記：不正なSSL証明書を見破るPublic Key Pinningを試す: joviさんによるHPKP(ドラフト)に関する詳細かつ広範な解説です。
Jxckさんのブログ：Public Key Pinning for HTTP(HPKP) 対応と report-uri.io でのレポート収集: Jxckさんの解説。特にreport-uriの機能を試してみた報告が貴重。
公開鍵ピンニングによるユーザ追跡 HPKP Supercookies: 今回の記事とはあまり関係ないですが、にしむねあさんのHPKPを使ったクッキーを使わないユーザー特定の面白い試みに関するスライド資料。
OWASP: Certificate and Public Key Pinning: OWASPの解説記事。無駄な情報も多い。

9. 追記

9.1. 追記(2017.02.26) HPKPのブラウザサポート状況

caniuse.comサイトでは様々なブラウザの機能のサポート状況を情報提供していますが、 2017年2月時点での HPKPのブラウザサポート状況についても記載されているので、示しておきます。Firefox、Chrome、Opera、Android版Chromeではサポートされていますが、それ以外ではサポートされていません。
hpkp-caniuse

9.2. 追記(2017.02.26) smashingmagazine.comで発生したHPKP障害

その後、HPKPについて継続して調べ物をしていたら、 smashingmagazine.comのブログで、 HPKPにより発生した接続障害についての考察が書かれていました。ここでは、以下のように書かれていました。

HPKPは中間者攻撃に対して有効な機能だが
HPKPの設定ミスで2016年10月21日から25日にかけHTTPS接続障害が発生
証明書期限切れでHPKPヘッダを更新したらエラーになった
すでに証明書は期限切れでロールバックはできない

教訓として、ブログでは、

金融サイトなどならば、HPKPを使う価値はあるが、単なる情報提供サイトなら、その必要もない。HPKP設定ミスによるサービス停止は、中間者攻撃よりも大きな脅威だ
max-ageを短くすることにより問題を緩和できる

私もサービス提供不能の方が、大きな問題だというのは同意ですが、前にも述べた通り、max-ageを短すぎる値に設定するのは懸命ではなく、注意が必要です。このサイトでは、max-ageを1年としているようですが、確かにこれは長すぎます。新しく設定されたHPKPヘッダを見てみましたが、現行のSSLサーバー証明書の他に 3つピンが設定されており、max-ageは1日に設定されており、いろいろと設定には問題がありそうです。

タグ：: #HPKP; #SSLTLS; #TLS; #Public-Key-Pins; #RFC7469; #X.509証明書; #証明書更新; #OpenSSL

k_urushima

2016年12月18日18:07

カテゴリ: JavaScript; PKI

X.509証明書の識別名などで使われるMulti-valued RDNとjsrsasignのサポートについて

久々にちょっとPKI関連ネタです。いわゆるデジタル証明書(X.509証明書)には、主体者名(Subject Name)や発行者名(Issuer Name)に識別名(DN: Distinguished Name)を使います。例えば、

CN=yourname@example.com,O=example,C=JP

のようなものです。カンマで区切った一つ一つを相対識別名(RDN: Relative Distinguished Name)と呼んでいます。

O=example

一般的には相対識別名(RDN)は、「一つの」属性タイプと属性値のペア(AttributeTypeAndValue) より構成されます。

属性タイプ=属性値
O=example

ただ、「一般的には」と書いた通り、RDNについて複数のAttributeTypeAndValueを持つことも可能です。これをMulti-valued RDNと呼んでおり、プラス"+"記号でつないで以下のように表現します。

属性タイプ1=属性値1+属性タイプ2=属性値2...
CN=User1+serialNumber=123

Googleとかで「Multi-valued RDN」で検索するとわかると思うんですが、英語では結構あるのに、日本語で触れている記事って、自分のブログ以外みつからないみたいなんですよね。今日は、拙作の暗号ライブラリ jsrsasign や OpenSSL を使いながら、証明書識別名のMulti-valued RDNや、識別名について掘り下げてみたいます。

エントリと識別名

LDAPや、その元となっているX.500ディレクトリサービスでは「エントリ」のツリー構造により情報を管理し、例えば会社、部門、社員は以下のように管理することができます。

LDAPでは、あるエントリを特定するために「○×商事」の「総務部」の「佐藤二朗」さんという特定の仕方をします。エントリの名前、「総務部」や「佐藤二朗」という値は、属性タイプという型をつけることができ、組織名(O: Organization Name)、部署名(OU: Organizational Unit Name)、一般名(CN: Common Name)などのタイプがあります。

例えば、営業の鈴木さんを特定するときに一番上までのエントリを辿って、以下のように表現します。これを「識別名(DN: Distinguished Name)」と呼びます。これにより他の部署のSuzukiさんとも区別できます。

CN=Suzuki,OU=Sales,O=MaruBatsu

識別名のうち、「OU=Sales」のようにエントリの丸の中を相対識別名(RDN: Relative Distinguished Name)と呼びます。

また、このエントリのツリー構造をDIT(Directory Information Tree)と呼びます。

Muti-valued RDNとは？なぜ必要か？

上記で説明した識別名(DN)で、同じ営業部に鈴木花子さんが二人いたらどうしましょう。一般名に区別するための数字を追加したり、追加の値として、社員番号やメールアドレスで区別することもでき、エントリを追加しても良いのですが、どれもイマイチ。

そこで、一つのエントリに複数の値をつけて識別することもできます。これを Multi-valued RDNと呼んでいます。

同性同名の人は多分いるでしょうから、社員番号やメールアドレスなど他の一意なものと組み合わせて管理するのはスマートな管理方法だと思いますし、一部の商用のディレクトリサーバー製品では、利用者数ベースでライセンス課金するために、エントリ数を使うものもありますので、Multi-valued RDNを使うことによってコスト削減を狙うこともできます。ただ、Multi-valued RDNは、すべての製品で使えるというものでもないので(例えば、とある製品のスマートカードとか802.1X認証とかで後になって問題になったことがありましたよね、、、)本当に使ってしまってよいかどうかは、アプリケーションと相談して決める必要があるでしょう。

識別名の文字列表現

識別名の文字列表現にはざっくり2つの表現があります。

CN=Matsuda Kenji,OU=Sales,O=MaruBatsu
/O=MaruBatsu/OU=Sales/CN=Matsuda Kenji

DITのツリー構造の下から順にカンマ","でつないだ方法と、上から順にスラッシュ"/"でつなぐ方法です。

カンマで逆順につなぐ方法はRFC 2253 Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Namesや後継の4514で規定されています。LDAPのアプリケーションソフトウェアでは一般的に使われている方法です。

もう一方の、先頭にスラッシュを付け、スラッシュで正順でつなぐ方法はOpenSSL compatフォーマットと呼ばれ、OpenSSLで標準的に使われるとともに、OpenSSL系のウェブサーバーであるApache HTTP Server、nginx、lighttpdなどの設定などで使われる方法です。

Multi-valued RDNの場合には、どちらの形式でも値をプラス"+"記号でつないで表現します。

CN=Matsuda Kenji+emailAddress=matsu@mb.com,OU=Sales,O=MaruBatsu
/O=MaruBatsu/OU=Sales/CN=Matsuda Kenji+emailAddress=matsu@mb.com

プラスで繋がれた値の表示順序については、特に決まりは無いと認識しており、以下のMulti-valued RDNでCNとemailAddressのどちらを先にしても良いはずです。これがどのようにASN.1でエンコードされるかは後で述べます。

CN=Matsuda Kenji+emailAddress=matsu@mb.com
emailAddress=matsu@mb.com+CN=Matsuda Kenji

次にCNやOUなどの属性タイプの文字列表現ですが、どのように表記しなければならいといった厳格な標準はなく、実装もバラバラであることがわかっています。8年前にXAdES長期署名に関連して、識別名の中の属性タイプの表記の実装状況について調査しており、その時にまとめた表を再掲します。

X.509証明書プロファイルを定めたRFC 5280の4.1.2.4節発行者名(Issuer)では、識別名の属性タイプとして対応しなければならない(MUST)リストと、対応すべき(SHOULD)属性タイプのリストが掲載されており、表中ではMUSTを黄緑、SHOULDを黄色、その他、証明書で実際に使われることのある属性タイプのリストを白とし、.NETや各種Javaベースの暗号ライブラリでどのように属性タイプが表記されるかをテストしました。表を見ればわかるとおり、結果はかなりバラバラです。また、S/MIMEのために使用される事があり、実際の証明書でもかなり含まれているemailAddressの属性タイプも、標準では実装を求めていないために対応にばらつきが出ているように思います。

今、見直してみると当時はなかったEV証明書用の以下の属性タイプも、今ならテストすべきだったかなぁと思います。

jurisdictionOfIncorporationL - 法人登録管轄地(市町村)
jurisdictionOfIncorporationSP - 法人登録管轄地(都道府県)
jurisdictionOfIncorporationC - 法人登録管轄地(国)

また、カンマつなぎの識別名表記であるRFC 2253とその後継のRFC 4584の違いについて8年前の記事でまとめており、仕様の改定によって、より識別名表記が一意になる方向に修正されていますが、仕様の中で「RFC 4514は識別名文字列は一意にならない(=正規化しない)」という事が明記されており、識別名文字列は、様々な表現が許されており、単純な文字列比較では同じであるかどうかを判断できない事に注意しなければなりません。

識別名のASN.1定義と構造

次に、識別名が、ASN.1 DERエンコーディングにより、どのようにバイト列にエンコードされるのかを、説明したいと思います。まず最初に、識別名のASN.1定義を紹介しましょう。 RFC 5280 4.1.2.4 Issuerより


// X.500名、識別名(DN)はRDNの並び(SEQUENCE)
Name ::= CHOICE { rdnSequence  RDNSequence }
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

// RDNは、AttributeTypeAndValue 1つ以上のSET
// つまり、複数AttributeTypeAndValueがあってもよい。
// これが複数あれば Multi-valued RDN
RelativeDistinguishedName ::=
  SET SIZE (1..MAX) OF AttributeTypeAndValue

// 属性タイプと属性値のペア
AttributeTypeAndValue ::= SEQUENCE {
  type     AttributeType,
  value    AttributeValue }
AttributeType ::= OBJECT IDENTIFIER
AttributeValue ::= ANY

// 属性値はANYと定義していながらも、DirectoryStringで
// 定義されたいずれかの文字タイプを使用する
DirectoryString ::= CHOICE {
      teletexString           TeletexString (SIZE (1..MAX)),
      printableString         PrintableString (SIZE (1..MAX)),
      universalString         UniversalString (SIZE (1..MAX)),
      utf8String              UTF8String (SIZE (1..MAX)),
      bmpString               BMPString (SIZE (1..MAX)) }

つまり、

識別名(DN)は、相対識別名(RDN)の並び(SEQUENCE OF)であり
相対識別名(RDN)は、属性タイプと値(AttributeTypeAndValue)の集合(SET OF)であり
属性タイプと値(AttributeTypeAndValue)は、属性タイプと値の並び(SEQUENCE)である

という事です。SEQUENCEとSETは構造型と呼ばれるASN.1プリミティブですが、

SEQUENCEは配列のようなもので、順序関係のある並びを表す際に使います。
SETは集合のようなもので、構成要素の中には特に順序関係はない場合に使います。

ついでに、SEQUENCEやSETと、SEQUENCE OF ～、SET OF ～の違いですが、

単にSEQUENCEやSETとなっている場合には、構成要素のASN.1クラスが異なる場合に使います。上の例ではAttributeTypeAndValueがそれに当たります。
SEQUENCE OF、SET OFとした場合、構成要素のASN.1クラスが同じ型の場合に使います。上の例では、NameやRDNがそれに当たります。

それでは、例として以下の識別名をASN.1 DERエンコーディングしてみましょう。

CN=aaa,O=TEST,C=JP

RFC 2253の場合には、逆順でRDNが並ぶので、以下のようにエンコードされます。


302A                SEQUENCE(30) OF       -- DN
  310B                SET(31) OF          -- RDN[1]
    3009                SEQUENCE(30)      -- AttributeTypeAndValue
      0603550406          ObjectIdentifier(06) countryName
      13024A50            PrintableString(13) "JP"
  310D                SET(31) OF          -- RDN[2]
    300B                SEQUENCE(30)      -- AttributeTypeAndValue
      060355040A          ObjectIdentifier(06) organizationName
      0C0454455354        UTF8String(0C) "TEST"
  310C                SET(31) OF          -- RDN[3]
    300A                SEQUENCE(30)      -- AttributeTypeAndValue
      0603550403          ObjectIdentifier(06) commonName
      0C03616161          UTF8String(0C) "aaa"

ASN.1データはデータ型を表すタグ、バイト長、値データより構成され、上の例の最後の行では、0CがUTF8String型、03がバイト長(=3)、616161(=aaa)が値を表しています。

さて、次にMulti-valued RDNの場合にはどのようにエンコードされるのか、下の例を元に見てみましょう。ここでは、CN=aaaとCN=aの2つのAttributeTypeAndValueが使用されています。

CN=aaa+CN=a,O=TEST,C=JP

これをASN.1 DERエンコーディングすると以下のようになります。最後のRDNに注目してください。CN=aとCN=aaaと二つのAttributeTypeAndValuesがあることが確認できます。また、また、CN=aとCN=aaaでは、必ずCN=aが先に来ることにも注目です。


3034                  DN
  310B                  RDN[1] C=JP
    3009
      0603550406
      13024A50
  310D                  RDN[2] O=TEST
    300B
      060355040A
      0C0454455354
  3116                  RDN[3] CN=aaa+CN=a SEQUENCE(30)が2つある
    3008                  ATV[1] CN=a  CN=aの方が先に来ている
      0603550403
      0C0161
    300A                  ATV[2] CN=aaa
      0603550403
      0C03616161

このRDN中のCN=a、CN=aaaの順序関係にはASN.1 DERとBERのちょっとした違いが関係があります。DERはBERのサブセットでなんですが、BERでは複数の表現が許されるのに対し、DERでは必ず一意な表現になります。その違いを表にまとめました。

	ASN.1 DER	ASN.1 BER
概要	ASN.1の一意なエンコード規則	ASN.1のエンコード規則。DERのスーパーセットでDERであればBER
共通の特徴	通信の世界では長い歴史のある、CPUや整数型のサイズに制限されない、巨大なデータも扱える、任意の構造化データを扱えるデータ表現。XML, JSONに比べコンパクト。
用途	証明書、CRL、OCSP、RFC3161タイムスタンプ	S/MIMEデータ、CMS署名・暗号化データ、PKCS#12
比較	必ず表現は一意。超巨大なデータでも長さが予めわかっていないといけないので、ストリーム処理など不向き	複数の表現がある。超大きなデータでも取り扱い可能
SET	要素のバイト列で昇順ソートする	ソートしなくて良い
BOOLEAN	TRUEのみ使え、FALSEは省略するようクラス定義	TRUE、FALSEが使える
不定長表現	長さ表現は一意で、予めデータサイズがわかっていないといけない。	長さ表現で不定長表現が使え、長さを8000とした場合それは開始記号で0000が続くまで一つの要素であり、大きなデータも扱いやすい。

以上のような違いがあり、SETの違いによりMulti-valued RDNのSET OFの順序が決まっているわけです。

SETの要素は、各要素をASN.1エンコードしたときの昇順の辞書順でソートされ、ざっくり言えば、

要素の短い物程先
同じ長さなら属性タイプの長さが短い方が先

ということになります。例でみてみましょう。


3008 0603550403 0C0161        CN=a
300A 0603550403 0C03616161    CN=aaa
  ^^ 全体の長さLが08, 0Aの順になるので同じ属性タイプ長なら属性値の短い方が先
     C,O,OU,CNなど主要な属性タイプはOIDの値が2.5.4.xになるので同一属性タイプ長

全体の長さが同じ時、


  ^^ 全体の長さは同じなら
3011 0603550403 0C0A6162636465666768696A CN=abcdefghij
3011 060B2B0601040182373C020103 0C024A50 jurisdictionOfIncorporateC=JP
       ^^ 属性タイプの値の短い方が先

OpenSSLのMulti-valued RDN対応

OpenSSLはMULTI-valued RDNに対応しており、"-multivalue-rdn"をつけるだけです。例えば、既存の秘密鍵でワンライナーでMulti-valued RDNの自己署名証明書を作りたい時

openssl genrsa 2048 > a.prv
openssl req -new -key a.prv -x509 -subj /C=JP/O=Test/OU=b+CN=a -out c.cer -multivalue-rdn

Multi-valued RDNの証明書発行要求を作りたいとき

openssl req -new -key a.prv -subj /C=JP/O=Test/OU=b+CN=a -out c.csr -multivalue-rdn

となります。

jsrsasignのMulti-valued RDN対応

jsrsasignは、私が趣味で作ったPure JavaScriptによる暗号ライブラリでして、2010年ぐらいからボチボチ暇を見つけては昨日を追加しており、最初はRSA署名だけだったものが、ASN.1や証明書やタイムスタンプやJOSEなんか、自分が「欲しいな」と思った時に増築を繰り返しており、PKIやASN.1やJOSE(JWS,JWT,JWK)関係でちょっと試したいなと思った時に重宝しています。

ウェブブラウザ上でも、Nodeでも使え、APIドキュメントやサンプルも充実させているので、結構ユーザは世界中にいたり、最近はSONYや横河(や勝手にうちの会社（＾＾；)のハードウェア商品でも使われていることが発覚したり、Nodeのnpmパッケージは月間10万弱のダウンロードがあるようで、ホントありがたい話です。

JavaScriptの暗号ライブラリのAPIとしては、W3C Web Crypto APIなどあるんですが、モバイルブラウザでサポートしていないケースがあったり、古い暗号が使えなかったり、ちょっと書こうと思っても何行も書かなければいけなかったり、面倒くさいんですよね。そこで、jsrsasignでは、「なるべく少ない行数でやりたい事ができる」っていうのを目標にしていて、例えば鍵なんかは秘密鍵でも公開鍵でもPKCS#5でもPKCS#8でもJSON Web KeyでもなんでもKEYUTIL.getKeyに渡してしまえば適当に処理します。また、PCでもスマホでもNodeでも、多少古い環境でもJavaScriptさえ動けば使えるようになっています。また、APIドキュメントやチュートリアルの資料もできる限り潤沢に用意したつもりです。

割と最新の話まで入っている英語の入門スライドがあったり、

またちょっと古いですが、2013年にJNSAのWGでお話したjsrsasignとjsjwsが別の開発ラインだった時の入門スライドがあるのでよかったら参考にしてください。

ドキュメント類は拙い英語のものしかなくて申し訳ないですが、問題とかあれば、Issueには日本語で入れて頂いて構わないので入れて頂ければと思います。

で、jsrsasignをMulti-valued RDN対応させたり、カンマ繋ぎDN対応したいなと思っていて、ようやく6.2.2をリリースした最近になってから対応させました。例えば、Multi-valued RDNの識別名がどのようにASN.1 DERエンコードされるのかなんて話は、次のように確認できます。


% node
> var X509Name = require("jsrsasign").KJUR.asn1.x509.X500Name;
> new X509Name({str: "/C=JP/O=T1+CN=kjur"}).getEncodedHex();
'3027310b3009060355040613024a5031183009060355040a0c025431300b06035504030c046b6a7572'

あとは、証明書発行要求(CSR)を作ったり、


var rs = require("jsrsasign");
var kp = rs.KEYUTIL.generateKeypair("RSA", 2048);
pem = rs.KJUR.asn1.csr.CSRUtil.newCSRPEM({
  subject: {ldapstr: 'OU=T1+CN=example.com,O=Test,C=US'},
  ext: [
    {subjectAltName: {array: [{dns: 'example.net'}]}
  ],
  sbjpubkey: pubKeyPEM,
  sigalg: "SHA256withRSA",
  sbjprvkey: prvKeyPEM
});

証明書を発行したりする時にもMulti-valued RDNが使えます。


var pem = KJUR.asn1.x509.X509Util.newCertPEM({ serial: {int: 4},
  sigalg: {name: 'SHA1withRSA', paramempty: true},
  issuer: {str: '/C=US/O=a'},
  notbefore: {str: '130504235959Z'},
  notafter: {str: '140504235959Z'},
  subject: {ldapstr: 'OU=kjur+CN=kjur,O=b,C=US'},
  sbjpubkey: kp.pubKeyObj,
  ext: [
    {basicConstraints: {cA: true, critical: true}},
    {keyUsage: {bin: '11'}},
  ],
  cakey: kp.pubKeyObj
});

割と融通が利くので、よかったら使ってやってください。

おわりに

というわけで長々、Multi-valued RDNや識別名(DN)のことでダラダラ書いてしまいました。ごめんなさい。誰かの参考になれば良いかな、と思います。

追記(2016.12.19)

あっ、誤解されないように書いておきますと、私としては、Multi-valued RDNを広めたいとか、使うべきだとか言うつもりは毛頭ありません。相互運用性が高い方向でインフラ設計するのが原則であり、使わなくて済むなら使わない方がいいでしょう。ただ、受け取ったとしても、びっくりしないでね、と、、、、ｗ

タグ：: #X.509証明書; #識別名; #相対識別名; #RDN; #Multi-valued-RDN; #jsrsasign; #OpenSSL; #RFC2253; #LDAP; #ASN.1

2015年09月22日00:01

カテゴリ: S/MIME; iOS

(小ネタ)スマホでS/MIME署名・暗号メール使うならdocomoはおやめなさい

いや～、シルバーウィーク暇ですわ～～～。iPhoneというかiOSの標準メールソフにはS/MIME署名・暗号メールの機能があって、S/MIME用証明書というメールアドレスの書かれたデジタル証明書があれば、自分が送ったメールの本文が改ざんされないようにデジタル署名で保護したり、送信先、送信者しかメールが見られないように暗号メールを送ったり、受信したりすることができます。

先月あたり、docomo iPhoneのS/MIMEメールでちょっと問題があることを知って、今日は書きそびれていたそのことをブログに書こうと思っています。

ある日、会社からS/MIME署名メールをdocomoのiPhoneに送ってみたところ、こんな感じに表示されました。

最初は、会社の検閲というかフィルタリングによって、S/MIME署名メールの署名部分を削除して送っているんだろうと思って、情報システムの運用部門に問い合わせてみたんですが、特にそのようなフィルタリングはしていないとの事。さらに、いろいろ調べてくれ、auやSoftbankなどではこのような問題は発生せず、送信先がdocomoの時だけ発生する問題だとわかりました。

~~いろいろ、ネットで調べてみると、こんなOCNのページを見つけました。~~

OCNからのお知らせ：電子署名に関するよくあるお問い合わせより引用

Q: スマートフォンで電子署名付メールを受信するとどうなりますか？

A: スマートフォンで受信した場合、(...中略...) (docomoのSPモードのような)携帯電話と同じ確認方法があります。(中略)携帯電話と同じ方式でメールを受信された場合は、電子署名そのものが「削除」されます。そのため、電子署名なしの通常のメールと同じ扱いになります。

最初、OCNの電子署名削除のお知らせページを見つけたので、docomo.ne.jpのメールはOCNを使っているのだと勘違いしていたんですが、いろんな方にコメント頂き、iPhoneでdocomo.ne.jpドメインのメールを使う場合には、ケータイで使われるSPモードメールをクラウドで管理するドコモメールという仕組みで送受信するそうです。

SPモードメールやドコモメールで電子署名を削除してしまうという説明は結局見つけることができなかったのですが、iモードメールに関しては以下のような記述を見つけることができました。症状としてはiPhoneでのdocomo.ne.jpのメールの状況と同じかなと思います。

docomo: iモードメールでできることより
電子署名付きメールが受信できる
電子署名があるメールも受信できるようになりました。
注意電子署名部はiモードセンターで削除され、メール本文に「電子署名削除」が挿入されます。

お、おいおい！！！docomoのケータイメール(SPモード)のS/MIME署名・メール対応について、どこにも注記や説明はないようなのですが、多分インフラとしてOCNと同じ環境か似たものを使っていると思われ、 S/MIME署名メールが送られてくると、一律、S/MIME電子署名部分を削除してくれるのだそうです。ひどい話じゃないですか。せっかく改ざん検知機能のためにS/MIME署名メールを送っているのに、S/MIME署名を削除して、本文を書き換えて送ってくるのです。

ファイルサイズが大きいからとか、ウィルス感染のリスクがあるから、とか何か理由があれば、削除してくるのもわかりますが、大きなサイズの画像でも送ることができますし、何故かS/MIME署名(と多分S/MIME暗号メールも)その部分だけ削除して送ってくるのです。なんで、勝手にこんなことをしてくれるんですかねぇ？

せっかくのiPhone、iPadの標準メールソフトのS/MIME署名・暗号メールの機能を使いたいなら、docomoは使い物にならないので、auやSoftbankを使いなさいという事なのだろうと思います。

Androidについては、この数年ずっと良いS/MIME対応メールアプリを探しているんですが、未だ良いアプリが見つかりません。どなたか良い情報があれば教えて下さい。よろしくお願いします。

今晩はこの辺で。

(追記 2015.09.22 07:00)

OCNについて、Active Sync使って問題なく送れているとのコメントを頂きました。コメント欄ご覧ください。記事も直しております。

(追記 2015.09.22 10:00)

ブログについていろいろ、コメントやリツイートなどいただき、docomo(mopera)のメールとOCNは無関係ということがわかりました。ありがとうございます。docomoのメール(iモードメール？)は、このページで以下のような説明がありました。

電子署名付きメールが受信できる
電子署名があるメールも受信できるようになりました。
注意：電子署名部はiモードセンターで削除され、メール本文に「電子署名削除」が挿入されます。

タグ：: #署名メール; #暗号メール; #iPhone; #docomo; #OCN; #SMIME

2015年05月10日15:23

カテゴリ: S/MIME; Windows

Windows信頼するルート認証機関コンプへの道(第一回)

先日のブログ「Windowsルート証明書の更新プログラム(2014.09)と戯言など」で、

オフラインでルート証明書をアップデートする公式アップデーター http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/rootsupd.exe からルート証明書が「抜ける」んじゃね？と某木村大先生からご指摘いただきました。

実際に試してみたので、ちょっと書いてみたいと思います。

ルート証明書アップデーターからSSTの取り出し

Windows 7以降のオフライン環境で、信頼するルート認証機関のリストをアップデートするのにアップデーター http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/rootsupd.exeがあるというので、早速ダウンロードしてみます。wgetでヘッダ見てみると最終更新は"Wed, 12 Nov 2014 17:33:07 GMT"になっているので、最新のアップデートには対応してそうかな？とも思ったんですが、後に最新のルート更新には対応してなかったことがわかりますorz

これはCAB形式自己解凍アーカイブみたいになっているので、exe2cab(Vectorのは64bitでは動作せず)を使って中身のcabファイルを取り出します。

cabファイルの中はこんな感じ。

ADVPACK.DLL
authroots.sst - ルートのスモールセット？
delroots.sst - 削除するルート
roots.sst - 最小限の2つのルート
rootsupd.inf -
updroots.exe - ルートを更新するプログラム
updroots.sst - 追加される多くのルート

cabファイルのタイムスタンプ見てみたら、2013年4月になっているので、どうも直近の2014年9月の更新に対応したアップデートファイルでは無さそうな雰囲気です。

SSTファイルからのルート証明書の取り出し

*.sstファイルはMicrosoft Serialized Certificate Filesというフォーマットらしく、前にも力技で証明書取り出すスクリプトを書いた記憶があるんですがorz、ちょっと調べてみたらPowerShellのExport-CertificateやImport-Certificateで操作できそうな雰囲気。サンプルにはSSTに証明書を追加する例なんかも紹介されていました。ところが、どうもSSTから証明書を取り出す方法がよくわからずに結局断念。

もうちょっと調べてみるとSSTの中の個々の証明書エントリはSerializedCertificateEntryという構造になっているらしく、SSTのヘッダ情報のあとはこの並びになっているので、Perlでちゃちゃっと抜き出すスクリプトを書きました。

id - 4byte 0x00000020
encodingType - 4byte 0x00000001 (= ASN.1 encoding)
length - 4byte 続く証明書データの長さ
certificate - 可変長 証明書生データ

取り出せた証明書の数はこんな感じ、2014年9月のルートの更新では411だそうですから、かなり少なめ。古い情報っぽくてちょっと萎え気味。

SSTファイル	ルート証明書数
authroots.sst	77
roots.sst	6
updroots.sst	275
計	358

で、ぽちぽちルート証明書を開いてみる

とまぁ、ルート証明書の取り出しはできたので、これをそれぞれ開いてみると「インターネットオプション＞コンテンツ＞証明書＞信頼されたルート認証機関」に未表示のものだったら、表示されるようになります。

Windows 8.1 Proの最新パッチ済の環境で、358のうち、有効期限切れになっているものや、すでにMicrosoftが登録削除しているものもあるようで、最終的には271個のルート認証機関がちゃんと表示されるようになりました。これの作業前は確か27だったので、大躍進という感じではあります。
winroot
(TURKTRUSTが表示されていることに他意はありません（＾＾；

おわりに

いや～～、隠し球っぽくて気持ち悪かったのが、表示されて随分すっきりしますね～～。ただ、

やっと271は表示されたが411まではまだ遠い

私はビックリマンチョコ世代ではないですが、仮面ライダースナックとか集めましたね～～。ソシャゲーのコンプガチャみたいんなもんなんですかね～～。最後までちゃんと表示させたくなりますよね～～～。 411まではまだ道のりは遠い感じですねぇ。やっぱり、Certificate Transparencyのデータに手をつけないといかんかなぁ、、、と思っているところです。

今日は、この辺で、、、

タグ：: #ルート認証局リスト; #トラストアンカ; #Windows; #Windowsルート証明書プログラム; #exe2cab; #SST; #信頼されたルート認証機関

2015年05月03日10:19

カテゴリ: SSL証明書; Windows

Windowsルート証明書の更新プログラム(2014.09)と戯言など

随分昔の話になりますが、 2014年9月に現時点で最新のWindowsルート証明書プログラムのリストが公開されており、今日は久々にこれを見ていこうと思います。

数年前、Windowsルート証明書の更新プログラムで登録されているルート認証機関にどんな変更があったのか、調査をしてブログで公開していた時期がありました。その時はWindows XPの時代で、登録されているルート認証機関はすべて表示されるようになっていたので、ルート証明書を全部取り出すプログラムを書いて、前回との差分を比較していただけだったので、比較的簡単に調査ができたわけです。

ところが、Windows 7以降、Windowsのルート証明書は、最初からすべて登録されるわけではなくなってしまいました。ちゃんと調べたわけではないので、わからないのですが、確かOSインストール直後は15～25ぐらいの主要なルート認証機関しか登録、ならびに表示されておらず、表示されていないルート認証局のサイトにアクセスした場合に、動的に登録されたルート証明書が追加されるような仕組みに変更になりました。

Windows 7以降のルート認証局リストの仕組みの問題点

Windows 7より導入されたルート認証局リストの配布方式は、個人的に「スッキリしない」というか「嫌だなぁ」と思っています。理由はこんなところです。

ルート認証局のリストはPDFの文書として公開されているが、維持組織、国、認証局名、鍵アルゴリズム、鍵長、ルート証明書ハッシュ値(拇印)しか公開されておらず、識別名や証明書の内容はわからないままである。中には、初期状態で表示されない RSA 1000bitのルート証明書が残っていたりする。
初期状態では20程度の認証局しか表示されておらず、利用者がどの認証局を信頼していることになっているのか、これを知る方法が上のリストのみで十分でない。
例えば、ある小国の認証局を全世界の人が信頼する必要があるとは思えない。不正発行などの事故を起こした場合に、信頼していないほうが良かったという事もあるだろう。そのような時に、自分が信頼している認証局がどこであるのかを把握できないのは問題だ。
Windows 7以降のシステムが認めたルート認証局は削除したとしても、再度アクセスする際に復活してしまう。ユーザは余計な認証局を利用停止や無効化することができない。
つまる所、最初からルート認証局リストが明示されず、後出しジャンケンのようにルート認証局が接続時に追加されるのは如何なものだろうか。

もちろんモバイル向けに初期配布のルート認証局は小さくしたいというのも、わかる気はしますが、どうせ400程度ですから、大したデータ量でもないので、最初から登録してあったほうが潔いと思います。

2014年9月版 Windowsルート証明書の更新

2014年9月のWindowsルート証明書の更新では、411のルート証明書が登録されています。

国別で見てみると、52ヶ国のルート証明書が登録されており、内訳は多い順に以下のようになっています。やっぱり、米国、スペインは多いですね。意外に少ないなぁと思うのが英国、オーストラリアです。
country

次にルート証明書の公開鍵アルゴリズムと鍵長についても見てみましょう。
keylen
RSA 2048bitがやはり多いですが、 RSA 4096bit、楕円曲線暗号のECC NIST P-384曲線もかなり増えています。 Comodo、 DigiCert、 Entrust、 GlobalSign、 Symantec、 Trend Microが楕円のルート証明書を持っています。そういえば、 Microsoftから発行されているリストには SHA1かSHA2かの情報って無いんですよね。残念だなぁ。やっぱり、ルート証明書そのものをダウンロードできるようにしてほしいなぁ。 Appleも、最初はルート証明書の詳しい情報を出していたんですが、最近はMicrosoftに習って、詳しい情報出すの止めちゃったんですよね～～。寂しい話です。

ルート証明書数の推移

Windows系、Android、Mac OS X、iOSでデフォルトのルート証明書の数がどう増えていったのかグラフにしてみました。Apple製品は公式サイトの情報から取得しています。Androidについては拙作のRoot CA Viewer Liteか過去の他作業を元に調べています。
osroot
iOSはiOS3以降、メジャーバージョン毎にルート証明書リストが公開されているのですが、Mac OS Xについては新しいMavericksとYosemiteしか情報がありませんでした。 Apple iOSについては、ルートの数が乱高下していて、なんか掲載ポリシーが定まってない感じなんですかね？本当はMozillaやJavaについても調べてみたかったんですが、これは今後の課題ということで、、、(^^;

Windowsルート証明書のリストを調べる地道な作業 (泣)

以前は、自前のツールを使えば簡単にルート証明書を抽出できたので、今回のような情報を比較的簡単に調査することができたんですが、 Windows 7以降、そうした事もできなくなってしまいました。で、今回はというと、こんな地味な手順を踏んで調査したんです(泣)。Microsoftの中の人ならリストのエクセルファイルとか、ルート証明書そのものを持っていて簡単に調査できるんでしょうけどねぇ、、、トホホ。

公開されているPDFファイル「 Windows Root Certificate Program Members - September 2014」からCERTIFICATES IN DISTRIBUTION FROM ALL MEMBER CAsの表を各ページ、テキストでコピペする。
Emacsのテキスト編集で何とか、TSV(タブ区切り)ファイルにする。
Macのテキストエディタで開きUTF-16で保存する。
MacのExcelでインポートする。
インポートした時点で、カラム位置のズレや文字化けがあるので手作業で修正。
ルート証明書リストのExcelが完成！！！ (泣)
ちゃんとしたエクセル表なので、フィルタ使って調べたり、簡単なスクリプト書いて集計したりできる。

さらなる野望

家族から「リビングにファンが煩いマシンを置くな！」と非難され、泣く泣くファンレスの超小型マシンDiginnos LIVAをサーバー代わりに使っているんですが、ブラウザで変なサイトに行くこともあまりないので、ルート認証局のリストは27で、初期出荷時からあまり増えていないはずで、今回、試しに開いて、イタリアのActalis Authentication CA G1が増えてしまいました。
windialog
なんかこう、あれです、411もあるわけですから、フルコンプしたいですよねぇ？先生、大事なことだからもう一回言います。

フルコンプしたいですよねぇ？！！！

これをフルコンプするには、 411の全ての認証局それぞれに、そこから発行されたどれか一つのSSLサーバー証明書を使っているサイト見つけて、Internet ExplorerでHTTPSアクセスすればいいだけですが、マイナーな認証局から発行された証明書を使っているサイトを見つけるなんて、海水浴行った海岸のどこかで落とした10円玉見つけるようなもんで、ほとんど無理ですよね。例えば、Symantecなんかは色んな認証局を買ったので、グループだけで70もの認証局が登録されているわけですが、Symantecにそれぞれの認証局から発行された証明書のすべてを見つけるなんて、もう無理です。

こういう時ですねぇ、Certificate Transparencyの公開監査ログを手元に持っているとですねぇ、740万枚ぐらいのサーバー証明書と、そのルート認証局までのチェーンがあるので、それぞれのルート証明書を取り出して、Windowsルート証明書情報のPDFに記載された証明書の拇印ハッシュ値とを比較すれば、そこから発行されたSSLサーバー証明書が一つみつかるので、そこへアクセスすれば前述の「証明書ダイアログ」に表示されるのではないかと！！！(パチパチ)

ゴールデンウィーク中に、ちょっとGo言語でこんなツールを作ろうかなぁ、、、と思ってます。

おわりに

いや～、オレのゴールデンウィークは有意義だなぁ、、、 (遠い目 ) こんなことばかりしているとカミさんに怒られるので、今日はこのへんで。

追記(2015.05.03 13:28)

オフラインでルート証明書をアップデートする公式アップデーター http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/rootsupd.exe からルート証明書が「抜ける」んじゃね？と某木村大先生からご指摘いただきました。確かにそのとおりでした。(つ～か、前にツール使ってそれができてたものが、参照情報しか取れなくなったと勘違いしてできなくなって、そのままにしてたんですが、指摘を頂いてから見てみたらちゃんとありました。) その実行ファイルには、証明書のリストである .SST (Microsoft Serialized Certificate Files)が入っており、その中からルート証明書が取り出せそうです。前は作ったツール使ってたんですが、今は PowerShell から取り出せそう。試したらまた報告します。ルート証明書が抜けたとして、ただ開いただけで、「信頼するルート認証機関」のリストに表示されるんかいな？？？

ちょっと遠い関連記事

タグ：: #ルート認証局リスト; #トラストアンカ; #Windows; #Windowsルート証明書プログラム; #iOS; #Android; #MacOSX; #RootCAViewerLite

記事一覧(手作り)

はてなブックマーク
された記事