公開鍵の作業は広く用いられている仕組みであるため、多数の公開鍵が流通して いるのが現状です。このシステムをうまく動かすには、それぞれのユーザが互いの 間違いのない公開鍵を知っておく必要があることから、信頼できる機関が各ユーザ の公開鍵を検証し、その検証結果を機関の公開鍵付きの証明書で示す必要が あります。このような証明書には公開鍵のほか、証明書を発行した機関のデジタル 証明書が含まれます。

公開鍵を含む証明書に対して、公開や署名を行なう信頼機関は、証明書の発行や 取り消し、更新などの証明書管理に対しても責任を持つ機関で、証明書の仕組みに おける重要な役割を担っています。このような仕組みを 公開鍵 インフラストラクチャ や PKI などと呼びます。 PKI として知られているものの 1 つに、 OpenPGP というものがあります。これは中央の認証ポイントを用意することなく、証明書 を自由に発行できる仕組みです。これらの証明書は、 「既に信頼済みの」 他者が署名することによって信頼を受けることができます。

X.509 公開鍵インフラストラクチャ (PKIX) は IETF (Internet Engineering Task Force) が定義するもう 1 つのモデルで、現在ではほとんどすべての公開鍵ベースの PKI のモデルとして 使用されています。このモデルでは、認証は 証明機関 (CA) と呼ばれる機関が階層構造の形で実施します。もっとも根幹にある CA をルート CA と呼び、すべての子 CA (下位 CA) の正当性を証明します。もっとも階層の低い (木構造で言うところの末端) の CA が、ユーザに対する証明書を発行します。 ユーザの証明書はルート CA から順に証明構造をたどることによって、正当性を 検証することができるようになっています。

このように、 PKI の仕組みは CA の証明書の信頼性に依存した作りになっています。 PKI の利用者に対して証明書の発行基準を明らかにするため、 PKI の運用者は 認証局運用規定 (CPS) を規定し、証明書の管理手順を 表明しておくのがよいでしょう。これにより、 PKI が信頼性のある証明書を 発行できるかどうかを確認することができます。

X.509 証明書は複数のフィールドから構成されるデータ構造で、任意の拡張を 含むこともできるようになっています。固定のフィールドには主に鍵の所有者に 関する情報や公開鍵、発行元の CA に関する情報 (名前と署名) などがあります。 セキュリティ上の理由から、証明書は有効期限が限定されているべきもので、 有効期限を示すフィールドも証明書内に存在しています。 CA は、この有効期限 が切れるまでの間、証明書の正当性を保証することになります。また、 CPS についても、有効期限が切れるまでに新しい証明書を作成して配布する必要が あることから、 PKI (発行元 CA) で必要になります。

拡張フィールドには任意の追加情報を含めることができます。その項目が critical (重要) であるものと記されている場合にのみ、 項目を解釈するためのアプリケーションが必要となります。アプリケーションが 重要項目を解釈できない場合、証明書を拒否しなければなりません。また、拡張に よっては、署名や暗号化など、特定のアプリケーションに有用な項目です。

表 16.1 では、バージョン 3 の X.509 証明書で使用される基本的な項目について 説明を記しています。

証明書が有効期限切れよりも前に信頼のできない状態になってしまった場合、 それらの証明書は即時に無効化されなければなりません。このような措置は、 たとえば機密鍵が誤って漏洩してしまったような場合があげられます。証明書の 無効化は、特に機密鍵がユーザの証明書ではなく CA に属するものであるような 場合に重要です。この場合、その CA で発行されたすべてのユーザ証明書は 即時に無効化されなければなりません。証明書が無効化されると PKI (対象の CA) は、その無効化情報を 証明書失効リスト (CRL) を利用して配布しなければなりません。

これらの一覧は、 CA が一定の間隔で提供するもので、公式の CRL 配布 ポイント (CDP) と呼ばれる箇所に配置されます。 CDP には任意で証明書内の 拡張を命名することもできるため、確認を行ないたい利用者は検証目的で現在の CRL にアクセスすることができます。これを オンライン証明書状態 プロトコル (OCSP) と呼びます。なお CRL の正当性は、 CA 自身が 発行する署名によって保証をおこうなことになります。 表 16.2 には、 X.509 CRL で使用する基本的な項目を示しています。

