Sun Java System Messaging Server 6 2005Q4 管理ガイド

暗号化と証明書に基づく認証を構成する

この節では、次の項目に分けて説明しています。

Messaging Server では、クライアントとサーバー間で、暗号化された通信および証明書に基づく認証を行うために TLS (Transport Layer Security) プロトコルを使用します。TLS プロトコルは、SSL (Secure Sockets Layer) プロトコルとも呼ばれます。Messaging Server は、SSL バージョン 3.0 および 3.1 をサポートします。TLS には、SSL との完全な互換性があり、必要な SSL 機能がすべて含まれています。

SSL に関する背景情報については、『Managing Servers with iPlanet Console』の付録の「Introduction to SSL」を参照してください。SSL は、公開キー暗号化の概念に基づいています。この概念については、『Managing Servers with iPlanet Console』の付録の「Introduction to Public-Key Cryptography」を参照してください。

Messaging Server とそのクライアント間、および Messaging Server とほかのサーバー間におけるメッセージの転送が暗号化される場合は、通信が盗聴される危険性はほとんどありません。また、接続しているクライアントが認証済みの場合は、侵入者がそれらのクライアントになりすます (スプーフィングする) 危険性もほとんどありません。

SSL は、IMAP4、HTTP、POP3 および SMTP のアプリケーションレイヤーの下のプロトコルレイヤーとして機能します。SMTP と SMTP/SSL は同じポートを使用しますが、HTTP と HTTP/SSL は異なるポートを必要とします。IMAP と IMAP/SSL、POP と POP/SSL は、同じポートを使用することも異なるポートを使用することもできます。図 19–1 に示すように、SSL は、送信メッセージと着信メッセージの両方で、メッセージ通信の特定の段階で作用します。

図 19–1 Messaging Server での暗号化された通信

この図では、暗号化された受信メッセージおよび送信メッセージを示します。

SSL は、ホップ間の暗号化を提供しますが、中間にある各サーバー上ではメッセージは暗号化されません。


注 –

送信メッセージの暗号化を有効にするには、チャネル定義を変更して、maytlsmusttls などの tls チャネルキーワードを追加する必要があります。詳細は、「Transport Layer Security」のマニュアルを参照してください。


SSL 接続を設定する際のオーバーヘッドによって、サーバーのパフォーマンスが低下する可能性があります。メッセージングシステムの設計とパフォーマンスの分析を行う際には、セキュリティー要件とサーバーのパフォーマンスのバランスをとる必要があります。


注 –

SSL はすべての Sun Java System サーバーでサポートされており、SSL の有効化と設定を行うために使用するコンソールインタフェースは多くのサーバーでほとんど同じです。そのため、この章で説明するタスクのいくつかについては、『Managing Servers with iPlanet Console』に詳しい説明が記載されています。それらのタスクについては、この章では要約だけを説明します。


管理コンソールからの証明書の入手

SSL の用途が暗号化か認証かにかかわらず、Messaging Server 用のサーバー証明書を入手する必要があります。この証明書は、使用するサーバーの識別情報をクライアントやほかのサーバーに提供します。管理コンソールから証明書を入手する場合は、この節の手順に従います。コマンド行モードで自己署名済み証明書を作成する場合は、「自己署名済み証明書を作成するには」を参照してください。

内部モジュールと外部モジュールを管理するには

サーバー証明書によって、キーのペアの所有権と有効性が確立されます。キーのペアは、データの暗号化と解読に使用される数値です。サーバーの証明書とキーのペアは、そのサーバーの識別情報を示します。これらは、サーバー内部または取り外し可能な外部のハードウェアカード (スマートカード) の証明書データベース内に保存されます。

