gnoMintを使って独自の認証機関を設定する
gnoMintは、独自の認証機関（CA）を簡単に管理できるデスクトップ・アプリケーションだ。多くのセキュア通信テクノロジは、接続先の団体やサービスが成りすましではないことを確認するためにデジタル証明書を使用する。ほとんどの人にとってデジタル証明書を目にするのは、HTTPS Webサイトを開いて、正しいWebサーバに接続したことを検証するために証明書が提示されたときである。
このような証明書を信頼できるのは、信頼されたCAによって署名されているからだ。CAの署名付きの証明書を入手するプロセスはいろいろあるが、一般にCertificate Signing Request（CSR:署名要求）を生成してCAに送信し、CAがこの要求が偽造ではないこと、そして送信者が申し立てどおりの本人であることを検証する。送信者の本人確認のためにCAで実行される検証のレベルはさまざまだ。認証で問題がなければ、CAによってCSRに署名が付けられ、有効な証明書が生成される。Webサイトにやってきたユーザはこの証明書を提示され、そこに記されたCAの署名を確認することで正しいWebサイトに接続したかどうかを検証できる。Webブラウザには信頼関係のあるCAのリスト（および各CAの署名検証用のパブリックキー）が登録されているため、このリストにあるCAによって署名された証明書は有効と考えてよい。
独自のCAを稼働することには、生成する証明書の使い方によっては短所がある。最大の短所は、その証明書をパブリックサーバで使う場合に生じる。このシナリオではサーバに接続中のクライアントにとって、そのサイトから提示された証明書を信頼できるかどうかを知る手段がない。Webブラウザに登録された既知のCAのリストには、この独自のCAに関する情報がないからだ。
証明書をパブリックサーバで使う予定であれば、無料の証明書署名を提供するStartSSLのようなサービスを利用するか、年間20ドル程度で署名付きの証明書を購入できる。
一方で、プライベートサーバへの接続を特定のユーザグループに許可する目的で証明書を使う場合、独自のCAは便利だ。独自のCAを稼働するということは、外部のCAを頼らずに20通の署名付き証明書を2、3時間内で発行できることを意味する。また、発行した証明書を長い期間（極端に言うと数十年でも）有効にすることも可能だ。独自の署名付き証明書を俊敏に生成できれば、サーバだけでなくクライアントの検証にも使える証明書を生成できる。これもメリットの1つだ。たとえば、Webメールインタフェースでは、クライアントの正当性の検証はサーバの正当性の検証と同じぐらい重要だ。また、クライアント・サーバ型アプリケーションでクライアント証明書を使用できれば、セキュリティレベルが高くなる。サーバに不正アクセスするためにはクライアント証明書を偽造しなければならないからだ。
gnoMintの使用
gnoMintのパッケージは、openSUSE、Fedora、またはUbuntuに用意されていない。そこで、バージョン0.5.3のgnoMintを以下のコマンドでソースコードからビルドした。使ったのは64ビット版Fedora 9マシンである。gnoMintでは、GNU Transport Layer Security Libraryを暗号化に使用し、CAに必要なすべての情報を1つのファイルに収めるためにSQLite3を使用する。
$ tar xzvf /.../gnomint-0.5.3.tar.gz $ cd ./gnomint*/ $ ./configure $ make $ sudo make install
以下のgnoMintスクリーンショットは、メインCAとしてexample.comを使ってla.comの証明書要求を生成および署名し、その後この証明書を無効にしたことを示している。また、foo証明書は署名済みだが、aruba.example.comの証明書要求は生成しただけでまだ署名していない。
最近明らかになったDebianのバグは、質の良い乱数データを用意することが強固な暗号にとって絶対条件である事実をよく示す例だ。たとえば、キーを生成するときは、この新しいキーの一部として使われる値が完全に推測不可能であり、誰かがキーを推測しようとしたら膨大な数の値を試さなければ暗号を破れないことが望ましい。gnoMintを試しているうちに、実際に使用する証明書の生成を始める前に強い乱数データを使い切ってしまう可能性がある。ネットワークトラフィックとマウスやキーボードの操作によって乱数データは徐々に回復される。乱数データが不足すると、gnoMintは十分な数がたまるまで処理を待機する。この状態がしばらく続くことがある。
多数の乱数データが必要になるのは、最初に実行する手順、つまり自己署名付き証明書（他の証明書に署名するために使う証明書）を証明書データベースに追加する処理である。gnoMintの機能を試すだけなので質の低い乱数データで十分な場合は、以下のコマンドを実行しよう。gnoMintの応答はずっと機敏になるが、生成されるキーは弱い。使用される乱数データの乱数度が低いため、キーの推測が容易になるからだ。以下のコマンドが効力を持つ間に生成されたキーは、実際の環境で使用してはならない。gnoMintの試用が終わったら、CAを丸ごと削除し、以下のコマンドを逆に実行し、gnoMintを使って本番用の新しいCAとキーのセットをあらためて生成することをお勧めする。
# mv /dev/random /dev/random-real # ln -s /dev/urandom /dev/random
証明書関連の用語（署名要求、信頼チェーンなど）やCAの管理方法に関する知識が既にあれば、gnoMintを使ったCAの生成と使用は簡単である。最初に、[Certificates(証明書)]メニューの[New certificate database(証明書データベースの新規作成)]を選択する。次に、[Certificates]→[Add(追加)]→[Add self-signed CA(自己署名CAの追加)]を選択して、CAそれ自体の自己署名証明書を生成する。表示に従って、新しいCAの場所として国名、都道府県、市町村を入力するが、この他に3つの見慣れない設定項目があって首をひねるかもしれない。組織（organization）、所属部署（organization unit）、ルートCA名(Root CA common name）のことだ。独自のCAの場合、組織と所属部署は自由に決めてかまわない。証明書のCA名（CN）は、認証されるホストのDNSホスト名と一致する必要がある。独自のCAに関してはCNが何であるかすぐにわかるだろうが、HTTPS接続のサーバ側に証明書を生成する場合は、CNをそのサーバ名と間違いなく同じにする必要がある。
CA識別情報の入力を終えたら、ダイアログの次の画面でRSA暗号またはDSA暗号、CAキーのビット長、有効期間（月単位）を選択できる。CA証明書の有効期間は最長50年。キーのビット長は1,024の倍数で指定し、こちらの最大値は5,120だ。
CAを生成した後は、[Certificates]→[Add]→[Add Certificate Request(証明書要求の追加)]を選択する。CA証明書の作成時に入力したものと同じ識別情報を要求するダイアログが表示され、次いでキー長の選択が求められる。証明書の有効期間はCAによって選択されるため、CSRには含まれない。
この段階で、画面には未発行のCSR（上記のスクリーンショットのaruba.example.comなど）が表示される。このCSRを有効な証明書にするには、右クリックして[Sign(署名)]を選択すればよい。証明書の詳細情報が表示され、署名を付けるために使うCA証明書、証明書の有効期間、使用目的を選択することが求められる。以下のスクリーンショットに、以上の一連の設定を終えたダイアログを示す。おかしなことに、CSRに署名を付けるダイアログなのに、ウィンドウタイトルは”New CA”だ。
これで、gnoMintツリービューのCA証明書の下位に新しい証明書が表示される。この署名付き証明書を右クリックし、表示されるメニューから[Export(エクスポート)]を選択すると、以下のスクリーンショットのようなエクスポートのダイアログが表示される。自己署名証明書をApacheで使用する場合は、キーを最初のオプションと3番目のオプションの両方を使ってエクスポートする必要がある。つまり、パブリックな部分とプライベートな部分をPEM形式でエクスポートする。
/etc/httpd/conf.d/ssl.confファイル内にSSLCertificateFileファイルとSSLCertificateKeyFileファイルへのパスが設定される。これらは、Apache Webサーバ用のパブリックキーを含むファイルとプライベートキーを含むファイルだ。PEM形式のパブリックキー（エクスポートのダイアログの最初のオプション）をSSLCertificateFileディレクティブが示すパスにコピーする。今回使ったコンピュータでは、このパスは/etc/pki/tls/certs/localhost.crtだった。さらに、PEM形式のプライベートキー（エクスポートのダイアログの3番目のオプション）をSSLCertificateKeyFileディレクティブが示すパスにコピーする。今回は、このパスは/etc/pki/tls/private/localhost.keyだった。
自己署名証明書をWebサーバに配置した後で、Firefoxを使ってこのWebサイトを開くと、sec_error_unknown_issuerというエラーが発生する。これは、このサイトが使う独自のCAについてFirefoxが何も知らないことが原因だ。この問題を解決するには、gnoMintでCAキーを右クリックし、キーのパブリックな部分のみをPEM形式でエクスポートする。その後で、[Edit(編集)]→[Preferences(設定)]→[Advanced(詳細)]→[Encryption(暗号)]を選択し、[View Certificates(証明書の表示)]ボタンをクリックする。表示されるダイアログで、[Authorities(機関)]タブを選択し、[Import…(インポート…)]ボタンをクリックする。gnoMintからエクスポートしたPEM形式のパブリックキーを開き、[Trust this CA to identify web sites(Webサイトの識別時にこのCAを信頼する)]チェックボックスをオンにし、開いたすべての設定ダイアログの[OK]をクリックして閉じる。これで、この独自のCAの証明書を使うWebサーバをFirefoxで開いてもエラーにはならない。
gnoMintのテスト中に経験した主な問題点は、コンピュータ上の適切な乱数データを使い切ったときにgnoMintのインタフェースが沈黙してしまい、フリーズはしないものの、キーの生成処理や乱数情報をもっと必要とする処理の完了までの残り時間を表示しないことだ。一方で、小規模のCAを稼働するのであれば、OpenSSLコマンドラインユーティリティやその他の低レベル方式を使うよりも、gnoMintを使った方がずっと簡単だとも言える。エクスポートのダイアログに記述された貴重な情報は、意図する使用目的に合った証明書またはキーを作成するためにどの形式を選択すればよいか判断するうえで参考になる。
CAが動作するしくみを概念レベルでおおよそ理解しているなら、gnoMintを使ってかなり短時間で証明書を生成して使用できるだろう。
Ben Martin 10年以上にわたってファイルシステムを研究。博士課程を修了し、現在、libferris、ファイルシステム、検索ソリューションを中心にコンサルティングをしている。