CA における証明書と CRL は、 リポジトリ を介して 広くアクセスできなければなりません。証明書や CRL は、自身の偽造を防ぐ目的 で署名されていることから、リポジトリ自身を特別な方法で保護したりする必要 はありません。その代わり、できるだけシンプルかつ高速なアクセス手段を提供 する必要があります。この理由から、証明書は LDAP や HTTP サーバ上で提供する のがよいでしょう。 LDAP についての説明は 第4章 ディレクトリサービス LDAP をお読みください。また、 第20章 Apache HTTP サーバ (↑リファレンス) には HTTP サーバに関する情報が記載されています。

YaST には X.509 証明書を管理するための基本的な機能を提供するモジュール があります。これは CA や副 CA の作成のほか、それらの証明書を作成する 機能も備えています。 PKI のサービスは単純に証明書や CRL を作成したり 配布したりするだけではなく、証明書や CRL の更新を継続して行なうための厳密に 設計された管理構造を必要とします。このような構造は商用の PKI 製品として 提供されていて、部分的ではありますがこれらを自動化することができます。 YaST では CA や証明書の作成や配布機能を提供していますが、現時点では 上述の管理構造までは提供していません。小規模な PKI を構築するにあたっては YaST のモジュールで十分ですが、 「公式の」 PKI や商用目的の PKI を構築する場合は、製品のご利用をお勧めします。

PKI を設定するにあたっての最初の手順は、ルート CA を作成することです。 下記の手順で行なってください:

一般的には、ルート CA に対してユーザの証明書を発行するのは不適切です。 少なくとも 1 段階の副 CA を用意し、ユーザ証明書はその副 CA から発行して ください。このようにすることで、ルート CA が独立した存在となるため、 機密の保護がより容易になり、ルート CA への攻撃が非常に難しいものとなります。

お使いの CA に対するパスワードを変更するには、下記の手順で行ないます:

下位 CA の作成方法は、ルート CA と全く同じです。

ただし、下位 CA の有効期限は、 「親の (下位 CA の発行元の)」 CA の有効期限内に存在しなければならないことに注意してください。下位 CA は 常に 「親の」 CA より後に作成しなければならないため、既定値の まま作成しようとするとエラーメッセージが表示されてしまいます。このような エラーを避けるには、有効期限の値を許容範囲内で設定してください。

下記の手順で行ないます:

クライアントやサーバの証明書の作成は、 16.2.1項 「ルート CA の作成」 で説明している CA の作成ととてもよく似ていて、同じようなやり方で作成することができます。 たとえば電子メール署名用の証明書であれば、電子メールのプログラムに取り込む 際、そのユーザのメールアドレス (機密鍵の所有者) が証明書に書かれていなければ なりません。また、暗号化の際に証明書を利用するような場合では、受信者 (公開鍵 の所有者) 電子メールアドレスが証明書に書かれていなければなりません。 サーバやクライアントに対する証明書の場合は、それぞれサーバやクライアントの ホスト名が 共通名 に書かれていなければなりません。 いずれの場合も、有効期限の既定値は 365 日です。

サーバやクライアントの証明書を作成するには、下記の手順で行ないます:

誤って発行してしまったりした不要な証明書を取り消すには、下記の手順で行ないます:

なお、取り消しの作業だけでは、証明書を無効化することができません。 CRL 内に取り消した証明書の情報を配布する必要があります。 CRL の作成 方法については 16.2.6項 「証明書失効リスト (CRL) の作成」 を お読みください。 CRL に公開したあとであれば、 削除 ボタンで取り消した証明書を完全に消去できるようになります。

今までこれまでの章では、下位 CA やクライアント、サーバの各証明書の作成 手順を説明してきました。 X.509 の証明書の拡張部分を扱うには、特別な設定が 必要となります。これらの値にはそれぞれ既定値が存在していて、特段の理由が 無い限り変更すべきではありません。しかしながら、特別な理由から変更をする 必要がある場合があります。このような場合は既定値を変更してください。 それ以外の場合は、証明書の作成時に毎回設定してください。