Sun Java System サーバーは、PKCS (Public-Key Cryptography System) #11 API に準拠するモジュールを使用して、キーと証明書のデータベースにアクセスします。通常、特定のハードウェアデバイスの PKCS #11 モジュールは、そのデバイスの供給元から入手できます。Messaging Server でそのデバイスを使用する前に、このモジュールを Messaging Server にインストールする必要があります。Messaging Server にプリインストールされている「Netscape Internal PKCS # 11 Module」は、サーバー内部の証明書データベースを使用する単一の内部ソフトウェアトークンをサポートします。

証明書を使用できるようにサーバーを設定する場合は、証明書とそのキーを格納するためのデータベースを作成し、PKCS #11 モジュールをインストールする必要があります。外部のハードウェアトークンを使用しない場合は、サーバー上に内部データベースを作成し、Messaging Server に含まれるデフォルトの内部モジュールを使用します。外部トークンを使用する場合は、スマートカードリーダーハードウェアを接続し、そのハードウェアの PKCS #11 モジュールをインストールします。

外部モジュールか内部モジュールかにかかわらず、PKCS #11 モジュールは、コンソールを使用して管理できます。PKCS #11 モジュールをインストールするには、次の手順を実行します。

  1. カードリーダーハードウェアを Messaging Server ホストマシンに接続し、ドライバをインストールします。

  2. コンソールの「PKCS #11 Management」インタフェースを使用して、インストールしたドライバ用の PKCS #11 モジュールをインストールします。

詳細な手順については、『Managing Servers with iPlanet Console』の SSL に関する章を参照してください。

ハードウェア暗号化アクセラレータのインストール暗号化用に SSL を使用する場合は、ハードウェア暗号化アクセラレータをインストールすることによって、メッセージの暗号化と解読のパフォーマンスを向上させることができます。一般的に、暗号化アクセラレータは、サーバーマシンに常設されたハードウェアボードとソフトウェアドライバで構成されます。Messaging Server は、PKCS #11 API に準拠したアクセラレータモジュールをサポートしています。これらは、基本的に独自のキーを格納しないハードウェアトークンで、キーの格納には内部データベースが使用されます。まず、製造元の指示に従ってハードウェアとドライバをインストールすることにより、アクセラレータをインストールします。その後、PKCS #11 モジュールをインストールすることにより、ハードウェア証明書トークンをインストールします。

Procedureサーバー証明書を要求するには

サーバー証明書を要求するには、コンソールでサーバーを開き、「証明書セットアップウィザード」を実行します。このウィザードには、「コンソール」メニューまたは Messaging Server の「暗号化」タブからアクセスできます。このウィザードを使用して、次のタスクを実行します。

手順
  1. 証明書要求を作成します。

  2. 電子メールを使用して、証明書を発行する認証局 (CA) に要求を送信します。

    認証局 (CA) から電子メールによる応答を受け取ったら、メールをテキストファイルとして保存し、証明書セットアップウィザードを使用してそのファイルをインストールします。

    詳細な手順については、『Managing Servers with iPlanet Console』の SSL に関する章を参照してください。

Procedure証明書をインストールするには

インストールは、要求とは別の手順で実行します。認証局 (CA) から証明書要求に対する応答の電子メールを受け取ったら、電子メールをテキストファイルとして保存し、もう一度証明書セットアップウィザードを実行して、次のように証明書としてファイルをインストールします。

手順
  1. 入手済みの証明書をインストールすることを指定します。

  2. 指示に従って、証明書のテキストをフィールド内に貼り付けます。

  3. 証明書のニックネームを server-cert から Server-Cert に変更します。

    証明書のニックネームを変更したくない場合は、configutil パラメータ encryption.rsa.nssslpersonalityssl を設定して、使用したい証明書ニックネームを変更することができます。

    詳細な手順については、『Managing Servers with iPlanet Console』の SSL に関する章を参照してください


    注 –

    CA の証明書 (以下に説明) をインストールする場合にも、この手順を実行する必要があります。サーバーはこの証明書を使用して、クライアントによって提示された証明書の信頼性を判断します。


信頼できる CA の証明書をインストールするには

