25.4 NetIQ Certificate Serverの管理

組織の認証局オブジェクトを作成する

このタスクについては、セクション 25.3.2, 組織の認証局オブジェクトを作成するで説明されています。

公開鍵証明書の発行

このタスクでは、サーバ証明書オブジェクトを認識しない暗号化対応アプリケーション用の証明書を生成できます。

組織認証局は、外部認証局と同じ方法で機能します。つまり、証明書署名要求(CSR)から証明書を発行する機能があります。ユーザが署名のためにCSRを送信してきたら、組織認証局を使用して証明書を発行できます。証明書を要求したユーザは、発行された証明書を取得し、暗号化対応アプリケーションに直接インポートします。

公開鍵証明書を発行するには、次の手順を実行します。

組織認証局のプロパティの表示

任意のeDirectoryオブジェクトで表示できるeDirectoryの権利とプロパティに加え、組織認証局に固有のプロパティ(それに関連付けられた公開鍵証明書や自己署名証明書のプロパティなど)を表示することもできます。

組織認証局の公開鍵証明書プロパティの表示

認証局の自己署名証明書プロパティの表示

組織認証局の自己署名証明書のエクスポート

自己署名証明書は、組織認証局の識別情報と、組織認証局によって署名された証明書の有効性を確認するために使用できます。

組織認証局のプロパティページでは、このオブジェクトに関連付けられた証明書とプロパティを参照できます。［自己署名証明書］プロパティページでは、自己署名証明書を、暗号化対応のアプリケーションで使用するファイルにエクスポートできます。

組織の認証局に存在する自己署名証明書は、組織の認証局によって署名された証明書を持つサーバ証明書オブジェクトのルート認証局証明書と同じものです。組織認証局の自己署名証明書をルート認証局として認識するサービスでは、組織認証局によって署名された有効なユーザやサーバを許可できます。

このタスクは、認証局が従属認証局の場合、適用されません。

組織認証局の自己署名証明書をエクスポートするには、次の手順を実行します。

組織認証局のバックアップ

NetIQでは、組織認証局のホストサーバで回復不能な障害が発生する場合に備え、組織認証局の秘密鍵と証明書をバックアップしておくことをお勧めします。障害が発生した場合、バックアップファイルを使用して、組織認証局をツリー内の任意のサーバに復元できます。

組織認証局が正常に機能しているときに、組織認証局をバックアップする必要があります。

NetIQ Certificate Server 9.0以降で認証局を完全にバックアップするには、CRLデータベースと発行済み証明書データベースをバックアップする必要があります。

その他のプラットフォームでは、これらのデータベースは両方とも、eDirectory dibファイルと同じディレクトリにあります。これらの場所のデフォルト値は次のとおりです。

これらのデフォルト値は、eDirectoryのインストール時に変更できます。

CRLデータベースのバックアップ対象ファイルは、crl.db、crl.01、およびcrl.rflディレクトリです。発行済み証明書データベースのバックアップ対象ファイルは、cert.db、cert.lck、cert.01、およびcert.rflディレクトリです。

eDirectory dibディレクトリは、標準および通常バックアップ計画の一部に含める必要があります。

組織認証局をバックアップするには、次の手順を実行します。

組織認証局の復元

組織認証局オブジェクトが削除されたまたは破損した場合、あるいは組織認証局のホストサーバに回復不能な障害が発生した場合、組織認証局のバックアップで作成したバックアップファイルを使用して、完全に復元することができます。

NetIQ Certificate Server 9.0で認証局を完全に復元するには、CRLデータベースと発行済み証明書データベースを復元する必要があります。

これらのデータベースは両方とも、eDirectory dibファイルと同じディレクトリにあります。これらの場所のデフォルト値は次のとおりです。

これらのデフォルト値は、eDirectoryのインストール時に変更できます。

CRLデータベースの復元対象ファイルは、crl.db、crl.01、およびcrl.rflディレクトリです。発行済み証明書データベースの復元対象ファイルは、cert.db、cert.lck、cert.01、およびcert.rflディレクトリです。

eDirectory dibディレクトリは、標準および通常バックアップ計画の一部に含める必要があります。

組織認証局を復元するには、次の手順を実行します。

組織認証局の別のサーバへの移動

組織認証局のバックアップおよび組織認証局の復元で説明されているバックアップと復元の手順を利用して、1つのサーバから別のサーバに組織認証局を移動できます。

NetIQ Certificate Server 3.2以降で、認証局を完全に移動するには、CRLデータベースと発行済み証明書データベースを移動する必要があります。

その他のプラットフォームでは、これらのデータベースは両方とも、eDirectory dibファイルと同じディレクトリにあります。これらの場所のデフォルト値は次のとおりです。

これらのデフォルト値は、eDirectoryのインストール時に変更できます。

CRLデータベースの移動対象ファイルは、crl.db、crl.01、およびcrl.rflディレクトリです。発行済み証明書データベースの移動対象ファイルは、cert.db、cert.lck、cert.01、およびcert.rflディレクトリです。

