E

証明書データベース (Web)

[1] Webブラウザーは、証明書データベース (certificate database) (証明書ストア (certificate store) ) を保持しています。

構造

[64] 証明書データベースは、 0個以上の証明書と、 その他関連する一連の情報で構成されます。 具体的には実装によって異なります。

[71] 多くの実装は、 論理的に想定される証明書データベースよりずっと複雑な物理的な構造を持っています。

[73] 例えば、 OSストレージ上に保持するルート証明書集と、 利用者ホームディレクトリー内に保持される追加の証明書と、 Webブラウザーが保持する証明書に関する追加情報と、 Webブラウザーのソースコードにハードコードされた証明書の扱いに関する追加情報、 といった複数の情報源が関与しているかもしれません。


[76] 証明書データベースの内容や設定が適用される範囲は実装次第です。

[78] 異なる利用者が共用できる Webブラウザーでは、 一部または全部が利用者ごとに異なるデータベースを用いることができるかもしれません。

[83] private browsing モードがある Webブラウザーでは、通常モードと異なるデータベースを用いる (必要がある) かもしれません。

[86] Web 以外の目的と共用の証明書データベースのことも多いです。

証明書の種別

[75] 証明書データベースに含まれ得る証明書は、 いくつかの種類があります。 さらにそれぞれの証明書にいくつかの追加情報が付与されます。

ルート証明書

[6] WebブラウザーTLS を実装し、 service identity を検証する必要があります。 そのため、証明書の検証に用いるルート証明書群を保持する必要があります。

[22] 証明書ダウンロード仕様では、利用者が信頼することにした証明書証明書データベースに追加することになっています。 証明書ダウンロード

[31] Webブラウザー等のTLSクライアントルートCA証明書に次のメタデータを付与して管理しています。

EV証明書用であるか否か
EV 表示するかの判定に使います。
trust bits
適用対象のアプリケーションを表します。
システムに組み込まれた証明書か否か
Pin Validation で使います。

[85] 特定の証明書は特定のドメイン起源でのみ利用するよう設定できるかもしれません。

[77] Web 以外の応用と共用の証明書データベースでは、 適用対象の応用を限定する設定があるかもしれません。

クライアント証明書

[20] WebブラウザーTLSクライアント認証に対応しているのが普通です。 Webブラウザー以外のクライアントのライブラリーや汎用アプリケーションも、 多くが対応しています。 クライアント認証を行うためには、クライアント証明書と (あれば) それに連なるCA証明書クライアント証明書に対応する秘密鍵を保持している必要があります。

[11] 証明書ダウンロード仕様では、利用者証明書をダウンロードすると、 それに対応する秘密鍵があれば証明書データベースにその証明書を保存することになっています。 中間証明書があれば、信頼されていない CA として追加されることになっています。 証明書ダウンロード

[10] HTMLkeygen 要素が含まれるフォームの提出を行うと、 公開鍵サーバーに送信し、秘密鍵ローカル鍵データベースに保存することになっています。 keygen

サーバー証明書

[121] WebサーバーTLS に対応しているものが多く、 其の場合サーバー証明書とそれに連なる CA証明書サーバー証明書に対応する秘密鍵を保持している必要があります。

[122] 多くのサーバーの実装は、 設定ファイル証明書ファイルパスを記述する方式をとっています。 接続された IPアドレスポートSNI で指定されたホストで分岐できるものが多いようです。

ルート以外の CA 証明書

[124] サーバーとして動作する場合のサーバー証明書クライアントとして動作する場合のクライアント証明書には、 それに連なる中間証明書を添えることが TLS プロトコル上必要となります。そのためこれらを保持しておく必要があります。

[8] それ以外、つまりサーバーとして動作する場合のクライアント中間証明書や、 クライアントとして動作する場合のサーバー中間証明書は、 TLS プロトコル上相手方から提供されるのであって、 自身が保持しているものを使うことはありません。 しかし実装によってはその検証結果をキャッシュしていることがあります。

[120] 設定不備などで、相手方からすべての中間証明書が送られてこないことがあります。 そのとき証明書の検証は失敗することが期待されています。 ところが古い一部の実装では、 事前に別のアクセスで中間証明書の検証結果がキャッシュされているとき、 それを流用して検証に成功してしまうことがありました。 設定した人を含む一部の人は検証結果を保持していて想定通りにアクセスできてしまい、 それ以外の人はエラーでアクセスできず、 原因究明しがたいトラブルが生じていました。