認証局 (CA) の証明書をインストールする場合も、証明書セットアップウィザードを使用します。CA 証明書は、認証局自体の身元を証明します。サーバーは、クライアントやほかのサーバーを認証するプロセスで、これらの CA 証明書を使用します。

たとえば、パスワードに基づく認証 (157ページの「証明書に基づくログインを設定するには」を参照) に加え、証明書に基づく認証にも対応するように会社の環境を設定した場合は、クライアントが提示する可能性のある証明書の発行元として信頼できる CA の証明書をすべてインストールする必要があります。これらの CA は、社内組織の場合もあれば、商業機関、政府機関、ほかの企業などの外部組織の場合もあります。認証用 CA 証明書の使用方法については、『Managing Servers with iPlanet Console』の「Introduction to Public-Key Cryptography」を参照してください。

Messaging Server をインストールすると、いくつかの商用認証局の CA 証明書もインストールされます。ほかの商用認証局の CA 証明書を追加する場合や、社内使用のために (Sun Java System Certificate Server を使用して) 独自の認証局を開発する場合は、追加の CA 証明書を入手して、インストールする必要があります。


注 –

Messaging Server により自動的に提供される CA 証明書は、インストール時にはクライアント証明書用の信頼できる証明書としてマークされていません。これらの CA から発行されるクライアント証明書を信頼できるものにする必要がある場合は、信頼設定を編集する必要があります。この手順については、153 ページの「証明書と信頼できる CA の管理」を参照してください。


新しい CA 証明書を要求してインストールするには、次の手順を実行します。

Procedure新しい CA 証明書を要求してインストールするには

手順
  1. Web ページからまたは電子メールを利用して認証局に連絡し、その CA 証明書をダウンロードします。

  2. 受け取った証明書のテキストをテキストファイルとして保存します。

  3. 証明書セットアップウィザードを使用し、前の節で説明した手順に従って証明書をインストールします。

    詳細な手順については、『Managing Servers with iPlanet Console』の SSL に関する章を参照してください。

証明書と信頼できる CA の管理

サーバーには、クライアントの認証に使用する、信頼できる CA の証明書を必要な数だけインストールできます。

コンソールでサーバーを開き、「コンソール」メニューの「証明書の管理」コマンドを選択すると、Messaging Server にインストールされている証明書の信頼設定の表示や編集、または任意の証明書の削除を行うことができます。この手順については、『Managing Servers with iPlanet Console』の SSL に関する章を参照してください。

パスワードファイルの作成

任意の Sun Java System サーバー上で、証明書セットアップウィザードを使用して証明書を要求すると、ウィザードによってキーのペアが作成されます。このキーのペアは、あとで内部モジュールのデータベースまたはスマートカード内にある外部データベースに格納します。次に、このプライベートキーを暗号化するために使われるパスワードの入力を要求されます。あとでこのキーを解読するには、この同じパスワードを使用する必要があります。ウィザードでは、パスワードはどこにも記録されません。

SSL を有効にしている Sun Java System サーバーでは、ほとんどの場合、起動時に管理者がキーのペアの解読に必要なパスワードを入力します。ただし、Messaging Server では、パスワードを何度も入力する手間を省き (少なくとも 3 つのサーバープロセスで入力が必要)、さらに無人でサーバーを再起動できるように、パスワードファイルからパスワードが読み取られます。

パスワードファイルは、sslpassword.conf という名前で、ディレクトリ msg_svr_base/config/ に保存されています。ファイル内の各エントリは、次の形式で 1 行ずつ記述されます。

moduleName:password

moduleName は使用される (内部または外部) PKCS #11 モジュールの名前です。password はそのモジュールのキーのペアを暗号化するためのパスワードです。パスワードは、クリアテキスト (暗号化されていないテキスト) として保存されます。

Messaging Server には、デフォルトのパスワードファイルが用意されています。このファイルには、次のような内部モジュールとデフォルトのパスワードのエントリが 1 つだけ含まれています。