組織認証局の証明書の検証

証明書に問題があることが疑われる場合、または失効していると思われる場合は、iManagerを使用して簡単に証明書を検証できます。外部認証局によって発行された証明書を含め、eDirectoryツリー内のすべての証明書を検証できます。

証明書の検証プロセスには、証明書のデータだけでなく、証明書チェーン内のデータに対する複数のチェックが含まれます。証明書チェーンは、ルート認証局証明書と、必要に応じて1つ以上の中間認証局の証明書からなります。

証明書チェーン内のすべての証明書が有効であれば、結果は有効になります。現在の時刻が証明書の有効期間内であるか、証明書が取り消されていないか、信頼されている認証局によって署名されているかなど、事前定義された一連の条件を証明書が満たすと、その証明書は有効であると見なされます。CRL配布ポイント拡張機能またはOCSP AIA拡張機能を使用している証明書に限り、取り消されているかどうかがチェックされます。

証明書チェーン内の1つ以上の証明書が無効であると判明した場合、または有効であると断定できない場合、結果は無効になります。無効であると見なされている証明書およびその理由を示す、これらの証明書に関する追加情報が提供されます。理由に関する詳細については、［ヘルプ］をクリックしてください。

証明書を検証するには、次の手順を実行します。

組織認証局の削除

組織認証局オブジェクトの削除は、絶対に必要な場合、またはバックアップから組織認証局を復元する場合にのみ行います(組織認証局の復元を参照してください)。オブジェクトを削除する唯一安全な方法は、後で復元できるようにまずバックアップを実行してから行う方法です。

ただし、組織認証局を削除し、復元されないようにする必要がある場合もあります。たとえば、ツリーをマージするとき、結果のツリーには1つの組織認証局だけが存在でき、その他の認証局は削除する必要があります。また、組織認証局のホストサーバが修復できないほど破損しているときに、認証局のバックアップまたはNICI設定が行われていない場合、残されている唯一のオプションは認証局を削除して初めからやり直すことです。

組織認証局オブジェクトを削除するには、次の手順を実行します。

組織認証局のロールオーバー

組織認証局(CA)証明書を置き換える際に考慮すべき重要な問題が2つあります。

サーバ証明書オブジェクト(KMO)には、サーバの公開鍵証明書と、公開鍵証明書の署名に使用されたルート認証局証明書の両方が含まれます。ユーザ証明書は、ユーザオブジェクトの属性として保存され、それらに署名したルート認証局とはペアになりません。したがって、ルート認証局証明書が置き換えられても、ルート認証局がまだアクセス可能であるため、サーバ証明書は引き続き有効になります。ただしユーザ証明書は、証明書の検証によって確認できるルート認証局コンテナにルート認証局証明書が配置されていない限り、すぐに無効になります。

認証局を交換する3つの理由があります。

認証局の有効期限が切れた場合、認証局が署名した証明書の有効期限も切れます。認証局を交換した後、新しい認証局を使用してそれぞれの署名済み証明書を再作成する必要があります。

認証局が侵害された場合、認証局を交換することによって、古い認証局によって署名されたユーザ証明書を無効にします。iManagerでデフォルト証明書の作成タスクを実行することによって、簡単に置き換えることができます。証明書サーバによってデフォルトで作成されたすべての証明書は、新しい認証局で再作成されます。カスタマイズした方法で作成したすべての証明書は、新しい認証局を使用して手動で再作成する必要があります。デフォルトの証明書を作成する方法の詳細については、デフォルトのサーバ証明書オブジェクトを作成するを参照してください。

何らかの理由で認証局を再作成する場合は、ルート認証局コンテナにルート認証局証明書を保存することによって、ユーザ証明書を再作成するのに都合の良いときまでユーザ証明書を有効なままにしておきます。

ルート認証局証明書を置き換えるには、次の手順を実行します。

サーバ証明書オブジェクトを作成する

このタスクについては、セクション 25.3.6, サーバ証明書オブジェクトを作成するで説明されています。

デフォルトのサーバ証明書オブジェクトを作成する

証明書サーバをインストールすると、デフォルトのサーバ証明書オブジェクトが作成されます。

何らかの理由でこれらの証明書が破損しているまたは無効になった場合、あるいは既存のデフォルト証明書を置換する場合は、次の手順に従って［Create Default Server Certificates］ウィザードを使用します。

サーバ証明書オブジェクトの作成をより細かく制御する場合は、サーバ証明書オブジェクトを手動で作成できます。詳細については、サーバ証明書オブジェクトを手動で作成するを参照してください。

サーバ証明書オブジェクトへの公開鍵証明書のインポート

証明書署名要求(CSR)を作成し、認証局(CA)が署名済み公開鍵証明書を返してきた後、公開鍵証明書をインポートします。このタスクは、外部認証局の署名オプションとカスタムオプションを使用して、サーバ証明書オブジェクトを作成したときに適用されます。