[9] 証明書ダウンロード仕様では、ダウンロードしたファイルに含まれていた中間証明書を信頼していない証明書として証明書データベースに追加することとなっています。

S/MIME 証明書

[12] 証明書ダウンロード仕様では、 S/MIME 用の証明書をダウンロードすると、 証明書データベースにその証明書を保存することになっています。 証明書ダウンロード

[13] これは他人に S/MIME電子メールを送る時に使うものです。 直接または間接に電子メールの送信に対応していないクライアントでは意味がありません。

失効情報

[23] 証明書自体に加えて、証明書失効情報も保持し、最新に保つ必要があります。 失効 (証明書)

キャッシュ

[32] 実装によっては、 ルート証明書の情報、 あるいは証明書の検証の結果を、 一定期間キャッシュしているようです。 従ってプラットフォームに新しいルート証明書を追加するなどの変更は、 即座に反映されない場合があります。

[33] ChromeHTTPS証明書エラーが表示されてから Windowsルート証明書を追加し、 再読込しても、 エラーのままになります。

[34] しかし新しいシークレットウィンドウで開くと、 エラーなく正常に表示されます。 通常のシークレットウィンドウは別セッション扱いで、 キャッシュが共有されていないためとみられます。

[123] >>8 も参照。

標準データベース

[87] 一般利用者が自分でルート証明書を収集して設定するのは現実的ではありません。 OS 事業者やWebブラウザー事業者は、 各社のルート証明書集を維持管理しています。 OSWebブラウザーは既定の状態でそのルート証明書集がインストールされた状態の証明書データベースを持っています。

ルート証明書追加ポリシー

[47] 各種の OSWebブラウザーの事業者は、自身の製品に含めるルート証明書について基準を設けて公表しています。 各ルートCAは各基準に従い運用していることを事業者に示し、 ルート証明書を事業者に提供しています。

[48] 各事業者の基準はそれぞれに異なりますが、 CA/Browser Forum の運用基準や WebTrust の監査基準に従うこと、またはそれに相当することを求めているものもあります。

[49] いずれにせよ、ほとんどの利用者ルート証明書の選択を完全に利用者エージェントに委ねていますから、 各事業者がルートCAを厳格に審査し信頼できるルート証明書のみを含めることが極めて重要です。

[65] 現在の Webブラウザーは、ルート証明書を含めるかどうかに加えて、 EV証明書として扱うかどうかも判断する必要があります。

[66] ルートCAEV証明書のつもりで発行したかどうかは証明書の内容から判断できますが (EV OID 参照)、EV であると信用するルート証明書を使ったもののみが Webブラウザー上で EV証明書として表示されます。ですから、 EV証明書のつもりで購入したものが、あるWebブラウザーでは非 EV とみなされる可能性はあります。 (実際上、EV証明書を発行するルートCAEV 発行元として Webブラウザー事業者に承認されず、しかし非 EVルート証明書としては承認されるような事例があるのかどうかはわかりません。)

[52] 各事業者はルートCAに費用を請求していないようです。

[53] ChromeOSルート証明書を持っていれば、それを使うようです。 しかし EV かどうかの判定は原則として自身で行うようです。

[67] ルート証明書として事業者が承認したものが WebブラウザーOS に反映されるまでの時差は、製品毎に異なります。自動更新機能がない製品では、 事業者が更新版を提供しても所有者がそれを適用しない可能性もあります。 また更新が行われなくなった古い製品ではルート証明書の更新も行われません。 そのため相互運用性の問題が生じることもあります (>>38)。

そのためクロスルート証明書のような技法が採られることがあります。

[41] Mozilla CA Certificate Policy ( (Frank Hecker and Kathleen Wilson 著, 版)) http://www.mozilla.org/projects/security/certs/policy/

[42] Certificate Authority Program ( 版) http://web.archive.org/web/19970727173502/http://home.netscape.com/assist/security/certificates/caprogram.html

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] 多くのプラットフォームで、 証明書データベースルート証明書失効情報は、 OSWebブラウザー自動更新機能により更新されます。

[89] Web で利用されるルート証明書は少しずつ入れ替わっています。 Web互換性のため証明書データベースは適宜更新し続けなければなりません。 (>>38)

[90] ガラケーは特定少数のルート証明書しか保持しておらず、 安価な事業者や新しい事業者の証明書に対応していなかったため、 ガラケー対応した Webサーバー提供事業者が HTTPS を利用する際の障害になっていました。

相互運用性