Internal (Software) Token:netscape!

内部証明書をインストールするときにデフォルト以外のパスワードを指定する場合は、指定するパスワードに合わせてパスワードファイル内の上記の行を編集する必要があります。外部モジュールをインストールする場合は、ファイルに新しい行を追加し、モジュール名とモジュール用に指定するパスワードを記述する必要があります。


注意 – 注意 –

管理者はサーバー起動時にモジュールパスワードの入力を要求されません。そのため、管理者のアクセスが適切に制御されていること、およびサーバーホストマシンとそのバックアップの物理的なセキュリティーが確保されていることの確認が重要になります。


自己署名済み証明書を作成するには

コマンド行モードで自己署名済み証明書を作成する場合は、この節の手順に従います。証明書ウィザードで証明書を作成するには、「管理コンソールからの証明書の入手」を参照してください。

Procedure自己署名済み証明書を作成するには

手順
  1. スーパーユーザー (root) としてログインします。

  2. /opt/SUNWmsgsr/config/sslpasswordcertutil の証明書データベースのパスワードを指定します。例:


    # echo "password" > /opt/SUNWmsgsr/config/sslpassword

    password は、ユーザー固有のパスワードです。

  3. sbin ディレクトリに移動し、証明書データベース (cert8.db) とキーのデータベース (key3.db) を生成します。例:


    # cd /opt/SUNWmsgsr/sbin
    # ./certutil -N -d /opt/SUNWmsgsr/config -f /opt/SUNWmsgsr/config/sslpassword
  4. デフォルトの自己署名済みルート認証局証明書を生成します。次に例を示します。


    # ./certutil -S -n SampleRootCA -x -t "CTu,CTu,CTu"
    -s "CN=My Sample Root CA, O=sesta.com" -m 25000
    -o /opt/SUNWmsgsr/config/SampleRootCA.crt
    -d /opt/SUNWmsgsr/config
    -f /opt/SUNWmsgsr/config/sslpassword   -z /etc/passwd
  5. ホストの証明書を生成します。例:


    ../certutil -S -n Server-Cert -c SampleRootCA -t "u,u,u"
    -s "CN=hostname.sesta.com, o=sesta.com" -m 25001
    -o /opt/SUNWmsgsr/config/SampleSSLServer.crt
    -d /opt/SUNWmsgsr/config -f /opt/SUNWmsgsr/config/sslpassword
    -z /etc/passwd

    hostname.sesta.com は、サーバーホスト名です。

  6. 証明書の妥当性を検査します。例:


    # ./certutil -V -u V -n  SampleRootCA -d /opt/SUNWmsgsr/config
    # ./certutil -V -u V -n  Server-Cert -d /opt/SUNWmsgsr/config
  7. 証明書を列挙します。例:


    # ./certutil -L -d /opt/SUNWmsgsr/config
    # ./certutil -L -n Server-Cert -d /opt/SUNWmsgsr/config
  8. modutil を使って、使用可能なセキュリティーモジュール (secmod.db) を列挙します。例:


    # ./modutil -list -dbdir /opt/SUNWmsgsr/config
  9. 次の例が示すように、証明書データベースファイルの所有者をメールサーバーのユーザーおよびグループに変更します。


    chown mailsrv:mail /opt/SUNWmsgsr/config/cert8.db
    chown mailsrv:mail /opt/SUNWmsgsr/config/key3.db
    
  10. メッセージングサービスを再起動して、SSL を有効にします。


    注 –

    以前は、証明書とキーファイルは常に Messaging Server の設定ディレクトリにありました。現在は、local.ssldbpath (証明書とキーファイルの場所を指定する) および local.ssldbprefix (証明書とキーファイルのプレフィックスを指定する) を使用して、これらのファイルの場所を指定できます。


SSL を有効化し暗号化方式を選択するには