認証局が証明書を返す方法はいくつかあります。通常、認証局によって、それぞれ1つずつ証明書を格納した1つ以上のファイルか、複数の証明書を格納した1つのファイルが返されます。これらのファイルは、バイナリのDERエンコードファイル(.der、.cer、.crt、.p7b)か、テキストのBase64エンコードファイル(.cer、.b64)になります。

ファイルに複数の証明書が含まれる場合、サーバ証明書オブジェクトにインポートできるようにするためPKCS #7形式である必要があります。さらに、このファイルには、オブジェクトにインポートされるすべての証明書(ルートレベルの認証局証明書、すべての中間証明書、サーバ証明書)を含める必要があります。

証明書に署名した結果として認証局が複数のファイルを返す場合、各ファイルにはサーバ証明書オブジェクトにインポートする必要がある別個の証明書が格納されます。3つ以上のファイル(1つのルートレベルの認証局、1つ以上の中間認証局、1つのサーバ証明書)がある場合、サーバ証明書オブジェクトにインポートするため、これらのファイルをPKCS #7ファイルにまとめる必要があります。

PKCS #7ファイルを作成する方法はいくつかあります。1つの方法は、Internet Explorerにすべての証明書をインポートする方法です。それらの証明書をインポートした後、Internet Explorerを使用して、サーバ証明書と証明書チェーン内のすべての証明書をPKCS #7形式でエクスポートすることができます。この方法の詳細については、外部認証局を参照してください。

一部の認証局は、ルートレベルの認証局証明書をサーバ証明書と一緒に返しません。それらのルートレベルの認証局証明書を取得するには、認証局プロバイダに直接問い合わせるか、テクニカルサポートに連絡します。

サーバ証明書オブジェクトに証明書をインポートするには、次の手順を実行します。

ルート認証局または公開鍵証明書のエクスポート

次の理由から、証明書をファイルにエクスポートすることがあります。

DERエンコード(.der)とBase64エンコード(.b64)の2つのファイル形式で証明書をエクスポートできます。.crt拡張子も、DERエンコード証明書に使用できます。暗号化対応アプリケーションに証明書を直接貼り付けることができるように、システムクリップボードにBase64形式でエクスポートすることもできます。

ルート認証局または公開鍵証明書をエクスポートするには、次の手順を実行します。

サーバ証明書オブジェクトの削除

秘密鍵が侵害されていると思われる場合、鍵ペアを使用する必要がなくなった場合、またはサーバ証明書オブジェクトのルート認証局を信頼できなくなった場合、サーバ証明書オブジェクトを削除する必要があります。

サーバ証明書オブジェクトを削除するには、次の手順を実行します。

サーバ証明書オブジェクトのプロパティの表示

任意のeDirectoryオブジェクトで表示できるeDirectoryの権利とプロパティに加え、サーバ証明書オブジェクトに固有のプロパティ(存在する場合、それに関連付けられた公開鍵証明書やルート認証局証明書のプロパティも含みます)を表示することもできます。

サーバ証明書オブジェクトのプロパティを表示するには、次の手順を実行します。

サーバ証明書オブジェクトの公開鍵証明書プロパティの表示

サーバ証明書オブジェクトの公開鍵証明書プロパティを表示するには、次の手順を実行します。

サーバ証明書オブジェクトのルート認証局証明書プロパティの表示

サーバ証明書オブジェクトのルート認証局証明書プロパティを表示するには、次の手順を実行します。

サーバ証明書オブジェクトのバックアップ

NetIQ Certificate Serverでは、サードパーティ認証局によって署名された証明書をサーバ証明書オブジェクトに保存することができます。多くの場合、これらの証明書にはかなりの費用がかかります。残念ながら、証明書を保有するサーバで回復不能なエラーが発生すると、サーバ証明書オブジェクトは使用できなくなります。そのような障害から守るために、外部認証局よって署名されたサーバ証明書とそれに関連付けられている秘密鍵をバックアップできます。障害が発生した場合、バックアップファイルを使用して、サーバ証明書オブジェクトをツリー内の任意のサーバに復元できます。

バックアップファイルには、サーバの秘密鍵、公開鍵証明書、ルート認証局証明書、および保存されているすべての中間認証局証明書が含められます。この情報は、PKCS #12形式(PFXとも呼ばれます)で保存されます。

サーバ証明書オブジェクトが正常に機能しているときに、サーバ証明書オブジェクトをバックアップする必要があります。

サーバ証明書オブジェクトをバックアップするには、次の手順を実行します。

サーバ証明書オブジェクトの復元

サーバ証明書オブジェクトが削除されたまたは破損した場合、あるいはサーバ証明書オブジェクトを所有するサーバで回復不能な障害が発生した場合、サーバ証明書オブジェクトのバックアップで作成したバックアップファイルを使用して、完全に復元することができます。

サーバ証明書オブジェクトのバックアップを作成できなかった場合、NICI 2.xがサーバにインストールされていて、NICI設定情報のバックアップが作成されていれば、そのサーバ証明書オブジェクトを使用できる可能性があります。NICI設定ファイルのバックアップおよび復元方法については、『Novell International Cryptographic Infrastructure Administration Guide』の「Backing Up and Restoring NICI」セクションを参照してください。

