[1] Webブラウザーは、証明書データベース (証明書ストア) を保持しています。
[64] 証明書データベースは、 0個以上の証明書と、 その他関連する一連の情報で構成されます。 具体的には実装によって異なります。
[71] 多くの実装は、 論理的に想定される証明書データベースよりずっと複雑な物理的な構造を持っています。
[73] 例えば、 OS がストレージ上に保持するルート証明書集と、 利用者のホームディレクトリー内に保持される追加の証明書と、 Webブラウザーが保持する証明書に関する追加情報と、 Webブラウザーのソースコードにハードコードされた証明書の扱いに関する追加情報、 といった複数の情報源が関与しているかもしれません。
[76] 証明書データベースの内容や設定が適用される範囲は実装次第です。
[78] 異なる利用者が共用できる Webブラウザーでは、 一部または全部が利用者ごとに異なるデータベースを用いることができるかもしれません。
[83] private browsing モードがある Webブラウザーでは、通常モードと異なるデータベースを用いる (必要がある) かもしれません。
[75] 証明書データベースに含まれ得る証明書は、 いくつかの種類があります。 さらにそれぞれの証明書にいくつかの追加情報が付与されます。
[6] Webブラウザーは TLS を実装し、 service identity を検証する必要があります。 そのため、証明書の検証に用いるルート証明書群を保持する必要があります。
[22] 証明書ダウンロード仕様では、利用者が信頼することにした証明書を証明書データベースに追加することになっています。
[31] Webブラウザー等のTLSクライアントはルートCA証明書に次のメタデータを付与して管理しています。
[20] WebブラウザーはTLSクライアント認証に対応しているのが普通です。 Webブラウザー以外のクライアントのライブラリーや汎用アプリケーションも、 多くが対応しています。 クライアント認証を行うためには、クライアント証明書と (あれば) それに連なるCA証明書、 クライアント証明書に対応する秘密鍵を保持している必要があります。
[11] 証明書ダウンロード仕様では、利用者の証明書をダウンロードすると、
それに対応する秘密鍵があれば証明書データベースにその証明書を保存することになっています。
中間証明書があれば、信頼されていない CA として追加されることになっています。
[121] Webサーバーは TLS に対応しているものが多く、 其の場合サーバー証明書とそれに連なる CA証明書、 サーバー証明書に対応する秘密鍵を保持している必要があります。
[122] 多くのサーバーの実装は、 設定ファイルに証明書のファイルのパスを記述する方式をとっています。 接続された IPアドレスやポート、 SNI で指定されたホストで分岐できるものが多いようです。
[124] サーバーとして動作する場合のサーバー証明書やクライアントとして動作する場合のクライアント証明書には、 それに連なる中間証明書を添えることが TLS プロトコル上必要となります。そのためこれらを保持しておく必要があります。
[8] それ以外、つまりサーバーとして動作する場合のクライアント用中間証明書や、 クライアントとして動作する場合のサーバー用中間証明書は、 TLS プロトコル上相手方から提供されるのであって、 自身が保持しているものを使うことはありません。 しかし実装によってはその検証結果をキャッシュしていることがあります。
[9] 証明書ダウンロード仕様では、ダウンロードしたファイルに含まれていた中間証明書を信頼していない証明書として証明書データベースに追加することとなっています。
[12] 証明書ダウンロード仕様では、 S/MIME 用の証明書をダウンロードすると、
証明書データベースにその証明書を保存することになっています。
[13] これは他人に S/MIME で電子メールを送る時に使うものです。 直接または間接に電子メールの送信に対応していないクライアントでは意味がありません。
[32] 実装によっては、 ルート証明書の情報、 あるいは証明書の検証の結果を、 一定期間キャッシュしているようです。 従ってプラットフォームに新しいルート証明書を追加するなどの変更は、 即座に反映されない場合があります。
[87] 一般利用者が自分でルート証明書を収集して設定するのは現実的ではありません。 OS 事業者やWebブラウザー事業者は、 各社のルート証明書集を維持管理しています。 OS やWebブラウザーは既定の状態でそのルート証明書集がインストールされた状態の証明書データベースを持っています。
[47] 各種の OS や Webブラウザーの事業者は、自身の製品に含めるルート証明書について基準を設けて公表しています。 各ルートCAは各基準に従い運用していることを事業者に示し、 ルート証明書を事業者に提供しています。
[48] 各事業者の基準はそれぞれに異なりますが、 CA/Browser Forum の運用基準や WebTrust の監査基準に従うこと、またはそれに相当することを求めているものもあります。
[49] いずれにせよ、ほとんどの利用者はルート証明書の選択を完全に利用者エージェントに委ねていますから、 各事業者がルートCAを厳格に審査し信頼できるルート証明書のみを含めることが極めて重要です。
[65] 現在の Webブラウザーは、ルート証明書を含めるかどうかに加えて、 EV証明書として扱うかどうかも判断する必要があります。
[52] 各事業者はルートCAに費用を請求していないようです。
[53] Chrome は OS がルート証明書を持っていれば、それを使うようです。 しかし EV かどうかの判定は原則として自身で行うようです。
[67] ルート証明書として事業者が承認したものが Webブラウザーや OS に反映されるまでの時差は、製品毎に異なります。自動更新機能がない製品では、 事業者が更新版を提供しても所有者がそれを適用しない可能性もあります。 また更新が行われなくなった古い製品ではルート証明書の更新も行われません。 そのため相互運用性の問題が生じることもあります (>>38)。
[41] Mozilla CA Certificate Policy ( (Frank Hecker and Kathleen Wilson 著, 版)) http://www.mozilla.org/projects/security/certs/policy/
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.
[88] 多くのプラットフォームで、 証明書データベースのルート証明書や失効情報は、 OS や Webブラウザーの自動更新機能により更新されます。
[89] Web で利用されるルート証明書は少しずつ入れ替わっています。 Web互換性のため証明書データベースは適宜更新し続けなければなりません。 (>>38)
[36] 相互運用性のためにはすべてのクライアントがまったく同じルート証明書の集合を保持している必要がありますが、 実際には各クライアントの開発元やクライアントを実行する環境のシステム管理者、 末端の利用者の設定などによって利用できるルート証明書は異なります。
[38] 実際に、 HTTPS で利用されるサーバー証明書が変更され必要なルート証明書が変化し、ある日突然クライアントが正しく動作しなくなるといったトラブルがしばしば起こっています。
[37] 多くの環境で利用できるルート証明書を用いた証明書ほど相互運用性が高いため、 証明書を発行する CA を選択する基準の一つともなっています。
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.
[99] Node-v0.10.34がはまったクロスルート証明書とOpenSSLの落とし穴 - ぼちぼち日記 ( 版) http://d.hatena.ne.jp/jovi0608/20141222/1419265270
[100] 携帯電話とSSLルート証明書 ( 版) http://triaez.kaisei.org/~kaoru/ssl/cell.html
[17] gitやcurlやwgetでGitHubにアクセスするとcertification errorになる原因を調べてみた - Dマイナー志向 ( 版) http://d.hatena.ne.jp/tmatsuu/20110614/1308010044
[98] RHEL5/CentOS5でGlobalSignのルート証明書が有効期限切れで大騒ぎ - インフラエンジニアway - Powered by HEARTBEATS ( 版) http://heartbeats.jp/hbblog/2014/01/rhel5centos5globalsign.html
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.)
[18] 多くの Webブラウザーは、証明書データベースを閲覧したり、 追加や削除を行ったりする利用者インターフェイスを提供しています。
[19] Webブラウザーによっては、管理者用の API 等で証明書データベースを操作できることがあります。
[79] 普通はルート証明書を一般利用者が手動で追加しなければならないことはありませんし、 するべきでもありません。
[80] 例外的に、次のような状況があります。 (利用者といっても本当の末端利用者ではなく、 システム管理者が追加するのが普通かもしれませんが。)
[56]
プラットフォームによっては、
第三者ソフトウェアがルート証明書をデータベースに容易に追加できます。
そのため利用者が意図せずルート証明書をインストールしてしまうことがあり、
実際に被害が発生しています。
[57] プラットフォームはこうした被害を防ぐ仕組みを整備するべきです。 多くの Webブラウザーは、 事業者によって予め確認されたルート証明書と、 そうした別途追加されたルート証明書を区別できるようにしています。
[117] 特定目的の応用では専用の証明書データベースを使うことがあります。 例えば特定の企業システムにアクセスする専用クライアントは、 当該システムサーバーと事前に合意した独自のルート証明書を使ってサーバー証明書を検証したり、 それを使って発行されたクライアント証明書を使ったりすることがあります。
[118] Webブラウザーのような汎用ソフトウェアはそうした特定システム専用に使うことが普通は考えられないので、 証明書データベースを完全に差し替えて使うことは想定していません。
[119] ライブラリーやそれを使ったアプリケーションは、 証明書データベースを指定して使うことができる場合が多いです。 (例えば >>103)
[126]
標準的なデータベースと専用のルート証明書の中間的な事例として、
クラウドサービスで事業者独自のルート証明書を使う事例がままみられます。
通常の
Webブラウザーなどで標準の状態で利用できずとも、
独自のアプリケーションやライブラリーで利用する人がそれなりに多いとみられるものです。
[24] 実際には一部または全部の機能が Webブラウザー自身ではなく OS など外部で実装されていることもあります。
[35] Windows は OS の機能として証明書データベースを持っており、 Microsoft がルート証明書集を管理しています。
[36] Apple は Mac OS や iOS のルート証明書集を管理しています。
[37]
Firefox
は証明書データベースを持っています。
Mozilla
がルート証明書集を管理しています
[50] 多くの Linux システムや Android は mozilla-ca を利用しています。
[39] Chrome はプラットフォームの証明書データベースを使います。 独自の制限が Chrome 側に組み込まれており、 プラットフォームで有効と判断されても Google が安全でないと判断される証明書は無効となります。
以下7種類の認証局に対応したルート証明書(以下、端末側ルート証明書)が、SSL対応機種にそれぞれ搭載されています。
ルート証明書
下記8社31種類のCAが発行したサーバ証明書に対応しています。
[92] Unix 系システムはルート証明書を配置するディレクトリーを持っていますが、 其の場所は OS ごとに異なります。
[61] Linux では、 /etc/ssl/certs/ あたりに証明書が保管されていて、
OpenSSL などから参照されるのが一般的です。
/etc/ssl/certs/ca-certificates.crt >>91/etc/ssl/certs >>91, >>62/etc/openssl/certs >>91, >>62/var/ssl/certs >>91, >>62[93]
Debian
だと
/etc/ssl/certs
に
/etc/ssl/certs/ca-certificates.crt
があるほかに
c8763593.0
みたいな
CApath
用のファイルとか
VeriSign_Class_3_Public_Primary_Certification_Authority_-_G4.pem
みたいなファイルとかいろいろあります。
[94]
他に OpenSSL
が秘密鍵用に使う
/etc/ssl/private
というディレクトリーが
Debian
にはあります。
[103] OpenSSL は、 証明書データベースの位置として、 CAfile, CApath, CAstore を持っています。 >>102
[111] まず CAfile から証明書が探され、 次に CApath 内から探されます。 >>102
[112]
CApath
ディレクトリー内では、
subject
のハッシュ値に
.0,
.1
のような数値の拡張子をつけたファイル名が探されます。
>>102
[113] こうしたファイルは
.pemファイル形式であることが期待されます。
>>102
[104] 既定モードでは
CAfile
が
OpenSSL
のディレクトリーの
cert.pem
ファイル、
CApath
が
OpenSSL
のディレクトリーの
certs
ディレクトリーになります。 >>102
[105]
既定モードで環境変数の
SSL_CERT_FILE,
SSL_CERT_DIR
が指定された場合、それぞれ
CAfile,
CApath
として使われます。 >>102
[108] OpenSSL はアプリケーションが CAfile, CApath, CAstore を明示的に指定する API を用意しています。 >>102
[107] OpenSSL を使う多くのプログラミング言語のライブラリーでは、 CAfile や CApath をアプリケーションが明示的に指定するオプションが用意されています。 OpenSSL を使ったアプリケーションも、 コマンドラインオプションのような形でこれらを利用者が明示的に指定する手段を提供しています。
[110]
Perlモジュール
AnyEvent::TLS
は
OpenSSL
を使うものですが、
ca_file として CAfile を、
ca_path として CApath
を指定できます。
ca_cert
としてファイルの中身を変数として与えることもできます。
独自の環境変数
PERL_ANYEVENT_CA_FILE,
PERL_ANYEVENT_CA_PATH
も用意されています。
>>109
ca_cert
もとても便利な機能です。
OpenSSL
はなぜかこれに相当する機能を提供していないので、
AnyEvent::TLS
はいちいち一時ファイルを作成しています。[97]
Go
のライブラリーは、
環境変数の
SSL_CERT_FILE,
SSL_CERT_DIR
で使用するファイルやディレクトリーを指定できます。
指定がない場合はプラットフォームの既定値を使うようです。
>>62
[106] CAstore は URL を指定できるようです >>102。 比較的新しい版の OpenSSL で追加されたので、 あまり使われておらず、 ライブラリーの類も対応していないことがおおいようです。
[125]
AnyEvent::TLS
にはクライアント証明書用の
cert_file、
それに対応する秘密鍵用の
key_file、
それを文字列値として指定する
cert,
key
を指定できます。
>>109
[128]
curl
はプラットフォームや
TLS/PKI のライブラリーによって挙動が違います。
サーバー証明書の検証に使う証明書を指定するものに、
コマンドラインオプションの
--cacert, --capath
と環境変数
CURL_CA_BUNDLE
があります。
また
Windows
では
curl.exe,
現在ディレクトリー、
環境変数 PATH
の
curl-ca-bundle.crt
という名前のファイルを探します。
クライアント証明書や秘密鍵を指定するものに、
コマンドラインオプションの
--key,
--cert,
-E
があります。
プロキシ接続用に
--proxy-cacert,
--proxy-capath,
--proxy-key,
--proxy-cert
があります。
>>127
[130]
wget
にはコマンドラインオプション
--ca-certificate,
--ca-directory,
--certificate,
--private-key、
設定ファイルの項目
ca_certificate,
ca_directory,
certificate,
private_key
があります。
>>129
[132]
Streamlink
にはコマンドラインオプション
--http-ssl-cert,
--http-ssl-cert-crt-key
があります。
>>131
[137]
mysql (MySQL 付属のクライアントプログラム)
のコマンドラインオプションに
--ssl-ca,
--ssl-capath,
--ssl-cert,
--ssl-key,
--ssl-crl,
--ssl-crlpath
があります。
[96]
Ubuntu
には編集用の
update-ca-certificates
コマンドがあります。
>>95
[54] オープンソースソフトウェアの多くは Mozilla が管理するルート証明書を取り出したものを利用しているようです。 Unix 系の OS では大抵標準のパッケージとして提供されています。
[115] Mozilla が公式に元データのテキストファイルや CSV ファイルとしてルート証明書集を配布しています。 >>7
[116]
Mozilla
公式ではありませんが、
Perlモジュールとして
Mozilla::CA
があります >>3。
.pemファイルの形で定期的に更新されているようです。
(.pemファイル自体は一般的なものなので
Perl
以外でも使えます。)
[55] なお Mozilla のルート証明書の一覧は、 (ソースコードの他) >>7 にもあります。
[134] Announcing the Chrome Root Program, https://groups.google.com/g/mozilla.dev.security.policy/c/3Q36J4flnQs/m/VyWFiVwrBQAJ
[135] Chromium Blog: Announcing the Launch of the Chrome Root Program, , https://blog.chromium.org/2022/09/announcing-launch-of-chrome-root-program.html
[136] Chrome Root Program Policy, Version 1.2, , https://www.chromium.org/Home/chromium-security/root-ca-policy/
[25] 証明書データベースは当該システムにおける PKI の根幹ですから、 それ自体のセキュリティーにも極めて重大な配慮が必要です。
[26] スパイウェアやソーシャルハッキングなどの形で不正なルート証明書をシステムにインストールし事前準備した上で、 (本来なら TLS 等により保護されていたはずの) 他の比較的簡単な手法で攻撃することができるかもしれません。
[27] 最低でも証明書データベースに対応するファイルシステム上のディレクトリーやファイルのパーミッションを適切に設定する必要はありそうです。
[28] 証明書データベースの管理の UI (ルート証明書の追加画面など) は、知識のない利用者が攻撃者の誘導に無思慮に従うことに備える必要があるかもしれません。
[30] 秘密鍵は PKCS #12 のようなパスワードを設定可能な形式で保存すると共に、 利用者が適切なパスワードを設定するよう UI で誘導する必要があるかもしれません。
[63] chrome.platformKeys - Google Chrome ( 版) https://developer.chrome.com/extensions/platformKeys
[14] chrome.enterprise.platformKeys - Google Chrome ( 版) https://developer.chrome.com/extensions/enterprise_platformKeys
[15] Developer Guide: Certificate Management Extension API on Chrome OS - The Chromium Projects ( 版) http://www.chromium.org/administrators/certificate-management-extension-api-on-chrome-os
[16] Mozilla または Firefox ブラウザへの証明書の読み込み (Service Registry 3.1 ユーザーズガイド (2006Q4)) ( 版) https://docs.oracle.com/cd/E19528-01/819-7126/gaesv/index.html
[69] Certificate pinningの実装におけるPrivate trust anchorの判定について調べてみる - ももいろテクノロジー ( 版) http://inaz2.hatenablog.com/entry/2015/02/25/024431
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.
[74] Equifax 1024 ビットルート証明書への信頼が打ち切られます | Firefox サイト互換性情報 ( 版) https://www.fxsitecompat.com/ja/docs/2015/equifax-1024-bit-root-certificate-will-no-longer-be-trusted/
[133] Chrome Root Program - The Chromium Projects, , https://www.chromium.org/Home/chromium-security/root-ca-policy