コンソールを使用すると、SSL を有効にし、Messaging Server がクライアントとの暗号通信で使用できる暗号化方式を選択できます。

暗号化方式について

「暗号化方式」とは、暗号化プロセスでデータの暗号化と解読に使用されるアルゴリズムのことです。各暗号化方式によって強度が異なります。つまり、強度の高い暗号化方式で暗号化したメッセージほど、承認されていないユーザーによる解読が困難になります。

暗号化方式では、キー (長い数値) をデータに適用することによってデータを操作します。一般的に、暗号化方式で使用するキーが長いほど、適切な解読キーを使わずにデータを解読することが難しくなります。

クライアントは、Messaging Server と SSL 接続を開始するときに、サーバーに対して、希望する暗号化用の暗号化方式とキー長を伝えます。暗号化された通信では、両方の通信者が同じ暗号化方式を使用する必要があります。一般的に使用される暗号化方式とキーの組み合わせは数多くあります。そのため、サーバーは柔軟な暗号化サポートを提供する必要があります。Messaging Server では、最大 6 つの暗号化方式とキー長の組み合わせをサポートできます。

表 19–2 に、Messaging Server が SSL 3.0 を使用する場合にサポートする暗号化方式の一覧を示します。この表には概要を記載しています。詳細は、『 Managing Servers with iPlanet Console』の「Introduction to SSL」を参照してください。

表 19–2 Messaging Server の SSL 暗号化方式

暗号化方式 

説明 

128 ビットの暗号化と MD5 メッセージ認証を使用した RC4 

RSA が提供する暗号化方式で、もっとも高速で、もっとも強度の高い暗号化方式と暗号化キーの組み合わせを提供します。 

168 ビットの暗号化と SHA メッセージ認証を使用した DES 

米国政府の標準となっている暗号化方式で、低速で、強度の高い暗号化方式と暗号化キーの組み合わせを提供します。 

56 ビットの暗号化と SHA メッセージ認証を使用した DES 

米国政府の標準となっている暗号化方式で、低速で、中程度の強度の暗号化方式と暗号化キーの組み合わせを提供します。 

40 ビットの暗号化と MD5 メッセージ認証を使用した RC4 

RSA が提供する暗号化方式で、もっとも高速で、強度の低い暗号化方式と暗号化キーの組み合わせを提供します。 

40 ビットの暗号化と MD5 メッセージ認証を使用した RC2 

RSA が提供する暗号化方式で、低速で、強度の低い暗号化方式と暗号化キーの組み合わせを提供します。 

暗号化なし、MD5 メッセージ認証のみ 

暗号化を使用せず、認証用のメッセージダイジェストのみを使用します。 

特定の暗号化方式を使わないようにする妥当な理由がないかぎり、すべての暗号化方式をサポートする必要があります。ただし、特定の暗号化方式の使用が法律で制限されている国もあります。また、米国の輸出規制法規が緩和される前に開発されたクライアントソフトウェアの中には、強度の高い暗号化を使用できないものもあります。40 ビットの暗号化方式では、偶発的な漏洩は防ぐことができますが、セキュリティーが確保されないため、意図的な攻撃を防ぐことはできません。

SSL を有効にし、暗号化方式を選択するには、次のコマンド行を実行します。

SSL を有効化/無効化するには、次のように入力します。

configutil -o nsserversecurity -v [ on | off ]

RSA 暗号化方式を有効化/無効化するには、次のように入力します。

configutil -o encryption.rsa.nssslactivation -v [ on | off ]

トークンを指定するには、次のように入力します。

configutil -o encryption.rsa.nsssltoken -v tokenname

証明書を指定するには、次のように入力します。

configutil -o encryption.rsa.nssslpersonalityssl -v certname

RSA 暗号化方式を有効にする場合は、トークンと証明書も指定する必要があります。

優先する暗号化方式を選択するには、次のように入力します。

configutil -o encryption.nsssl3ciphers -v cipherlist

cipherlist は、カンマで区切られた暗号化方式のリストです。