サーバ証明書オブジェクトを復元するには、次の手順を実行します。

これで、サーバの秘密鍵と証明書が復元され、サーバ証明書オブジェクトは完全に機能するようになります。必要に応じて、将来の使用に備え、再度バックアップファイルを保存できます。

サーバ証明書オブジェクトとクラスタリング

クラスタ化された環境でサーバ証明書オブジェクトを設定し、サーバ証明書オブジェクトを使用する暗号化対応アプリケーションがそれらに常にアクセスできるようにできます。サーバ証明書オブジェクトのバックアップと復元機能を使用して、オブジェクトのキーマテリアルをクラスタ内の1つのノードからすべてのノードに複製できます。外部認証局によって署名されたキーマテリアルにこのプロセスを使用することによって、クラスタ内のすべてのノードのために新しいキーマテリアルを要求するのではなく1つのサーバ証明書のキーマテリアルを複製できるため、コストを削減できます。

クラスタ環境で機能するようにサーバ証明書を設定するには、次の手順を実行します。

サーバ証明書の検証

証明書に問題があることが疑われる場合、または失効していると思われる場合は、iManagerを使用して簡単に証明書を検証できます。外部認証局によって発行された証明書を含め、eDirectoryツリー内のすべての証明書を検証できます。

証明書の検証プロセスには、証明書のデータだけでなく、証明書チェーン内のデータに対する複数のチェックが含まれます。証明書チェーンは、ルート認証局証明書と、必要に応じて1つ以上の中間認証局の証明書からなります。

証明書チェーン内のすべての証明書が有効であれば、結果は有効になります。現在の時刻が証明書の有効期間内であるか、証明書が取り消されていないか、信頼されている認証局によって署名されているかなど、事前定義された一連の条件を証明書が満たすと、その証明書は有効であると見なされます。CRL配布ポイント拡張機能またはOCSP AIA拡張機能を使用している証明書に限り、取り消されているかどうかがチェックされます。

証明書チェーン内の1つ以上の証明書が無効であると判明した場合、または有効であると断定できない場合、結果は無効になります。無効であると見なされている証明書およびその理由を示す、これらの証明書に関する追加情報が提供されます。理由に関する詳細については、［ヘルプ］をクリックしてください。

証明書を検証するには、次の手順を実行します。

ルート認証局または自己署名証明書の取り消し

鍵または認証局が侵害されている場合、証明書が別の証明書によって置き換えられてしまった場合、証明書がCRLから削除された場合など、さまざまな理由で証明書を取り消す必要があると判断することがあるかもしれません。

別のサーバへのサーバ証明書オブジェクトの移動

サーバ証明書オブジェクトのバックアップおよびサーバ証明書オブジェクトの復元で説明されているバックアップと復元の手順を利用して、1つのサーバから別のサーバにサーバ証明書オブジェクトを移動できます。

サーバ証明書オブジェクトのキーマテリアルの置換

サーバ証明書オブジェクト内の秘密鍵と証明書を置き換えることができます。それらを置き換える場合、サーバ証明書オブジェクトのバックアップ中に作成された、内部で生成されたPFXファイルのみを使用するようにします。秘密鍵、サーバ証明書、および完全な証明書チェーンが含まれている場合は、外部で生成されたPFXファイルも使用できます。ファイル内の鍵と証明書は、必ずしもオブジェクトのものと一致している必要はありません。ファイル内のデータによって、オブジェクトの鍵と証明書が上書きされます。

サーバ証明書オブジェクト内の秘密鍵と証明書の置換は、慎重に行う必要があります。鍵と証明書がオブジェクトのものと正確に一致しない場合、現在のサーバ証明書オブジェクトを削除して新規に作成するのと同じことになります。オブジェクトを削除することによって生じる結果の詳細については、サーバ証明書オブジェクトのバックアップセクションを参照してください。

鍵および証明書がオブジェクトのものと一致する場合、Secure Authentication Services (SAS)によって使用されるいくつかの属性が再生成される以外は、キーマテリアルの置換によって生じる影響はありません。

サーバ証明書オブジェクトのキーマテリアルを置換するには、次の手順を実行します。

これで、サーバの秘密鍵と証明書が置換されました。サーバ証明書は完全に機能するようになります。必要に応じて、将来の使用に備え、再度バックアップファイルを保存します。

ユーザ証明書の作成

このタスクについては、ユーザ証明書の作成で説明されています。

ユーザ証明書の一括作成

この機能により、一連の操作で、同時に複数のユーザのユーザ証明書を作成できます。

ユーザオブジェクトへの公開鍵証明書のインポート(秘密鍵は省略可)

ユーザオブジェクト(たとえば、サードパーティの認証局によって署名された証明書)に、任意の公開鍵証明書をインポートできます。この証明書は、次の2種類のファイルのいずれかとして表示されます。

インポートされると、証明書はユーザオブジェクトに保存され、使用可能な証明書のリストに表示されます。

