[1] [[Webブラウザー]]は、[DFN[[RUBYB[[[証明書データベース]]]@en[certificate database]]]] ([DFN[[RUBYB[[[証明書ストア]]]@en[certificate store]]]]) を保持しています。 * 構造 [64] [[証明書データベース]]は、 0個以上の[[証明書]]と、 その他関連する一連の情報で構成されます。 具体的には実装によって異なります。 [71] 多くの実装は、 論理的に想定される[[証明書データベース]]よりずっと複雑な物理的な構造を持っています。 [EG[ [73] 例えば、 [[OS]] が[[ストレージ]]上に保持する[[ルート証明書]]集と、 [[利用者]]の[[ホームディレクトリー]]内に保持される追加の[[証明書]]と、 [[Webブラウザー]]が保持する[[証明書]]に関する追加情報と、 [[Webブラウザー]]のソースコードにハードコードされた[[証明書]]の扱いに関する追加情報、 といった複数の情報源が関与しているかもしれません。 ]EG] -*-*- [76] [[証明書データベース]]の内容や設定が適用される範囲は実装次第です。 [78] 異なる[[利用者]]が共用できる [[Webブラウザー]]では、 一部または全部が[[利用者]]ごとに[[異なるデータベース][Webブラウザー利用者の設定]]を用いることができるかもしれません。 [83] [[private browsing]] モードがある [[Webブラウザー]]では、通常モードと異なるデータベースを用いる (必要がある) かもしれません。 [86] [[Web]] 以外の目的と共用の[[証明書データベース]]のことも多いです。 * 証明書の種別 [75] [[証明書データベース]]に含まれ得る[[証明書]]は、 いくつかの種類があります。 さらにそれぞれの[[証明書]]にいくつかの追加情報が付与されます。 ** ルート証明書 [6] [[Webブラウザー]]は [[TLS]] を実装し、 [[service identity]] を検証する必要があります。 そのため、[[証明書の検証]]に用いる[[ルート証明書]]群を保持する必要があります。 [22] [[証明書ダウンロード]]仕様では、[[利用者]]が信頼することにした[[証明書]]を[[証明書データベース]]に追加することになっています。 [SEE[ [[証明書ダウンロード]] ]] [31] [[Webブラウザー]]等の[[TLSクライアント]]は[[ルートCA証明書]]に次の[[メタデータ]]を付与して管理しています。 [FIG(list members)[ :[[EV証明書]]用であるか否か:[[EV]] 表示するかの判定に使います。 :[[trust bits]]:適用対象の[[アプリケーション]]を表します。 :システムに組み込まれた証明書か否か:[[Pin Validation]] で使います。 ]FIG] [85] 特定の[[証明書]]は特定の[[ドメイン]]や[[起源]]でのみ利用するよう設定できるかもしれません。 [77] [[Web]] 以外の[[応用]]と共用の[[証明書データベース]]では、 適用対象の[[応用]]を限定する設定があるかもしれません。 ** クライアント証明書 [20] [[Webブラウザー]]は[[TLSクライアント認証]]に対応しているのが普通です。 [[Webブラウザー]]以外の[[クライアント]]のライブラリーや汎用アプリケーションも、 多くが対応しています。 [[クライアント認証]]を行うためには、[[クライアント証明書]]と (あれば) それに連なる[[CA証明書]]、 [[クライアント証明書]]に対応する[[秘密鍵]]を保持している必要があります。 [11] [[証明書ダウンロード]]仕様では、[[利用者]]の[[証明書]]をダウンロードすると、 それに対応する[[秘密鍵]]があれば[[証明書データベース]]にその[[証明書]]を保存することになっています。 [[中間証明書]]があれば、信頼されていない [[CA]] として追加されることになっています。 [SEE[ [[証明書ダウンロード]] ]] [HISTORY[ [10] [[HTML]] の [CODE(HTMLe)@en[[[keygen]]]] [[要素]]が含まれる[[フォームの提出]]を行うと、 [[公開鍵]]を[[サーバー]]に送信し、[[秘密鍵]]を[[ローカル鍵データベース]]に保存することになっています。 [SEE[ [CODE(HTMLe)@en[[[keygen]]]] ]] ]HISTORY] ** サーバー証明書 [121] [[Webサーバー]]は [[TLS]] に対応しているものが多く、 其の場合[[サーバー証明書]]とそれに連なる [[CA証明書]]、 [[サーバー証明書]]に対応する[[秘密鍵]]を保持している必要があります。 [122] 多くのサーバーの実装は、 [[設定ファイル]]に[[証明書]]の[[ファイル]]の[[パス]]を記述する方式をとっています。 接続された [[IPアドレス]]や[[ポート]]、 [[SNI]] で指定された[[ホスト]]で分岐できるものが多いようです。 ** ルート以外の CA 証明書 [124] [[サーバー]]として動作する場合の[[サーバー証明書]]や[[クライアント]]として動作する場合の[[クライアント証明書]]には、 それに連なる[[中間証明書]]を添えることが [[TLS]] プロトコル上必要となります。そのためこれらを保持しておく必要があります。 [8] それ以外、つまり[[サーバー]]として動作する場合の[[クライアント]]用[[中間証明書]]や、 [[クライアント]]として動作する場合の[[サーバー]]用[[中間証明書]]は、 [[TLS]] プロトコル上相手方から提供されるのであって、 自身が保持しているものを使うことはありません。 しかし実装によってはその検証結果をキャッシュしていることがあります。 ;; [120] 設定不備などで、相手方からすべての[[中間証明書]]が送られてこないことがあります。 そのとき[[証明書の検証]]は失敗することが期待されています。 ところが古い一部の実装では、 事前に別のアクセスで[[中間証明書]]の検証結果がキャッシュされているとき、 それを流用して検証に成功してしまうことがありました。 設定した人を含む一部の人は検証結果を保持していて想定通りにアクセスできてしまい、 それ以外の人はエラーでアクセスできず、 原因究明しがたいトラブルが生じていました。 [9] [[証明書ダウンロード]]仕様では、ダウンロードしたファイルに含まれていた[[中間証明書]]を信頼していない[[証明書]]として証明書データベースに追加することとなっています。 ** S/MIME 証明書 [12] [[証明書ダウンロード]]仕様では、 [[S/MIME]] 用の[[証明書]]をダウンロードすると、 [[証明書データベース]]にその[[証明書]]を保存することになっています。 [SEE[ [[証明書ダウンロード]] ]] [13] これは他人に [[S/MIME]] で[[電子メール]]を送る時に使うものです。 直接または間接に[[電子メール]]の送信に対応していない[[クライアント]]では意味がありません。 ** 失効情報 [23] [[証明書]]自体に加えて、[[証明書]]の[[失効]]情報も保持し、最新に保つ必要があります。 [SEE[ [[失効 (証明書)]] ]] * キャッシュ [32] 実装によっては、 [[ルート証明書]]の情報、 あるいは[[証明書の検証]]の結果を、 一定期間[[キャッシュ]]しているようです。 従って[[プラットフォーム]]に新しい[[ルート証明書]]を追加するなどの変更は、 即座に反映されない場合があります。 [EG[ [33] [[Chrome]] で [[HTTPS]] の[[証明書]]エラーが表示されてから [[Windows]] に[[ルート証明書]]を追加し、 [[再読込]]しても、 エラーのままになります。 [34] しかし新しい[[シークレットウィンドウ]]で開くと、 エラーなく正常に表示されます。 通常の[[窓]]と[[シークレットウィンドウ]]は別[[セッション]]扱いで、 [[キャッシュ]]が共有されていないためとみられます。 ]EG] [123] >>8 も参照。 * 標準データベース [87] 一般[[利用者]]が自分で[[ルート証明書]]を収集して設定するのは現実的ではありません。 [[OS]] 事業者や[[Webブラウザー事業者]]は、 各社の[[ルート証明書]]集を維持管理しています。 [[OS]] や[[Webブラウザー]]は既定の状態でその[[ルート証明書]]集がインストールされた状態の[[証明書データベース]]を持っています。 ** ルート証明書追加ポリシー [47] 各種の [[OS]] や [[Webブラウザー]]の事業者は、自身の製品に含める[[ルート証明書]]について基準を設けて公表しています。 各[[ルートCA]]は各基準に従い運用していることを事業者に示し、 [[ルート証明書]]を事業者に提供しています。 [48] 各事業者の基準はそれぞれに異なりますが、 [[CA/Browser Forum]] の運用基準や [[WebTrust]] の監査基準に従うこと、またはそれに相当することを求めているものもあります。 [49] いずれにせよ、ほとんどの[[利用者]]は[[ルート証明書]]の選択を完全に[[利用者エージェント]]に委ねていますから、 各事業者が[[ルートCA]]を厳格に審査し信頼できる[[ルート証明書]]のみを含めることが極めて重要です。 [65] 現在の [[Webブラウザー]]は、[[ルート証明書]]を含めるかどうかに加えて、 [[EV証明書]]として扱うかどうかも判断する必要があります。 ;; [66] [[ルートCA]]が[[EV証明書]]のつもりで[[発行]]したかどうかは[[証明書]]の内容から判断できますが ([[EV OID]] 参照)、[[EV]] であると信用する[[ルート証明書]]を使ったもののみが [[Webブラウザー]]上で [[EV証明書]]として表示されます。ですから、 [[EV証明書]]のつもりで購入したものが、ある[[Webブラウザー]]では非 [[EV]] とみなされる可能性はあります。 (実際上、[[EV証明書]]を発行する[[ルートCA]] で [[EV]] 発行元として [[Webブラウザー]]事業者に承認されず、しかし非 [[EV]] の[[ルート証明書]]としては承認されるような事例があるのかどうかはわかりません。) [52] 各事業者は[[ルートCA]]に費用を請求していないようです。 [REFS[ - [43] [CITE@en-US[Info about Root-Embedding Programs - CA Trust Anchors in Browsers/OS]] ([TIME[2015-04-02 12:22:39 +09:00]] 版) - [25] [CITE@en[Mozilla CA Certificate Policy — Mozilla]] ([TIME[2015-04-06 18:34:55 +09:00]] 版) -- [26] [CITE@en[Mozilla CA Certificate Inclusion Policy — Mozilla]] ([TIME[2015-04-06 18:36:16 +09:00]] 版) -- [39] [CITE@en[Mozilla CA Certificate Maintenance Policy — Mozilla]] ([TIME[2015-04-06 23:03:08 +09:00]] 版) -- [40] [CITE@en[Mozilla CA Certificate Enforcement Policy — Mozilla]] ([TIME[2015-04-06 23:03:24 +09:00]] 版) - [44] [CITE@en[Introduction to The Microsoft Root Certificate Program - TechNet Articles - United States (English) - TechNet Wiki]] ([TIME[2015-04-02 12:21:48 +09:00]] 版) -- [51] [CITE@en[Microsoft Root Certificate Program]] ([TIME[2015-04-06 23:20:22 +09:00]] 版) - [45] [CITE[Root Certificate Policy - The Chromium Projects]] ([TIME[2015-04-02 11:12:06 +09:00]] 版) - [46] [CITE@en-US[Apple - Root Certificate Program]] ([[Apple Inc.]] 著, [TIME[2015-04-02 12:22:45 +09:00]] 版) - [5] [CITE@ja[Operaに含まれているルート証明書の取得]] ([[ドキュメント]] 著, [TIME[2015-03-14 20:51:34 +09:00]] 版) ]REFS] [53] [[Chrome]] は [[OS]] が[[ルート証明書]]を持っていれば、それを使うようです。 しかし [[EV]] かどうかの判定は原則として自身で行うようです。 [67] [[ルート証明書]]として事業者が承認したものが [[Webブラウザー]]や [[OS]] に反映されるまでの時差は、製品毎に異なります。自動更新機能がない製品では、 事業者が更新版を提供しても所有者がそれを適用しない可能性もあります。 また更新が行われなくなった古い製品では[[ルート証明書]]の更新も行われません。 そのため[[相互運用性]]の問題が生じることもあります (>>38)。 ;; そのため[[クロスルート証明書]]のような技法が採られることがあります。 [41] [CITE@en-US[Mozilla CA Certificate Policy]] ( ([[Frank Hecker and Kathleen Wilson]] 著, [TIME[2013-12-03 01:48:20 +09:00]] 版)) [FIG(quote)[ [FIGCAPTION[ [42] [CITE[Certificate Authority Program]] ([TIME[2015-04-06 14:29:01 +09:00]] 版) ]FIGCAPTION] > The Certificate Authority Program is designed to make it easier for Netscape customers to get certificates. For more information on getting a personal certificate, check out the Certificate Authorities that are currently offering client and server certificate services. > The Certificate Authority program is open to Certificate Authorities that meet an established set of criteria. Certificate Authorities may participate at the Premier, Distinguished, and Basic levels, though the Premier level is closed at this time. ]FIG] ** 更新 [88] 多くの[[プラットフォーム]]で、 [[証明書データベース]]の[[ルート証明書]]や[[失効情報][失効 (証明書)]]は、 [[OS]] や [[Webブラウザー]]の[[自動更新]]機能により更新されます。 [89] [[Web]] で利用される[[ルート証明書]]は少しずつ入れ替わっています。 [[Web互換性]]のため[[証明書データベース]]は適宜更新し続けなければなりません。 (>>38) [HISTORY[ [90] [[ガラケー]]は特定少数の[[ルート証明書]]しか保持しておらず、 安価な事業者や新しい事業者の[[証明書]]に対応していなかったため、 [[ガラケー対応]]した [[Webサーバー]]提供事業者が [[HTTPS]] を利用する際の障害になっていました。 ]HISTORY] ** 相互運用性 [36] [[相互運用性]]のためにはすべての[[クライアント]]がまったく同じ[[ルート証明書]]の[[集合]]を保持している必要がありますが、 実際には各[[クライアント]]の開発元や[[クライアント]]を実行する環境のシステム管理者、 末端の[[利用者]]の設定などによって利用できる[[ルート証明書]]は異なります。 [38] 実際に、 [[HTTPS]] で利用される[[サーバー証明書]]が変更され必要な[[ルート証明書]]が変化し、ある日突然[[クライアント]]が正しく動作しなくなるといったトラブルがしばしば起こっています。 [37] 多くの環境で利用できる[[ルート証明書]]を用いた[[証明書]]ほど[[相互運用性]]が高いため、 [[証明書]]を[[発行]]する [[CA]] を選択する基準の一つともなっています。 ;; [72] 往々にしてそのような [[CA]] ほど[[証明書]]の発行手数料は高額です。 [FIG(quote)[ [FIGCAPTION[ [7] [CITE@en[Necko/Differences - MozillaWiki]] ([TIME[2015-03-21 17:34:27 +09:00]] 版) ]FIGCAPTION] > Our SSL CA certificate database is basically a subset of Windows' and Mac OS X's, so our users are probably more likely to encounter certificate error pages unnecessarily. ]FIG] [99] [CITE[Node-v0.10.34がはまったクロスルート証明書とOpenSSLの落とし穴 - ぼちぼち日記]] ([TIME[2015-03-04 23:16:15 +09:00]] 版) [100] [CITE[携帯電話とSSLルート証明書]] ([TIME[2015-02-18 02:34:53 +09:00]] 版) [17] [CITE[gitやcurlやwgetでGitHubにアクセスするとcertification errorになる原因を調べてみた - Dマイナー志向]] ([TIME[2015-03-29 12:43:51 +09:00]] 版) [98] [CITE[RHEL5/CentOS5でGlobalSignのルート証明書が有効期限切れで大騒ぎ - インフラエンジニアway - Powered by HEARTBEATS]] ([TIME[2015-04-06 14:55:45 +09:00]] 版) [FIG(quote)[ [FIGCAPTION[ [101] [CITE[cURL - Extract CA Certs from Mozilla]] ([TIME[2015-02-09 19:02:35 +09:00]] 版) ]FIGCAPTION] > Around early September 2014, Mozilla removed the trust bits from the certs in their CA bundle that were still using RSA 1024 bit keys. This may lead to TLS libraries having a hard time to verify some sites if the library in question doesn't properly support "path discovery" as per RFC 4158. (That includes OpenSSL and GnuTLS.) ]FIG] * データベースの編集 [18] 多くの [[Webブラウザー]]は、[[証明書データベース]]を閲覧したり、 追加や削除を行ったりする[[利用者インターフェイス]]を提供しています。 ;; [21] その機能の一部または全部を [[OS]] に委ねているものもあります。 [19] [[Webブラウザー]]によっては、管理者用の [[API]] 等で[[証明書データベース]]を操作できることがあります。 ** ルート証明書の追加 [79] 普通は[[ルート証明書]]を一般利用者が手動で追加しなければならないことはありませんし、 するべきでもありません。 [80] 例外的に、次のような状況があります。 ([[利用者]]といっても本当の[[末端利用者]]ではなく、 [[システム管理者]]が追加するのが普通かもしれませんが。) [FIG(list)[ - [81] [[イントラネット]]等の対象利用者が限定されるシステムにアクセスする際に、 私的な[[認証局]]が用いられるため、その[[ルート証明書]]を追加する必要がある場合 - [82] [[ネットワーク]]の制約上、 [[MITM proxy]] を利用する必要があり、 その用いる[[ルート証明書]]を追加する必要がある場合 - [84] [[TLS]] を用いる[[アプリケーション]]の開発で、 その場限りの開発用の[[証明書]]を発行して利用する場合に、 その[[ルート証明書]]を追加する必要がある場合 ]FIG] [56] [[プラットフォーム]]によっては、 第三者ソフトウェアが[[ルート証明書]]をデータベースに容易に追加できます。 そのため[[利用者]]が意図せず[[ルート証明書]]をインストールしてしまうことがあり、 実際に被害が発生しています。 [SEE[ [[ルート証明書]] ]] [57] [[プラットフォーム]]はこうした被害を防ぐ仕組みを整備するべきです。 多くの [[Webブラウザー]]は、 事業者によって予め確認された[[ルート証明書]]と、 そうした別途追加された[[ルート証明書]]を区別できるようにしています。 * 代替データベース [117] 特定目的の[[応用]]では専用の[[証明書データベース]]を使うことがあります。 例えば特定の企業システムにアクセスする専用[[クライアント]]は、 当該システム[[サーバー]]と事前に合意した独自の[[ルート証明書]]を使って[[サーバー証明書]]を[[検証]]したり、 それを使って発行された[[クライアント証明書]]を使ったりすることがあります。 [118] [[Webブラウザー]]のような汎用ソフトウェアはそうした特定システム専用に使うことが普通は考えられないので、 [[証明書データベース]]を完全に差し替えて使うことは想定していません。 [119] [[ライブラリー]]やそれを使った[[アプリケーション]]は、 [[証明書データベース]]を指定して使うことができる場合が多いです。 (例えば >>103) -*-*- [126] 標準的なデータベースと専用の[[ルート証明書]]の中間的な事例として、 [[クラウドサービス]]で事業者独自の[[ルート証明書]]を使う事例がままみられます。 通常の [[Webブラウザー]]などで標準の状態で利用できずとも、 独自の[[アプリケーション]]や[[ライブラリー]]で利用する人がそれなりに多いとみられるものです。 [SEE[ 具体例は[[ルート証明書]] ]] * 実装 [24] 実際には一部または全部の機能が [[Webブラウザー]]自身ではなく [[OS]] など外部で実装されていることもあります。 [35] [[Windows]] は [[OS]] の機能として[[証明書データベース]]を持っており、 [[Microsoft]] が[[ルート証明書]]集を管理しています。 [36] [[Apple]] は [[Mac OS]] や [[iOS]] の[[ルート証明書]]集を管理しています。 [37] [[Firefox]] は[[証明書データベース]]を持っています。 [[Mozilla]] が[[ルート証明書]]集を管理しています [SEE[ [[mozilla-ca]] ]]。 [50] 多くの [[Linux]] システムや [[Android]] は [[mozilla-ca]] を利用しています。 [39] [[Chrome]] は[[プラットフォーム]]の[[証明書データベース]]を使います。 独自の制限が [[Chrome]] 側に組み込まれており、 [[プラットフォーム]]で有効と判断されても [[Google]] が安全でないと判断される[[証明書]]は無効となります。 [FIG(short list)[ - [[Java KeyStore]] ]FIG] [FIG(quote)[ [FIGCAPTION[ [60] [CITE@ja[作ろうiモードコンテンツ:主なスペック | サービス・機能 | NTTドコモ]] ([TIME[2015-04-06 15:02:31 +09:00]] 版) ]FIGCAPTION] > 以下7種類の認証局に対応したルート証明書(以下、端末側ルート証明書)が、SSL対応機種にそれぞれ搭載されています。 ]FIG] [FIG(quote)[ [FIGCAPTION[ [58] [CITE@ja[Mobile Creation | ソフトバンクモバイル]] ([TIME[2014-08-29 10:51:46 +09:00]] 版) ]FIGCAPTION] > ルート証明書 > 下記8社31種類のCAが発行したサーバ証明書に対応しています。 ]FIG] ** Unix の証明書ディレクトリー [92] [[Unix]] 系システムは[[ルート証明書]]を配置する[[ディレクトリー]]を持っていますが、 其の場所は [[OS]] ごとに異なります。 [61] [[Linux]] では、 [CODE[/etc/ssl/certs/]] あたりに[[証明書]]が保管されていて、 [[OpenSSL]] などから参照されるのが一般的です。 [FIG(table)[ :os: [[OS]] :dir: [[ディレクトリー]] :file: [[ファイル]] :file:[CODE[/etc/ssl/certs/ca-certificates.crt]] [SRC[>>91]] :os: [[Debian]], [[Ubuntu]], [[Gentoo]] など :dir:[CODE[/etc/ssl/certs]] [SRC[>>91, >>62]] :os:[[SLES10]], [[SLES11]] :dir:[CODE[/etc/pki/tls/certs]] [SRC[>>91, >>62]] :file:[CODE[/etc/pki/tls/certs/ca-bundle.crt]] [SRC[>>91]] :os:[[Fedora]], [[RHEL]]6 :file:[CODE[/etc/ssl/ca-bundle.pem]] [SRC[>>91]] :os:[[OpenSUSE]] :file:[CODE[/etc/pki/tls/cacert.pem]] [SRC[>>91]] :os:[[OpenELEC]] :file:[CODE[/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem]] [SRC[>>91]] :os:[[CentOS]], [[RHEL7]] :file:[CODE[/etc/ssl/cert.pem]] [SRC[>>91]] :os:[[Alpine Linux]] :dir:[CODE[/system/etc/security/cacerts]] [SRC[>>91, >>62]] :os:[[Android]] :dir:[CODE[/usr/local/share/certs]] [SRC[>>91, >>62]] :os:[[FreeBSD]] :dir:[CODE[/etc/openssl/certs]] [SRC[>>91, >>62]] :os:[[NetBSD]] :dir:[CODE[/var/ssl/certs]] [SRC[>>91, >>62]] :os:[[AIX]] ]FIG] [93] [[Debian]] だと [CODE[/etc/ssl/certs]] に [CODE[/etc/ssl/certs/ca-certificates.crt]] があるほかに [CODE[c8763593.0]] みたいな [[CApath]] 用の[[ファイル]]とか [CODE[VeriSign_Class_3_Public_Primary_Certification_Authority_-_G4.pem]] みたいなファイルとかいろいろあります。 [94] 他に [[OpenSSL]] が[[秘密鍵]]用に使う [CODE[/etc/ssl/private]] という[[ディレクトリー]]が [[Debian]] にはあります。 -*-*- [103] [[OpenSSL]] は、 [[証明書データベース]]の位置として、 [DFN[CAfile]], [DFN[CApath]], [DFN[CAstore]] を持っています。 [SRC[>>102]] [111] まず [[CAfile]] から[[証明書]]が探され、 次に [[CApath]] 内から探されます。 [SRC[>>102]] [112] [[CApath]] [[ディレクトリー]]内では、 [[subject]] のハッシュ値に [CODE[.0]], [CODE[.1]] のような数値の[[拡張子]]をつけた[[ファイル名]]が探されます。 [SRC[>>102]] [113] こうしたファイルは [[[CODE[.pem]]ファイル]]形式であることが期待されます。 [SRC[>>102]] [104] 既定モードでは [[CAfile]] が [[OpenSSL]] の[[ディレクトリー]]の [CODE[cert.pem]] [[ファイル]]、 [[CApath]] が [[OpenSSL]] の[[ディレクトリー]]の [CODE[certs]] [[ディレクトリー]]になります。 [SRC[>>102]] [105] 既定モードで[[環境変数]]の [DFN[[CODE[SSL_CERT_FILE]]]], [DFN[[CODE[SSL_CERT_DIR]]]] が指定された場合、それぞれ [[CAfile]], [[CApath]] として使われます。 [SRC[>>102]] [108] [[OpenSSL]] は[[アプリケーション]]が [[CAfile]], [[CApath]], [[CAstore]] を明示的に指定する [[API]] を用意しています。 [SRC[>>102]] [107] [[OpenSSL]] を使う多くの[[プログラミング言語]]の[[ライブラリー]]では、 [[CAfile]] や [[CApath]] を[[アプリケーション]]が明示的に指定するオプションが用意されています。 [[OpenSSL]] を使った[[アプリケーション]]も、 [[コマンドラインオプション]]のような形でこれらを[[利用者]]が明示的に指定する手段を提供しています。 [110] [[Perlモジュール]] [CODE[AnyEvent::TLS]] は [[OpenSSL]] を使うものですが、 [DFN[[CODE[ca_file]]]] として [[CAfile]] を、 [DFN[[CODE[ca_path]]]] として [[CApath]] を指定できます。 [DFN[[CODE[ca_cert]]]] として[[ファイル]]の中身を[[変数]]として与えることもできます。 独自の環境変数 [DFN[[CODE[PERL_ANYEVENT_CA_FILE]]]], [DFN[[CODE[PERL_ANYEVENT_CA_PATH]]]] も用意されています。 [SRC[>>109]] ;; [114] [[アプリケーション]]開発者としては [CODE[ca_cert]] もとても便利な機能です。 [[OpenSSL]] はなぜかこれに相当する機能を提供していないので、 [CODE[AnyEvent::TLS]] はいちいち[[一時ファイル]]を作成しています。 [97] [[Go]] の[[ライブラリー]]は、 [[環境変数]]の [CODE[SSL_CERT_FILE]], [CODE[SSL_CERT_DIR]] で使用する[[ファイル]]や[[ディレクトリー]]を指定できます。 指定がない場合は[[プラットフォーム]]の既定値を使うようです。 [SRC[>>62]] [106] [[CAstore]] は [[URL]] を指定できるようです [SRC[>>102]]。 比較的新しい版の [[OpenSSL]] で追加されたので、 あまり使われておらず、 [[ライブラリー]]の類も対応していないことがおおいようです。 [125] [CODE[AnyEvent::TLS]] には[[クライアント証明書]]用の [DFN[[CODE[cert_file]]]]、 それに対応する[[秘密鍵]]用の [DFN[[CODE[key_file]]]]、 それを[[文字列値]]として指定する [DFN[[CODE[cert]]]], [DFN[[CODE[key]]]] を指定できます。 [SRC[>>109]] [128] [[curl]] は[[プラットフォーム]]や [[TLS]]/[[PKI]] のライブラリーによって挙動が違います。 [[サーバー証明書]]の[[検証]]に使う[[証明書]]を指定するものに、 [[コマンドラインオプション]]の [DFN[[CODE[--cacert]]]], [DFN[[CODE[--capath]]]] と[[環境変数]] [DFN[[CODE[CURL_CA_BUNDLE]]]] があります。 また [[Windows]] では [CODE[curl.exe]], [[現在ディレクトリー]]、 [[環境変数]] [CODE[PATH]] の [DFN[[CODE[curl-ca-bundle.crt]]]] という名前のファイルを探します。 [[クライアント証明書]]や[[秘密鍵]]を指定するものに、 [[コマンドラインオプション]]の [DFN[[CODE[--key]]]], [DFN[[CODE[--cert]]]], [DFN[[CODE[-E]]]] があります。 [[プロキシ]]接続用に [DFN[[CODE[--proxy-cacert]]]], [DFN[[CODE[--proxy-capath]]]], [DFN[[CODE[--proxy-key]]]], [DFN[[CODE[--proxy-cert]]]] があります。 [SRC[>>127]] [130] [[wget]] には[[コマンドラインオプション]] [DFN[[CODE[--ca-certificate]]]], [DFN[[CODE[--ca-directory]]]], [DFN[[CODE[--certificate]]]], [DFN[[CODE[--private-key]]]]、 設定ファイルの項目 [DFN[[CODE[ca_certificate]]]], [DFN[[CODE[ca_directory]]]], [DFN[[CODE[certificate]]]], [DFN[[CODE[private_key]]]] があります。 [SRC[>>129]] [132] [[Streamlink]] には[[コマンドラインオプション]] [DFN[[CODE[--http-ssl-cert]]]], [DFN[[CODE[--http-ssl-cert-crt-key]]]] があります。 [SRC[>>131]] [137] [CODE[mysql]] ([[MySQL]] 付属のクライアントプログラム) の[[コマンドラインオプション]]に [DFN[[CODE[--ssl-ca]]]], [DFN[[CODE[--ssl-capath]]]], [DFN[[CODE[--ssl-cert]]]], [DFN[[CODE[--ssl-key]]]], [DFN[[CODE[--ssl-crl]]]], [DFN[[CODE[--ssl-crlpath]]]] があります。 -*-*- [96] [[Ubuntu]] には編集用の [DFN[[CODE[update-ca-certificates]]]] [[コマンド]]があります。 [SRC[>>95]] [REFS[ - [102] [CITE@en[/docs/manmaster/man3/SSL_CTX_load_verify_locations.html]], [[OpenSSL Foundation, Inc.]], [TIME[2020-06-01 18:24:15 +09:00]] - [91] [CITE[SSL Certificate Location on UNIX/Linux - Server Fault]], [TIME[2020-06-01 17:50:24 +09:00]] - [95] [CITE@en[Ubuntu Manpage: update-ca-certificates - update /etc/ssl/certs and ca-certificates.crt]], [[Canonical]], [TIME[2020-06-01 18:05:47 +09:00]] - [62] [CITE[src/crypto/x509/root_unix.go - The Go Programming Language]] ([TIME[2015-04-16 18:33:59 +09:00]] 版) - [109] [CITE[lib/AnyEvent/TLS.pm - metacpan.org]], [TIME[2019-09-18 10:11:59 +09:00]] - [127] [CITE[[[curl]] - How To Use]], [TIME[2020-09-21T09:01:13.000Z]], [TIME[2020-10-01T05:48:37.465Z]] - [129] [CITE@en[[[GNU Wget]] 1.20 Manual]], [TIME[2020-10-01T07:24:58.000Z]] - [131] [CITE@en[Command-Line Interface — [[Streamlink]] 1.6.0 documentation]], [TIME[2020-09-30T20:32:48.000Z]], [TIME[2020-10-01T07:51:06.054Z]] ]REFS] ** Mozilla の CA 証明書集 [54] [[オープンソースソフトウェア]]の多くは [[Mozilla]] が管理する[[ルート証明書]]を取り出したものを利用しているようです。 [[Unix]] 系の [[OS]] では大抵標準のパッケージとして提供されています。 [115] [[Mozilla]] が公式に元データの[[テキストファイル]]や [[CSV]] ファイルとして[[ルート証明書]]集を配布しています。 [SRC[>>7]] [116] [[Mozilla]] の公式ではありませんが、 [[Perlモジュール]]として [CODE[Mozilla::CA]] があります [SRC[>>3]]。 [[[CODE[.pem]]ファイル]]の形で定期的に更新されているようです。 ([[[CODE[.pem]]ファイル]]自体は一般的なものなので [[Perl]] 以外でも使えます。) [REFS[ - [4] [CITE[cURL - Extract CA Certs from Mozilla]] ([TIME[2015-02-09 19:02:35 +09:00]] 版) - [3] [CODE[Mozilla::CA]] ]REFS] [55] なお [[Mozilla]] の[[ルート証明書]]の一覧は、 ([[ソースコード]]の他) >>7 にもあります。 [REFS[ - [7] [CITE@en[CA:IncludedCAs - MozillaWiki]] ([TIME[2015-03-21 11:10:02 +09:00]] 版) - [29] [CITE@en[CA:PendingCAs - MozillaWiki]] ([TIME[2015-04-06 13:44:18 +09:00]] 版) ]REFS] ;; [59] [[Mozilla]] は[[中間CA]]は含まず[[ルートCA]]にだけ言及していると思われる箇所でも全般的に単に [[CA]] と呼んでいるようです。 ** Chrome Root Program [134] [CITE@ja[Announcing the [[Chrome Root Program]]]], [TIME[2022-09-30T06:26:25.000Z]] [135] [CITE@en[Chromium Blog: Announcing the Launch of the [[Chrome Root Program]]]], [TIME[2022-09-29T18:28:30.000Z]], [TIME[2022-09-30T06:30:49.168Z]] [136] [CITE[[[Chrome Root Program]] Policy, Version 1.2]], [TIME[2022-09-29T19:41:14.000Z]], [TIME[2022-09-30T06:31:42.798Z]] * セキュリティー [25] [[証明書データベース]]は当該システムにおける [[PKI]] の根幹ですから、 それ自体の[[セキュリティー]]にも極めて重大な配慮が必要です。 [EG[ [26] [[スパイウェア]]や[[ソーシャルハッキング]]などの形で不正な[[ルート証明書]]をシステムにインストールし事前準備した上で、 (本来なら [[TLS]] 等により保護されていたはずの) 他の比較的簡単な手法で攻撃することができるかもしれません。 ]EG] [EG[ [29] [[証明書データベース]]に保存された[[個人証明書]]の[[秘密鍵]]に、 同じシステムで動作する[[スパイウェア]]が[[ファイルシステム]]を通じてアクセスできるかもしれません。 ]EG] [27] 最低でも[[証明書データベース]]に対応する[[ファイルシステム]]上の[[ディレクトリー]]や[[ファイル]]の[[パーミッション]]を適切に設定する必要はありそうです。 [28] [[証明書データベース]]の管理の [[UI]] ([[ルート証明書]]の追加画面など) は、知識のない[[利用者]]が攻撃者の誘導に無思慮に従うことに備える必要があるかもしれません。 [30] [[秘密鍵]]は [[PKCS #12]] のような[[パスワード]]を設定可能な形式で保存すると共に、 [[利用者]]が適切な[[パスワード]]を設定するよう [[UI]] で誘導する必要があるかもしれません。 * メモ [63] [CITE[chrome.platformKeys - Google Chrome]] ([TIME[2015-04-14 13:48:36 +09:00]] 版) [14] [CITE[chrome.enterprise.platformKeys - Google Chrome]] ([TIME[2015-04-14 13:48:46 +09:00]] 版) [15] [CITE[Developer Guide: Certificate Management Extension API on Chrome OS - The Chromium Projects]] ([TIME[2015-04-14 09:20:04 +09:00]] 版) [16] [CITE[Mozilla または Firefox ブラウザへの証明書の読み込み (Service Registry 3.1 ユーザーズガイド (2006Q4))]] ([TIME[2011-02-03 21:53:18 +09:00]] 版) [69] [CITE@ja[Certificate pinningの実装におけるPrivate trust anchorの判定について調べてみる - ももいろテクノロジー]] ([TIME[2015-06-06 22:08:32 +09:00]] 版) [FIG(quote)[ [FIGCAPTION[ [70] [CITE[Security FAQ - The Chromium Projects]] ([TIME[2015-06-06 06:30:25 +09:00]] 版) ]FIGCAPTION] > To enable certificate chain validation, Chrome has access to two stores of trust anchors: certificates that are empowered as issuers. One trust anchor store is the system or public trust anchor store, and the other other is the local or private trust anchor store. The public store is provided as part of the operating system, and intended to authenticate public internet servers. The private store contains certificates installed by the user or the administrator of the client machine. Private intranet servers should authenticate themselves with certificates issued by a private trust anchor. > Chrome’s key pinning feature is a strong form of web site authentication that requires a web server’s certificate chain not only to be valid and to chain to a known-good trust anchor, but also that at least one of the public keys in the certificate chain is known to be valid for the particular site the user is visiting. This is a good defense against the risk that any trust anchor can authenticate any web site, even if not intended by the site owner: if an otherwise-valid chain does not include a known pinned key (“pin”), Chrome will reject it because it was not issued in accordance with the site operator’s expectations. ]FIG] [74] [CITE@ja[Equifax 1024 ビットルート証明書への信頼が打ち切られます | Firefox サイト互換性情報]] ([TIME[2015-11-05 06:12:09 +09:00]] 版) [133] [CITE[Chrome Root Program - The Chromium Projects]], [TIME[2020-11-12T16:27:03.000Z]], [TIME[2020-11-13T11:16:00.612Z]]