[36] 相互運用性のためにはすべてのクライアントがまったく同じルート証明書集合を保持している必要がありますが、 実際には各クライアントの開発元やクライアントを実行する環境のシステム管理者、 末端の利用者の設定などによって利用できるルート証明書は異なります。

[38] 実際に、 HTTPS で利用されるサーバー証明書が変更され必要なルート証明書が変化し、ある日突然クライアントが正しく動作しなくなるといったトラブルがしばしば起こっています。

[37] 多くの環境で利用できるルート証明書を用いた証明書ほど相互運用性が高いため、 証明書発行する CA を選択する基準の一つともなっています。

[72] 往々にしてそのような CA ほど証明書の発行手数料は高額です。
[7] Necko/Differences - MozillaWiki ( 版) https://wiki.mozilla.org/Necko/Differences

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

[101] cURL - Extract CA Certs from Mozilla ( 版) http://curl.haxx.se/docs/caextract.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ブラウザーは、証明書データベースを閲覧したり、 追加や削除を行ったりする利用者インターフェイスを提供しています。

[21] その機能の一部または全部を OS に委ねているものもあります。

[19] Webブラウザーによっては、管理者用の API 等で証明書データベースを操作できることがあります。

ルート証明書の追加

[79] 普通はルート証明書を一般利用者が手動で追加しなければならないことはありませんし、 するべきでもありません。

[80] 例外的に、次のような状況があります。 (利用者といっても本当の末端利用者ではなく、 システム管理者が追加するのが普通かもしれませんが。)

[56] プラットフォームによっては、 第三者ソフトウェアがルート証明書をデータベースに容易に追加できます。 そのため利用者が意図せずルート証明書をインストールしてしまうことがあり、 実際に被害が発生しています。 ルート証明書

[57] プラットフォームはこうした被害を防ぐ仕組みを整備するべきです。 多くの Webブラウザーは、 事業者によって予め確認されたルート証明書と、 そうした別途追加されたルート証明書を区別できるようにしています。

代替データベース

[117] 特定目的の応用では専用の証明書データベースを使うことがあります。 例えば特定の企業システムにアクセスする専用クライアントは、 当該システムサーバーと事前に合意した独自のルート証明書を使ってサーバー証明書検証したり、 それを使って発行されたクライアント証明書を使ったりすることがあります。

[118] Webブラウザーのような汎用ソフトウェアはそうした特定システム専用に使うことが普通は考えられないので、 証明書データベースを完全に差し替えて使うことは想定していません。

[119] ライブラリーやそれを使ったアプリケーションは、 証明書データベースを指定して使うことができる場合が多いです。 (例えば >>103)


[126] 標準的なデータベースと専用のルート証明書の中間的な事例として、 クラウドサービスで事業者独自のルート証明書を使う事例がままみられます。 通常の Webブラウザーなどで標準の状態で利用できずとも、 独自のアプリケーションライブラリーで利用する人がそれなりに多いとみられるものです。 具体例はルート証明書

実装

[24] 実際には一部または全部の機能が Webブラウザー自身ではなく OS など外部で実装されていることもあります。

[35] WindowsOS の機能として証明書データベースを持っており、 Microsoftルート証明書集を管理しています。

[36] AppleMac OSiOSルート証明書集を管理しています。

[37] Firefox証明書データベースを持っています。 Mozillaルート証明書集を管理しています mozilla-ca

[50] 多くの Linux システムや Androidmozilla-ca を利用しています。

[39] Chromeプラットフォーム証明書データベースを使います。 独自の制限が Chrome 側に組み込まれており、 プラットフォームで有効と判断されても Google が安全でないと判断される証明書は無効となります。

[60] 作ろうiモードコンテンツ:主なスペック | サービス・機能 | NTTドコモ ( 版) https://www.nttdocomo.co.jp/service/developer/make/content/ssl/spec/

以下7種類の認証局に対応したルート証明書(以下、端末側ルート証明書)が、SSL対応機種にそれぞれ搭載されています。

[58] Mobile Creation | ソフトバンクモバイル ( 版) http://creation.mb.softbank.jp/mc/tech/tech_web/web_ssl.html

ルート証明書

下記8社31種類のCAが発行したサーバ証明書に対応しています。

Unix の証明書ディレクトリー

[92] Unix 系システムはルート証明書を配置するディレクトリーを持っていますが、 其の場所は OS ごとに異なります。

[61] Linux では、 /etc/ssl/certs/ あたりに証明書が保管されていて、 OpenSSL などから参照されるのが一般的です。