ユーザオブジェクトに公開鍵証明書をインポートするには、次の手順を実行します。

ユーザ証明書のプロパティの表示

任意のeDirectoryオブジェクトで表示できるeDirectoryの権利とプロパティに加え、ユーザ証明書に固有のプロパティ(発行者、証明書のステータス、秘密鍵のステータス、検証期間など)を表示することもできます。

ユーザ証明書のエクスポート

別のユーザとセキュリティで保護された電子メールを交換するには、まず、そのユーザの公開鍵証明書を入手する必要があります。証明書を入手する1つの方法は、iManagerを使用して証明書をエクスポートすることです。あるいは、LDAPや電子メールを使用して、相手の証明書を入手することもできます。

自分または他のユーザの公開鍵証明書をエクスポートするには、次の手順に従います。

ユーザ証明書と秘密鍵のエクスポート

セキュリティで保護された電子メール、認証、または暗号化の証明書を使用するには、秘密鍵と証明書の両方が、暗号化対応アプリケーションで使用できるようになっていなければなりません。ユーザ証明書と秘密鍵をエクスポートし、アプリケーションで使用できるよう、そのアプリケーションがアクセスできる場所に配置する必要があります。

ユーザのオブジェクトに含まれる秘密鍵は、そのユーザに属しています。その秘密鍵をエクスポートできるのは、そのユーザとしてログインした場合のみです。その他のユーザは、ネットワーク管理者であっても、他のユーザの秘密鍵をエクスポートする権利はありません。

自分の秘密鍵と証明書をエクスポートするには、次の手順に従います。

ユーザ証明書の検証

証明書に問題があることが疑われる場合、または失効していると思われる場合は、iManagerを使用して簡単に証明書を検証できます。外部認証局によって発行された証明書を含め、eDirectoryツリー内のすべての証明書を検証できます。

証明書の検証プロセスには、証明書のデータだけでなく、証明書チェーン内のデータに対する複数のチェックが含まれます。証明書チェーンは、ルート認証局証明書と、必要に応じて1つ以上の中間認証局の証明書からなります。

証明書チェーン内のすべての証明書が有効であれば、結果は有効になります。現在の時刻が証明書の有効期間内であるか、証明書が取り消されていないか、信頼されている認証局によって署名されているかなど、事前定義された一連の条件を証明書が満たすと、その証明書は有効であると見なされます。CRL配布ポイント拡張機能またはOCSP AIA拡張機能を使用している証明書に限り、取り消されているかどうかがチェックされます。

証明書チェーン内の1つ以上の証明書が無効であると判明した場合、または有効であると断定できない場合、結果は無効になります。このような場合は、無効と見なされた証明書とその理由に関する追加情報が提供されます。理由に関する詳細については、［ヘルプ］をクリックしてください。

証明書を検証するには、次の手順を実行します。

ユーザ証明書の取り消し

鍵または認証局が侵害されている場合、証明書が別の証明書によって置き換えられてしまった場合、証明書がCRLから削除された場合など、さまざまな理由で証明書を取り消す必要があると判断することがあるかもしれません。

ユーザ証明書と秘密鍵の削除

ユーザ証明書が無効になった場合、または何らかの形での秘密鍵のセキュリティ侵害が疑われる場合は、ユーザ証明書と秘密鍵を削除する必要があります。

ユーザ証明書と秘密鍵を削除するには、その前に、ユーザ証明書を取り消さなければなりません。詳細については、ユーザ証明書の取り消しを参照してください。

ユーザ証明書と秘密鍵を削除するには、次の手順に従います。

概要

X.509認定を作成するときには、認証局(CA)が証明書を発行する前に特定して裏付けを取っておく必要のある、多くの重要な情報があります。最も重要なタスクは、以下の2つです。

これら2つのタスクには非常に時間がかかる可能性があり、多くの場合は独立した管理者や管理グループによって行われます。

NetIQ Certificate Serverではこれまで常に、eDirectoryのセキュア識別情報管理機能を利用して、これらの検証に必要な時間を節約し、手間を省いてきました。iManagerでは、管理者がユーザ証明書を一括で作成できるようになっています。つまり、多数のユーザの証明書を一度に作成できます。認証局は、証明書の識別情報がeDirectoryアカウントに関連付けられていることを確認し、それによって証明書のサブジェクトの識別情報を検証します。一方、証明書のサブジェクト名の妥当性は認証局によって検証されていませんでした。このため、NetIQ Certificate Serverで証明書を作成するには、証明書を作成する担当者またはソフトウェアには必ず、組織認証局に対する管理権が必要でした。

自己プロビジョニングにより、ユーザまたはサーバは、認証局に対する管理権がなくても、別の管理者または管理グループの介入なく、組織認証局のセキュリティを維持しながら、証明書を生成できます。