注 –

送信メッセージの暗号化を有効にするには、チャネル定義を変更して、maytlsmusttls などの tls チャネルキーワードを追加する必要があります。詳細は、「Transport Layer Security」のマニュアルを参照してください。


証明書に基づくログインを設定するには

Sun Java System サーバーでは、パスワードに基づくログインに加えて、デジタル証明書の確認によるユーザー認証もサポートしています。証明書に基づく認証では、クライアントはサーバーとの SSL セッションを確立し、ユーザーの証明書をサーバーに提出します。その後、サーバーが、提出された証明書の信頼性を評価します。証明書の信頼性が確認されると、そのユーザーは認証済みであるとみなされます。

証明書に基づくログインを実行できるように Messaging Server を設定するには、次の手順を実行します。

Procedure証明書に基づくログインを設定するには

手順
  1. 使用しているサーバー用の証明書を入手します(詳細は「管理コンソールからの証明書の入手」を参照)。

  2. 証明書セットアップウィザードを実行して、サーバーが認証するユーザーに証明書を発行する、信頼できる認証局の証明書をインストールします (詳細は「信頼できる CA の証明書をインストールするには」を参照)。

    サーバーのデータベース内に信頼できる CA の証明書が 1 つでもあるかぎり、サーバーは接続するクライアントに対してクライアント証明書を要求します。

  3. SSL を有効にします(詳細は「SSL を有効化し暗号化方式を選択するには」を参照)。

  4. サーバーが提出された証明書の情報に基づいて LDAP ユーザーディレクトリを適切に検索するように、サーバーの certmap.conf ファイルを編集します (省略可)。

    ユーザーの証明書内の電子メールアドレスと、ユーザーのディレクトリエントリ内の電子メールアドレスが一致する場合は、certmap.conf ファイルを編集する必要はありません。また、検索を最適化したり、提出された証明書をユーザーエントリ内の証明書と照合したりする必要もありません。

    certmap.conf の形式と変更可能な部分の詳細は、『Managing Servers with iPlanet Console』の SSL に関する章を参照してください。

    上記の手順を実行したあとに、ユーザーが、IMAP または HTTP にログインできるようにクライアントで SSL セッションを確立すると、Messaging Server からクライアントに対してユーザーの証明書が要求されます。サーバーによって信頼されている CA から発行された証明書をクライアントが提出し、かつ証明書の識別情報がユーザーディレクトリ内のエントリと一致する場合、そのユーザーは、認証され、ユーザーに適用されるアクセス制御ルールに応じたアクセス権が与えられます。

    証明書に基づくログインを有効にするためにパスワードに基づくログインを無効する必要はありません。パスワードに基づくログインが許可されている場合 (デフォルトの状態) に、この節で説明した作業を実行すると、パスワードに基づくログインと証明書に基づくログインの両方がサポートされます。その場合は、クライアントが SSL セッションを確立し、証明書を提出すると、証明書に基づくログインが使用されます。クライアントが SSL を使用しない場合、または証明書を提出しない場合は、パスワードを要求されます。

SMTP プロキシを使用した SSL パフォーマンスの最適化方法

SMTP プロキシを使用すると、SMTP プロトコルの待ち時間が増加するため、ほとんどのサイトでは SMTP プロキシを使用しません。ただし、SMTP 接続を保護するために SSL を頻繁に使用する大規模サイトでは、SSL とプロキシ専用の 1 台のサーバー上で、すべてのプロトコルのすべての SSL 操作を実行することで、SSL アクセラレータハードウェアに対する投資効果を最大化する必要があります。SMTP プロキシを使用すると、フロントエンドのプロキシサーバーで SSL を処理し、メールキューを別の MTA マシン上に置くことができます。この方法により、各タスクに最適なハードウェアを個別に購入して構成することができます。

SMTP プロキシのインストール方法については、「POP before SMTP を有効にする」を参照してください。