os
OS
dir
ディレクトリー
file
ファイル
file
/etc/ssl/certs/ca-certificates.crt >>91
os
Debian, Ubuntu, Gentoo など
dir
/etc/ssl/certs >>91, >>62
os
SLES10, SLES11
dir
/etc/pki/tls/certs >>91, >>62
file
/etc/pki/tls/certs/ca-bundle.crt >>91
os
Fedora, RHEL6
file
/etc/ssl/ca-bundle.pem >>91
os
OpenSUSE
file
/etc/pki/tls/cacert.pem >>91
os
OpenELEC
file
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem >>91
os
CentOS, RHEL7
file
/etc/ssl/cert.pem >>91
os
Alpine Linux
dir
/system/etc/security/cacerts >>91, >>62
os
Android
dir
/usr/local/share/certs >>91, >>62
os
FreeBSD
dir
/etc/openssl/certs >>91, >>62
os
NetBSD
dir
/var/ssl/certs >>91, >>62
os
AIX

[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] 既定モードでは CAfileOpenSSLディレクトリーcert.pem ファイルCApathOpenSSLディレクトリーcerts ディレクトリーになります。 >>102

[105] 既定モードで環境変数SSL_CERT_FILE, SSL_CERT_DIR が指定された場合、それぞれ CAfile, CApath として使われます。 >>102

[108] OpenSSLアプリケーションCAfile, CApath, CAstore を明示的に指定する API を用意しています。 >>102

[107] OpenSSL を使う多くのプログラミング言語ライブラリーでは、 CAfileCApathアプリケーションが明示的に指定するオプションが用意されています。 OpenSSL を使ったアプリケーションも、 コマンドラインオプションのような形でこれらを利用者が明示的に指定する手段を提供しています。

[110] Perlモジュール AnyEvent::TLSOpenSSL を使うものですが、 ca_file として CAfile を、 ca_path として CApath を指定できます。 ca_cert としてファイルの中身を変数として与えることもできます。 独自の環境変数 PERL_ANYEVENT_CA_FILE, PERL_ANYEVENT_CA_PATH も用意されています。 >>109

[114] アプリケーション開発者としては ca_cert もとても便利な機能です。 OpenSSL はなぜかこれに相当する機能を提供していないので、 AnyEvent::TLS はいちいち一時ファイルを作成しています。

[97] Goライブラリーは、 環境変数SSL_CERT_FILE, SSL_CERT_DIR で使用するファイルディレクトリーを指定できます。 指定がない場合はプラットフォームの既定値を使うようです。 >>62

[106] CAstoreURL を指定できるようです >>102。 比較的新しい版の OpenSSL で追加されたので、 あまり使われておらず、 ライブラリーの類も対応していないことがおおいようです。

[125] AnyEvent::TLS にはクライアント証明書用の cert_file、 それに対応する秘密鍵用の key_file、 それを文字列値として指定する cert, key を指定できます。 >>109

[128] curlプラットフォームTLS/PKI のライブラリーによって挙動が違います。 サーバー証明書検証に使う証明書を指定するものに、 コマンドラインオプション--cacert, --capath環境変数 CURL_CA_BUNDLE があります。 また Windows では curl.exe, 現在ディレクトリー環境変数 PATHcurl-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


[96] Ubuntu には編集用の update-ca-certificates コマンドがあります。 >>95

Mozilla の CA 証明書集

[54] オープンソースソフトウェアの多くは Mozilla が管理するルート証明書を取り出したものを利用しているようです。 Unix 系の OS では大抵標準のパッケージとして提供されています。

[115] Mozilla が公式に元データのテキストファイルCSV ファイルとしてルート証明書集を配布しています。 >>7

[116] Mozilla 公式ではありませんが、 Perlモジュールとして Mozilla::CA があります >>3.pemファイルの形で定期的に更新されているようです。 (.pemファイル自体は一般的なものなので Perl 以外でも使えます。)

[55] なお Mozillaルート証明書の一覧は、 (ソースコードの他) >>7 にもあります。

[59] Mozilla中間CAは含まずルートCAにだけ言及していると思われる箇所でも全般的に単に CA と呼んでいるようです。

Chrome Root Program

[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 等により保護されていたはずの) 他の比較的簡単な手法で攻撃することができるかもしれません。

[29] 証明書データベースに保存された個人証明書秘密鍵に、 同じシステムで動作するスパイウェアファイルシステムを通じてアクセスできるかもしれません。

[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

[70] Security FAQ - The Chromium Projects ( 版) http://www.chromium.org/Home/chromium-security/security-faq#TOC-How-does-key-pinning-interact-with-local-proxies-and-filters-

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