NetIQ Certificate Serverは、証明書の識別情報がeDirectoryアカウントに関連付けられていることを確認することによって、証明書のサブジェクトの識別情報を検証します。認証局はeDirectory内の情報を確認することで、証明書のサブジェクト名の妥当性も検証します。したがって、組織認証局はeDirectoryのセキュリティ識別情報管理機能を利用して、組織認証局のセキュリティを維持しながら、管理タスクを減らすことができます。

ユーザ自己プロビジョニング

これまで、ユーザ証明書を作成するには認証局に対する管理権だけでなく、ユーザオブジェクトに対する権利も必要でした。ユーザ自己プロビジョニングにより、認証局に対する管理権が不要になります。ただし、userCertificate属性、NDSPKI:UserCertificateInfo属性、およびSAS:SecretStore属性に対する読み込み(R)権と書き込み(W)権は引き続き必要です。

証明書の作成を要求するユーザが認証局に対する管理権を持っている場合、証明書の作成は、ユーザ自己プロビジョニングが有効にされているかどうかによって影響を受けることはありません。証明書の作成を要求するユーザが認証局に対する管理権を持っていない場合は、要求に含まれるサブジェクト名が、ユーザのeDirectory DNと、sasAllowableSubjectNames属性に含まれるすべての値と比較されます。

サブジェクト名が一致すると、認証局は、すべてのサブジェクト代替名を調べて適切であることを確認します。認証局はそのために、複数のサブジェクト代替名がないことを確認します。代替名が存在する場合、そのタイプは電子メールの名前でなければならず、ユーザオブジェクトに設定済みの電子メールの名前と一致していなければなりません。これらすべての確認に成功すると、認証局に対する管理権を認証局から要求されることなく、証明書を作成できます。

ユーザ自己プロビジョニングを使用するには、次の手順に従います。

サーバ自己プロビジョニング

これまで、サーバ証明書を作成するには、認証局に対する管理権だけでなく、サーバ証明書が作成されたコンテキストに対する管理権も必要でした。サーバ自己プロビジョニングにより、認証局に対する管理権が不要になります。ただし、サーバ証明書が作成されたコンテキストに対する管理権は引き続き必要です。

サーバ証明書を作成するには、認証局に対する管理権が必要です。証明書の作成は、サーバ自己プロビジョニングが有効にされているかどうかによって影響を受けることはありません。認証局に対する必要な管理権を持っていない場合は、iManagerの［認証局の設定］タスクで［CAを操作するには読み込み権が必要］オプションを有効にして、認証局を操作してください。次のいずれかに当てはまる場合、認証局に対する管理権は必要ありません。

デフォルトでは、認証局のNDSPKI:Private Key属性に対する書き込み権はサーバに付与されません。iManagerの［認証局の設定］タスクで、［CAを操作するには書き込み権が必要］オプションが有効にされている場合、認証局のNDSPKI:Private Key属性に対する読み込み権をサーバに付与する必要があります。

サーバ自己プロビジョニングを使用するには、次の手順に従います。

証明書の自己プロビジョニングと証明書の発行タスク

証明書の発行タスクでは、PKCS#10証明書署名要求(CSR)を使用して証明書を作成できます。ユーザはこのタスクを使用して、どのeDirectoryオブジェクトにも関連付けられていない証明書を作成できます。証明書の作成を要求するユーザが認証局に対する管理権を持っている場合、証明書の作成には影響がありません。証明書の作成を要求するユーザが認証局に対する管理権を持っていなければ、証明書の要求はユーザ自己プロビジョニングリクエストとして扱われます。ただし、ユーザがオブジェクトのuserCertificate属性、NDSPKI:UserCertificateInfo属性、およびSAS:SecretStore属性に対する管理権を持っている必要はありません。これは、証明書はeDirectoryに保管されないためです。したがって、オブジェクトに対する権利は必要ありません。

認証局に対する管理権を持たないユーザが証明書を発行するには、ユーザ自己プロビジョニングが有効にされている必要があります。それには、ユーザ自己プロビジョニングのステップ1から3に従います。

証明書の発行タスクについては、公開鍵証明書の発行を参照してください。

PKIヘルスチェック機能

eDirectory以外のアプリケーションにX.509認定を提供してほしいというお客様からの要望に応え、現在、NetIQ Certificate Serverに組み込まれたPKIヘルスチェックコードでX.509認定と鍵を自動的にファイルシステムにエクスポートして、eDirectoryが生成した証明書とeDirectoryで管理される証明書を、eDirectory以外のアプリケーションが利用できるようになっています。

PKIヘルスチェックが実行されると、証明書の秘密鍵を含め、既存の証明書が自動的に上書きされます。ただし、有効な証明書と秘密鍵が削除されないようにするため、PKIヘルスチェックは既存の証明書と鍵がeDirectoryで設定されているものと同じであるかどうかを判別します。eDirectoryで設定されているものと異なる場合は、PKIヘルスチェックはそれらのファイルをバックアップしてから上書きします。したがって、外部ソース(VeriSign*など)から取得された証明書が削除されることはありません。