ここで設定した既定値は、これ以降に作成した証明書だけに適用されます。 既に存在する CA や証明書については、変更は行ないません。

証明書を誤って発行してしまった場合など、不要な証明書は使用できないように するため、取り消し処理を行なわなければなりません。それぞれ取り消し処理 の手順については、 16.2.3項 「下位 CA の作成と失効化」 (下位 CA の場合) や 16.2.4項 「ユーザ証明書の作成と失効化」 (ユーザ証明書の場合) で説明を行なっています。それぞれの作業後、 CRL を作成して 取り消した情報を公開しなければなりません。

なお、システムはそれぞれの CA に対して 1 つの CRL のみを管理します。 CRL を 作成したり更新したりするには、下記の手順で行ないます:

CRL を検証することのできるアプリケーションは、 CRL が利用できないような 場合や有効期限が切れているような場合、すべての証明書を受け付けなくなります。 PKI の提供元としては、現在の CRL の有効期限が切れる前に新しい CRL を生成し、 公開する義務を負うことに注意してください。 YaST では、このような作業の 自動化までは行なっていません。

LDAP にエクスポートするには、対象のコンピュータを YaST LDAP クライアント を利用して設定する必要があります。ダイアログの各項目に入力を行なうことで、 使用する LDAP サーバの情報を実行時に取得するようになります。 YaST LDAP クライアントモジュールを利用しない場合は (それでもエクスポート機能は動作 しますが) 、すべての LDAP データを手作業で入力しなければなりません。 また、複数のパスワードを入力する必要もあります (詳しくは 表16.3「LDAP エクスポート時のパスワード」 をお読みください) 。

証明書, CA, CRL をそれぞれ LDAP にエクスポートすることができます。

お使いのコンピュータに CA を管理するためのリポジトリを設定している場合、 このオプションを利用することで、 CA オブジェクトを直接ファイルに作成する ことができます。この場合、 PEM や DER, PKCS12 など、複数の出力形式に 対応しています。 PEM の場合は、証明書とともに鍵を含めるかどうかと、鍵を 暗号化するかどうかを選択することができます。また、 PKCS12 の場合は、 証明パスをあわせてエクスポートすることもできます。

ファイルへのエクスポートは、 LDAP に対する CA のエクスポートや証明書の エクスポートと同じで、 16.2.7項 「LDAP に対する CA オブジェクトのエクスポート」 の手順で作業を行ないます。このとき、 LDAP にエクスポート ではなく ファイルにエクスポート を選択する必要がある ことに注意してください。これにより、出力形式とパスワード、および ファイル名を指定できるようになります。最後に OK を 押すと、指定した場所に証明書が保存されます。

CRL の場合は エクスポート を押した後 ファイルにエクスポート を選択します。あとは出力形式 (PEM または DER) を選択し、出力先パスを指定します。最後に OK を押すと、指定した場所に出力されます。

エクスポート処理は、ファイルシステム内であれば任意の場所を指定できます。 それ以外にも、たとえば USB メモリなど、外部メディアに CA オブジェクトを 保存することもできます。お使いのシステムに内蔵されているハードディスク 以外の場所を指定する場合、一般的には /media 以下に 表示されます。

CA を管理するサーバ上で YaST を利用してサーバ証明書を作成した場合、 メディアなどにエクスポートして対象のサーバに複製する必要があります。 対象のサーバではこれを 共通サーバ証明書 と呼びます。 このインポート作業はインストール中に実施することができるほか、 YaST を利用して後から行なうこともできます。

証明書を正しくインポートするには、 PKCS12 形式のうちのいずれかを利用 する必要があります。

共通サーバ証明書は /etc/ssl/servercerts ディレクトリ内に 保管され、 CA 機能に対応するすべてのサービスから利用できるようになります。 また、この証明書の有効期限が切れた場合も、同じ手順で簡単に入れ替えることが できるようになっています。証明書を入れ替えた後は、対象のサービスを再起動 することで新しい証明書を利用できるようになります。

インポート を選択すると、ファイルシステム内の任意の 場所を選択することができるようになります。インポートの処理はハードディスク のほか、 USB メモリなどの外部メディアも選択することができます。

共通サーバ証明書をインポートするには、下記の手順で行ないます: