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

ここで説明する内容は、次のとおりです。

• 「23.5.1 証明書の入手」

• 「23.5.2 SSL を有効化し暗号化方式を選択する」

• 「23.5.3 証明書に基づくログインを設定する」

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

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 5.0 』の「Introduction to SSL」を参照してください。SSL は、公開鍵暗号方式の概念に基づいています。この概念については、『Managing Servers With iPlanet Console 5.0 』の「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 は、同じポートを使用することも異なるポートを使用することもできます。図 23–1 に示すように、SSL は、送信メッセージと着信メッセージの両方で、メッセージ通信の特定の段階で作用します。

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

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

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

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

23.5.1 証明書の入手

SSL の用途が暗号化か認証かにかかわらず、Messaging Server 用のサーバー証明書を入手する必要があります。この証明書は、使用するサーバーの識別情報をクライアントや他のサーバーに提供します。証明書を入手するためのもっとも効率的な方法は、msgcert コマンド (この節のあとの方で説明) の使用です。古い certutil コマンドもまだ機能しますが、新しいコマンドに比べてずっと複雑で、グローバル化もされていないことに注意してください。certutil の詳細は、「23.5 暗号化と証明書に基づく認証を構成する」および http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html を参照してください。

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

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

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 モジュールをインストールします。

以降の節では、コンソールまたはディレクトリサーバーコンソールについて触れています。これは、バージョン 6 より前の Directory Server を指しています。バージョン 6 以降では、グラフィカルユーザーインタフェースは Directory Server Control Center と呼ばれています。詳細は、Directory Server の最新のマニュアル (『Sun Java System Directory Server Enterprise Edition 6.0 管理ガイド』) を参照してください。

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

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

2. msg-svr-base/sbin にある modutil を使用して、インストールしたドライバ用の PKCS #11 モジュールをインストールします。

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

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

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

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

moduleName:password

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

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

Internal (Software) Token:netscape!

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

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

23.5.1.3 証明書の入手と管理

SSL の用途が暗号化か認証かにかかわらず、Messaging Server 用のサーバー証明書を入手する必要があります。この証明書は、使用するサーバーの識別情報をクライアントや他のサーバーに提供します。証明書を取得して管理するための主なメカニズムとして、msgcert を使用します。ただし、管理サーバーがインストールされている場合は、管理コンソールも使用できます。

この節の残りの部分では、msgcert を使用する方法について説明します。

23.5.1.4 msgcert について

msgcert を使用すると、証明書要求の生成、証明書データベースへの証明書の追加、データベース内の証明書の一覧表示などを行うことができます。詳細な情報を表示するには、コマンド行で次のコマンドを入力します。

msg-svr-base/sbin/msgcert --help

次の情報が表示されます。

# ./msgcert --help

Usage: msgcert SUBCMD [GLOBAL_OPTS] [SUBCMD_OPTS] [SUBCMD_OPERANDS]
Manages the Messaging Servers Certificate Database
The accepted values for SUBCMD are:

add-cert              Adds a certificate to the certificate database
add-selfsign-cert     Creates and adds a selfsign certificate to the 
                      certificate database
export-cert           Exports a certificate and its keys from the database
generate-certDB       Creates Messaging Server Databases cert8.db key3.db 
                      secmod.db and sslPassword
import-cert           Adds a new certificate and its keys to the cert database
import-selfsign-cert  Adds a new selfsign certificate and its keys to the 
                      cert database
list-certs            Lists all certificates in the Certificate database
remove-cert           Removes a certificate from the database
renew-cert            Renews a certificate
renew-selfsign-cert   Renews a selfsign certificate
request-cert          Generates a certificate request
show-cert             Displays a certificate

The accepted value for GLOBAL_OPTS is:-?, --help
                Displays SUBCMD help

NOTE: You must stop all the TLS or SSL-enabled servers before making any 
changes to the Certificate Database.

上に示されている各サブコマンドが、特定の証明書管理機能を実行します。これらのサブコマンドやその機能に関する詳細情報を得るには、次のコマンドを入力します。

msgcert SUBCMD –help

この節の残りの部分では、いくつかの一般的な証明書管理手順について説明します。

23.5.1.5 証明書を管理する

ここでは、Messaging Server で SSL 証明書を管理する方法について説明します。Messaging Server で SSL を実行するには、自己署名付き証明書か、または外部の認証局 (CA) を含む公開鍵インフラストラクチャー (PKI) ソリューションのどちらかを使用してください。PKI ソリューションの場合は、公開鍵と非公開鍵の両方を含む CA 署名付きサーバー証明書が必要です。この証明書は、1 つの Messaging Server に固有です。また、公開鍵を含む、信頼できる CA 証明書も必要です。信頼できる CA 証明書によって、CA からのすべてのサーバー証明書が信頼できることが保証されます。この証明書は、CA ルートキーまたはルート証明書とも呼ばれることがあります。

証明書データベースのパスワードの設定

証明書を管理する場合、証明書のパスワードを入力したり、パスワードファイルを指定したりする必要はありません。パスワードを -W 引数として渡すだけで済みます。次に例を示します。

echo "password22" > /tmp/certdbpwd
echo "password22" > /tmp/certdbpwd
# ./msgcert list-certs -W /tmp/certdbpwd

デフォルトの自己署名付き証明書を含む Messaging Server 証明書データベースを作成する

1. Messaging Server 証明書データベースを作成するには、次のコマンドを実行します。

   msgcert generate-certDB

   このコマンドによって CERT_PW_FILE から証明書データベースのパスワードが読み取られます。(デフォルトはパスワードの入力を要求)

2. この証明書は、次のコマンドを使用して表示できます。

   msgcert show-cert Server-Cert

自己署名付き証明書を管理する

テストの目的で証明書を使用している場合は、自己署名付き証明書を使用できます。配備の設定では、信頼できる証明書発行局 (CA) の証明書を使用するほうを選択する可能性があります。また、Directory Server 管理コンソールを使用してもこのタスクを実行できます。

1. 証明書データベースを作成する場合は、デフォルトの自己署名付き証明書が自動的に提供されます。デフォルト以外の設定を含む自己署名付き証明書を使用する場合は、msgcert add-selfsign-cert コマンドを使用します。次に例を示します。

   msgcert add-selfsign-cert --name siroe --org comms --org-unit Messaging --city SantaClara --state ca --country us MySelfSigned-Cert

   自己署名付き証明書の有効期間は 3 か月です。

2. 自己署名付き証明書の期限が切れたら、次のコマンドを使用して証明書を更新します。

   msgcert renew-selfsign-cert cert_alias

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

認証局の証明書をインストールするには、./msgcert add-cert を使用します。CA 証明書は、認証局自体の身元を証明します。サーバーは、クライアントやほかのサーバーを認証するプロセスで、これらの CA 証明書を使用します。

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

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

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

次の手順は、Messaging Server で使用する CA 署名付きサーバー証明書と信頼できる認証局の証明書を要求してインストールするプロセスを示しています。

CA 署名付きサーバー証明書を要求する

また、Directory Server 管理コンソールを使用してもこのタスクを実行できます。

1. CA 署名付きサーバー証明書に対する要求を生成します。

   msgcert request-cert [-W CERT_PW_FILE] {-S DN|--name NAME [--org ORG] [--org-unit ORG-UNIT] [--city CITY] [--state STATE] [--country COUNTRY] } [-F FORMAT] [-o OUTPUT_FILE]

   CA 署名付きサーバー証明書に対する要求の例を次に示します。この場合は、バイナリ形式の証明書が返されます。

   ./msgcert request-cert --name aqua --org siroe --org-unit Messaging -o my_ca_signed_request_cert

   ASCII 形式の証明書を返すには、次のコマンドを使用します。

   ./msgcert request-cert --name aqua --org siroe --org-unit Messaging -F ascii -o my_casigned_request_cert

   DURGA:どうして 2 つのコマンドがあるのですか。

   通常、CA はサーバーを完全に識別するために、この例に含まれるすべての属性を必要とします。各属性の説明を表示するには、./msgcert request-cert --help を入力します。msgcert request-cert を使用して証明書を要求した場合、出力形式として ASCII を指定しないかぎり、得られる証明書要求はバイナリ形式の証明書要求になります。ASCII を指定すると、得られる証明書要求は、PEM 形式の PKCS #10 証明書要求になります。PEM (Privacy Enhanced Mail) は、RFC 1421 〜 1424 で指定されている形式で、US-ASCII 文字を使用した base64 形式で符号化されます。要求の内容は、次の例のようになります。

   -----BEGIN NEW CERTIFICATE REQUEST----- MIIBdTCB3wIBADA2MRIwEAYDVQQLEwlNZXNzYWdpbmcxDjAMBgNVBAoTBXNpcm9l MRAwDgYDVQQDEwdhcXVhdGljMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDt KEh5Fnj/h9GEu18Da6DkJpcNShkwxanjnKs2883ZoUV5Sp4pN7U6Vfbh0414WXZh D26m3t81q9b9h47Klkf0pW1X3BB6LOjGOHSt2VoNBI8n3hJ6XiN2zYbrlLTgdKuo y0YrSG/kHFnqKghikag9O/Ox+cwD+mpjl2QnsPZgswIDAQABoAAwDQYJKoZIhvcN AQEEBQADgYEArqgWQIwNZDC2d3EZawI23Wj9o6Pyvu9J1rkb+NYgIEnNp9jugxqX F326N0ABLdHXXNX/2ZvC5TKOgS4RidTBM89N9xJvokmvRGfc+1x80uxy474YdNlZ s+nP8AYo9dW9mrLOammozx9HLPSVYNFp4FxekgV2n8QG7WC5rkN5bCE= -----END NEW CERTIFICATE REQUEST-----

2. ここで説明する手順に従って、証明書要求を CA に送信します。

   認証局証明書を取得するプロセスは、使用する認証局によって異なります。一部の商用認証局は、証明書を自動的にダウンロードできる Web サイトを提供しています。その他の認証局は、要求された証明書を電子メールで送信します。

   要求を送信したら、CA から証明書が送られてくるまで待ちます。要求に対する回答が届くまでの時間は、状況によって異なります。たとえば、CA が社内にある場合は、要求に対する回答は 1 〜 2 日しかかからないこともあります。CA が社外にある場合は、数週間かかることもあります。

3. 認証局から送られてきた証明書を保存します。

   証明書を安全な場所にバックアップするようにしてください。これにより、証明書を失ってもバックアップファイルを使用して再インストールできます。証明書は、テキストファイルに保存できます。次に、PEM 形式の PKCS #11 証明書の例を示します。

   -----BEGIN CERTIFICATE----- MIICjCCAZugAwIBAgICCEEwDQYJKoZIhKqvcNAQFBQAwfDELMAkGA1UEBhMCVVMx IzAhBgNVBAoGlBhbG9a2FWaWxsZGwSBXaWRnZXRzLCBJbmMuMR0wGwYDVQQLExRX aWRnZXQgTW3FrZXJzICdSJyBVczEpMCcGAx1UEAxgVGVzdCBUXN0IFRlc3QgVGVz dCBUZXN0IFlc3QgQ0EswHhcNOTgwMzEyMDIzMzUWhcNOTgwMzI2MDIzMpzU3WjBP MQswCYDDVQQGEwJVUzEoMCYGA1UEChMfTmV0c2NhcGUgRGlyZN0b3J5VIFB1Ymxp Y2F0aW9uczEWMB4QGA1UEAxMNZHVgh49dq2tLNvbjTBaMA0GCSqGSIb3DQEBAQUA A0kAMEYkCQCksMR/aLGdfp4m0OiGgijG5KgOsyRNvwGYW7kfW+8mmijDtZaRjYNj jcgpF3VnlbxbclX9LVjjNLC5737XZdAgEDozYwpNDARBglghkgBhvhCEAQEEBAMC APAwHkwYDVR0jBBgwFAU67URjwCaGqZHUpSpdLxlzwJKiMwDQYJKoZIhQvcNAQEF BQADgYEAJ+BfVem3vBOPBveNdLGfjlb9hucgmaMcQa9FA/db8qimKT/ue9UGOJqL bwbMKBBopsDn56p2yV3PLIsBgrcuSoBCuFFnxBnqSiTS7YiYgCWqWaUA0ExJFmD6 6hBLseqkSWulk+hXHN7L/NrViO+7zNtKcaZLlFPf7d7j2MgX4Bo= -----END CERTIFICATE-----

CA 署名付きサーバー証明書と信頼できる認証局の証明書を追加する

また、Directory Server 管理コンソールを使用してもこのタスクを実行できます。

1. 次のコマンドを使用して、CA 署名付きサーバー証明書を追加します。

   msgcert add-cert cert_alias cert_file

   ここで、cert_alias は証明書を識別するために指定する名前です。cert_file は、PEM 形式の PKCS #11 証明書を含むテキストファイルです。

   たとえば、CA 署名付きサーバー証明書をインストールするには、次のようなコマンドを使用できます。

   msgcert add-cert /my_cert/server-cert-file

   これで証明書がインストールされましたが、まだ信頼されてはいません。CA 署名付きサーバー証明書を信頼できるものにするには、認証局証明書をインストールしてください。

2. 次のコマンドを使用して、信頼できる証明書発行局の証明書を追加します。

   msgcert add-cert -C cert_alias cert_file

   -C オプションは、この証明書が信頼できる証明書発行局の証明書であることを示します。

   たとえば、認証局から信頼できる証明書をインストールするには、次のコマンドを使用できます。

   msgcert add-cert -C CA-cert /my_cert/ca-cert-file

3. 必要に応じて、インストールした証明書を、次のコマンドを使用して確認します。

   すべてのサーバー証明書を一覧表示して、エイリアスや有効期限などの情報を表示するには、次のコマンドを実行します。

   msgcert list-certs

   ./msgcert generate-CertDB で生成された場合、Messaging Server には Server-Cert と呼ばれるデフォルトの証明書が用意されています。「発行者と同じ」というテキストは、デフォルトの証明書が自己署名付きサーバー証明書であることを示しています。次に例を示します。

   # ./msgcert list-certs 証明書データベースのパスワードを入力してください: エイリアス 有効期限開始日 有効期限 自己 発行元 発行先 署名付き ------------ ---------------- --------------- ------ --------------------- ------------------------- -------------- SelfSignedCrt 2006/07/28 12:58 2006/10/28 12:58 y CN=SFO,L=SC,ST=ca,C=us 発行者と同じ Server-Cert 2006/07/28 07:47 2006/10/28 07:47 y CN=perseids 発行者と同じ 2 個の証明書が見つかりました

   信頼できる認証局の証明書を一覧表示するには、次のコマンドを実行します。

   msgcert list-certs -C

   証明書の詳細 (証明書の満了日を含む) を表示するには、次のコマンドを実行します。

   msgcert show-cert cert_alias

   たとえば、自己署名付き証明書を表示するには、次のコマンドを実行します。

   # ./msgcert show-cert MySelfSigned-Cert Enter the certificate database password: Certificate: Data: Version: 3 (0x2) Serial Number: 00:83:35:37:94 Signature Algorithm: PKCS #1 MD5 With RSA Encryption Issuer: "CN=siroe,O=comms,OU=Messaging,L=SantaClara,ST=ca,C=us" Validity: Not Before: Fri Jul 28 19:58:31 2006 Not After : Sat Oct 28 19:58:31 2006 Subject: "CN=siroe,O=comms,OU=Messaging,L=SantaClara,ST=ca,C=us" Subject Public Key Info: Public Key Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: aa:9d:3d:23:b2:59:39:f3:77:c8:69:7f:b0:d1:ac:d2: 4e:81:c8:51:0f:27:6f:a1:21:4b:a9:27:46:d7:0f:b4: c8:44:86:32:5e:4f:2f:1c:2f:a9:b8:a3:49:b5:b8:ab: 51:a8:a5:ba:1c:e8:90:7d:46:67:f9:a7:44:c5:1d:24: e6:bd:e8:8f:07:b4:5a:68:41:b1:19:f2:ea:98:ba:25: 55:b8:ba:9c:af:bb:43:c3:c0:8f:14:a7:4c:2b:50:b4: ac:df:b5:cd:68:de:a6:14:9d:68:77:d3:8b:7f:de:c0: 5d:35:d7:55:8d:b5:c3:14:2a:60:a9:bf:de:96:90:a9 Exponent: 65537 (0x10001) Signature Algorithm: PKCS #1 MD5 With RSA Encryption Signature: 15:86:f1:cc:85:c9:08:0f:ff:d3:56:d8:e2:c8:ea:3c: 8e:45:36:be:8b:b0:7d:2f:e9:cd:e3:b4:ad:8c:70:59: c8:a5:14:da:9c:fa:7f:70:86:64:34:0b:21:ae:c4:28: d2:f5:94:5c:a6:78:0f:d9:fd:fc:c5:5e:37:49:25:a9: bc:12:59:cb:fb:4e:e9:d4:8a:8d:3d:41:12:ae:f1:7f: 8d:d3:10:ac:fb:33:51:5d:0c:1b:dc:23:5f:95:d5:6d: c6:1d:e5:ed:13:8b:16:41:89:5b:4d:de:c0:c7:56:a2: 48:82:38:32:5a:99:d5:21:20:c5:0d:5c:ea:0c:84:aa Fingerprint (MD5): EF:76:A3:6C:09:4E:BC:6B:87:76:A3:35:70:1F:B2:C4 Fingerprint (SHA1): BB:1C:20:4B:79:3A:F1:49:F0:83:FB:CC:9C:56:10:D3:06:97:AA:07 Certificate Trust Flags: SSL Flags: Valid CA Trusted CA User Trusted Client CA Email Flags: User Object Signing Flags: User

期限が切れた CA 署名付きサーバー証明書の更新

CA 署名付きサーバー証明書 (公開鍵および非公開鍵) の期限が切れた場合は、次の手順を使用して証明書を更新できます。また、Directory Server 管理コンソールを使用してもこのタスクを実行できます。

1. 認証局から、更新された CA 署名付きサーバー証明書を取得します。

2. 更新された証明書を受信したら、その証明書をインストールします。

   msgcert renew-cert cert_alias cert_file

CA 署名付きサーバー証明書をエクスポートおよびインポートする

場合によっては、証明書を (たとえば、別のホストに) エクスポートして、あとでその証明書をインポートできるようにしたいことがあります。また、Directory Server 管理コンソールを使用してもこのタスクを実行できます。

1. 証明書をエクスポートします。

   msgcert export-cert [-o OUTPUT_FILE] CERT_ALIAS

   次に例を示します。

   $ ./msgcert export-cert -o /tmp/first-certificate "First Certificate" $./msgcert export-cert -o /tmp/first-server-certificate Server-Cert Choose the PKCS#12 file password: Confirm the PKCS#12 file password: $ls /tmp first-server-certificate /tmp/first-certificate

2. 証明書をインポートします。

   $ msgcert import-cert CERT_FILE

   たとえば、証明書をインポートするには、次のコマンドを実行します。

   $ msgcert import-cert /tmp/first-server-certificate Enter the PKCS#12 file password: $

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

コンソールを使用すると、SSL を有効にし、Messaging Server がクライアントとの暗号通信で使用できる暗号化方式を選択できます。また、msgcert ユーティリティーを使用して SSL 証明書をインストールし、対応する configutil を実行するか、またはその特定のサービスの SSL を有効にするために必要な対応する設定ファイルを編集することもできます。

23.5.2.1 暗号化方式について

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

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

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

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

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

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

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

configutil -o encryption.rsa.nssslpersonalityssl -v certname

また、SSL サーバー証明書のニックネームに対するサービスごとの設定も存在します。新しい configutil 設定は次のとおりです。

local.imta.sslnicknames - SMTP および Submit サーバーの場合 local.imap.sslnicknames - IMAP サーバーの場合 local.pop.sslnicknames - POP サーバーの場合 local.http.sslnicknames - Web メールサーバーの場合

これらの設定は、encryption.rsa.nssslpersonalityssl の設定と同じ意味を持ち、その設定より優先されます。具体的には、この値は NSS 証明書のニックネームのコンマ区切りリストです。リスト内には複数のニックネームを指定できますが、この設定がほぼ常に 1 つのニックネームだけになるように、各ニックネームが別の種類の証明書 (たとえば、RSA 証明書と DSS 証明書) を参照するようにしてください。ニックネームは非修飾にすることができます。この場合は、NSS ソフトウェアトークンまたはデフォルトのトークンが検索されます。または、"security-module:nickname" の形式にすることができます。この場合は、指定されたセキュリティーモジュールでそのニックネームが検索されます。この指定方法は、ハードウェアトークン、またはデフォルトの NSS データベース以外の場所に格納された証明書の場合に必要です。

これにより、製品内で複数の NSS ソフトウェアトークンを使用することは許可されません。特に、IMAP、POP、SMTP、および HTTP に対しては 1 つの cert8.db、key3.db、および secmod.db しか存在しません。NSS ではそれが許可されません。

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

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

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

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

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

1. 使用しているサーバー用の証明書を入手します (詳細は、「23.5.1 証明書の入手」を参照)。

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

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

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

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

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

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

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

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

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

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

SMTP プロキシをインストールする方法については、『Sun Java Communications Suite 5 配備計画ガイド』の「MMP SMTP プロキシの使用」および「23.8 POP before SMTP を有効にする」を参照してください。