SAS:Serviceオブジェクトにサーバの環境設定が作成された後、指定のサーバに関連付けられた鍵と証明書が自動的にファイルシステムにエクスポートされます。eDirectory内で鍵と証明書が置き換えられるか更新される場合(たとえば、サーバ証明書オブジェクトが削除されて、同じ名前で新しいサーバ証明書オブジェクトが作成された場合)、次のPKIヘルスチェックの実行時に新しい鍵と証明書が自動的にファイルシステムにエクスポートされます。

PKIヘルスチェックの詳細については、セクション 25.4.10, PKIヘルスチェックを参照してください。

PKIヘルスチェックでX.509認定と鍵を自動的にファイルシステムにエクスポートするには、その前に、SAS:Serviceオブジェクトを設定する必要があります。これは、PKIヘルスチェックがSAS:Serviceオブジェクトの設定を読み込むためです。SAS:Serviceオブジェクトを設定する方法については、eDirectory証明書をエクスポートするためのSAS:Serviceオブジェクトの設定を参照してください。

eDirectory証明書をエクスポートするためのSAS:Serviceオブジェクトの設定

eDirectoryのサーバ証明書をファイルシステムにエクスポートするには、その前に、SAS:Serviceオブジェクトにサーバ用の環境設定を作成する必要があります。使用しているeDirectoryサーバによって、自動的に作成できる場合も、手動で作成できる場合もあります。以降のセクションで、これらのオプションについて詳しく説明します。

ルート認証局コンテナの作成

このタスクについては、ルート認証局コンテナの作成で説明されています。

ルート認証局オブジェクトの作成

このタスクについては、ルート認証局オブジェクトの作成で説明されています。

ルート認証局オブジェクトのプロパティの表示

任意のeDirectoryオブジェクトで表示できるeDirectoryの権利とプロパティに加え、ルート認証局オブジェクトに固有のプロパティを表示することもできます。これらのプロパティには、証明書の発行者、ステータス、有効期間があります。

ルート認証局証明書の置き換え

このタスクによって、ルート認証局オブジェクトに保管されているルート認証局証明書を置き換えることができます。ルート認証局証明書の有効期限が切れている場合は、このタスクを実行する必要があります。

ルート認証局証明書は、ルート認証局オブジェクトのプロパティページで置き換えることができます。

ルート認証局オブジェクトの検証

証明書に問題があることが疑われる場合、または失効していると思われる場合は、iManagerを使用して簡単に証明書を検証できます。外部認証局によって発行された証明書を含め、eDirectoryツリー内のすべての証明書を検証できます。

証明書の検証プロセスには、証明書のデータだけでなく、証明書チェーン内のデータに対する複数のチェックが含まれます。証明書チェーンは、ルート認証局証明書と、必要に応じて1つ以上の中間認証局の証明書からなります。

証明書チェーン内のすべての証明書が有効であれば、結果は有効になります。現在の時刻が証明書の有効期間内であるか、証明書が取り消されていないか、信頼されている認証局によって署名されているかなど、事前定義された一連の条件を証明書が満たすと、その証明書は有効であると見なされます。CRL配布ポイント拡張機能またはOCSP AIA拡張機能を使用している証明書に限り、取り消されているかどうかがチェックされます。

証明書チェーン内の1つ以上の証明書が無効であると判明した場合、または有効であると断定できない場合、結果は無効になります。このような場合は、無効と見なされた証明書とその理由に関する追加情報が提供されます。理由に関する詳細については、［ヘルプ］をクリックしてください。

ルート認証局証明書を検証するには、次の手順に従います。

ルート認証局証明書の取り消し

鍵または認証局が侵害されている場合、証明書が別の証明書によって置き換えられてしまった場合、証明書がCRLから削除された場合など、さまざまな理由で証明書を取り消す必要があると判断することがあるかもしれません。

手動によるCRLコンテナの作成

NetIQ Certificate Serverのインストール時に、ユーザがCRLコンテナの作成に必要な権利を持っている場合は、CRLコンテナが作成されます。そうでない場合は、インストールが完了してから、適切な権利を持つユーザが手動でCRLコンテナを作成できます。

CRLコンテナの削除

CRLコンテナを削除することはできますが、そうすることはお勧めしません。

通常、関連する配布ポイントを含む最後の証明書の有効期限が切れてから1日経過するまで、CRLコンテナ、CRL設定オブジェクト、CRLオブジェクト、CRLファイルは削除しません。

CRL設定オブジェクトの作成

CRL設定オブジェクトは、CRLコンテナ内に作成できます。このオブジェクトは、eDirectoryツリーで使用可能なCRLオブジェクトの環境設定情報を格納するものです。通常、ツリーにはCRL設定オブジェクトが1つだけあります。新しい組織認証局を作成またはロールオーバする場合には、複数のCRL設定オブジェクトが必要になりますが、新しい証明書を作成するために使用できるCRL設定オブジェクトは1つだけです。

CRL設定オブジェクトは、CRLコンテナ内に存在します。

CRL設定オブジェクトのアクティブ化

eDirectoryツリー内で複数のCRL設定オブジェクトを同時にアクティブにすることはできません。複数のCRL設定オブジェクトがある場合は、どのオブジェクトをアクティブにするか選択する必要があります。デフォルトでは、最初に作成されたCRL設定オブジェクトがアクティブになります。

CRL設定オブジェクトのプロパティの表示と変更

CRL設定オブジェクトの削除

CRL設定オブジェクトは削除できますが、推奨されていません。CRL設定オブジェクトを削除すると、サーバはCRLファイルを作成しなくなります。CRLオブジェクトで指定された場所にCRLファイルがすでに存在する場合は、有効期限が切れるまで、証明書の検証でそのファイルが使用し続けられます。証明書が期限切れになると、CRL配布ポイントでその既存のCRLファイルを参照しているすべての証明書の検証が失敗します。

通常、関連する配布ポイントを含む最後の証明書の有効期限が切れてから1日経過するまで、CRLコンテナ、CRL設定オブジェクト、CRLオブジェクト、CRLファイルは削除しません。

CRLオブジェクトの作成

このタスクによって、eDirectory内にサードパーティCRLを保管するためのCRLオブジェクト(cRLDistributionPoint)を作成できます。このオブジェクトは、eDirectoryツリー内の任意のコンテナに作成できます。ただし一般的な規則として、NetIQ CRLオブジェクトはCRL設定オブジェクト内にあるので、手動で作成する必要はありません。CRL設定オブジェクトを作成すると、CRLオブジェクトが自動的に作成されます。

CRLオブジェクトには、CRLの詳細情報が記載されたCRLファイルが含まれています。NetIQ CRLオブジェクトの場合、サーバが新しい証明書を発行するたびに、CRLファイルは自動的に作成および更新されます。その他のCRLオブジェクトの場合、サードパーティの認証局からCRLファイルをインポートする必要があります。

CRLオブジェクトを作成するには、次の手順に従います。

CRLファイルのエクスポート

CRL配布ポイントオブジェクトに含まれるCRLは、ファイルにエクスポートすることができます。

NetIQ CRLファイルをエクスポートするには、次の手順に従います。

サードパーティのCRLファイルをエクスポートするには、次の手順に従います。

CRLファイルの置き換え

CRLファイルを置き換えることはできますが、そうすることはお勧めしません。

CRLファイルがCRL設定オブジェクトにない場合は、［インポート］ボタンが表示されます。

CRLオブジェクトのプロパティの表示

NetIQ CRLオブジェクトのプロパティを表示するには、次の手順に従います。

サードパーティのCRLオブジェクトのプロパティを表示するには、次の手順に従います。

CRLオブジェクトの削除

CRLオブジェクトを削除すると、サーバが次にCRLファイルを生成するときにCRLオブジェクトが再作成されます。iManagerを使用して作成したCRLオブジェクトを削除しそれをインポートする場合、そのオブジェクトは永続的に失われ、そのオブジェクトを参照するすべての証明書は無効と見なされます。

通常、関連する配布ポイントを含む最後の証明書の有効期限が切れてから1日経過するまで、CRLコンテナ、CRL設定オブジェクト、CRLオブジェクト、CRLファイルは削除しません。

複数のセキュリティコンテナ、組織認証局、KAPコンテナ、およびW0オブジェクトの解決

NetIQ Certificate Serverは、eDirectoryツリー内の複数のサーバにインストールできます。ただし、NetIQ Certificate Serverが適切に機能するためには、ツリー内にセキュリティコンテナ、組織認証局、KAPコンテナ、およびW0オブジェクトがそれぞれ1つだけ存在していなければなりません。

NetIQ Certificate ServerをeDirectoryツリー内の複数のサーバにインストールする場合は、eDirectoryにNetIQ Certificate Serverの各インストール間で複製を許可する必要があります。eDirectoryに複製を許可しなければ別のサーバへのインストールで、ツリーにすでにセキュリティコンテナ、組織認証局、KAPコンテナ、およびW0オブジェクトが存在することが認識されず、これらのオブジェクトが同じeDirectoryツリー内の別のサーバで再作成される可能性があります。

以下の項目で、考えられるシナリオとその解決方法について説明します。

セキュリティコンテナの復元または再作成

セキュリティコンテナを削除した場合、セキュリティコンテナを復元または再作成するまでは、組織認証局を作成することができません。

セキュリティコンテナを復元するには、セキュリティコンテナが含まれるeDirectoryのパーティションを復元します。

セキュリティコンテナを再作成するには、次の2つの方法のいずれかを使用します。

KAPおよびW0の復元または再作成

KAPまたはW0オブジェクトを削除しないでください。削除すると、それまでに作成したすべてのユーザ証明書が無効になります。これらのオブジェクトのいずれかを削除した場合は、NovellサポートWebサイトにアクセスし、TID番号3032354の「How to Restore or Recreate KAP and W0 Objects」を検索し、KAPおよびW0を復元してこの問題を解決する方法を参照してください。問題が修正されるまでは、NetIQ Certificate Server、Single Sign-on、NMAS、またはeDirectoryをインストールしようとしないでください。