5.4. サブシステム証明書の要件の決定

Certificate System サブシステムが最初にインストールおよび設定されると、それにアクセスして管理するために必要な証明書が自動的に作成されます。これには、エージェントの証明書、サーバー証明書、およびサブシステム固有の証明書が含まれます。これらの初期証明書は 表5.1「初期サブシステム証明書」 に表示されます。

既存のサブシステム証明書を置き換える際の注意点がいくつかあります。

CA のコア要素は署名ユニットと Certificate Manager ID です。署名ユニットは、終了エンティティーが要求した証明書に署名します。Certificate Manager には、発行するすべての証明書に記載されている、独自の識別名 (DN) が必要です。

他の証明書と同様に、CA 証明書は DN を公開鍵にバインドします。DN は、エンティティーを一意に識別する一連の名前と値のペアです。たとえば、次の DN は、Example Corporation という名前の企業のエンジニアリング部門の Certificate Manager を識別します。

cn=demoCA, o=Example Corporation, ou=Engineering, c=US

Certificate Manager の DN には、名前と値のペアの組み合わせが多数あります。エンドエンティティーが検証できるため、DN は一意で識別する必要があります。

Certificate Manager 署名証明書を含むすべての証明書には有効期間が必要です。Certificate System は、指定可能な有効期間を制限しません。証明書の更新の要件、証明書階層内の CA の位置、および PKI に含まれる公開 CA の要件に応じて、有効期間をできるだけ長く設定します。

Certificate Manager は、CA 署名証明書の有効期間よりも有効期間が長い証明書を発行することはできません。CA 証明書の有効期間よりも長い期間要求が行われた場合、要求された有効日は無視され、CA 署名証明書の有効期間が使用されます。

署名鍵は、サブシステムが何かを検証して封印するために使用されます。CA は、CA 署名証明書を使用して、発行する証明書または CRL に署名します。OCSP は、署名証明書を使用して、証明書ステータス要求への応答を検証します。すべてのサブシステムは、ログファイル署名証明書を使用して監査ログに署名します。

署名キーは、署名操作の保護とセキュリティーを提供するために、暗号的に強力である必要があります。以下の署名アルゴリズムがセキュアであるとみなされます。

キー タイプ とともに、各キーには特定の ビット長 があります。キーは、より短い鍵よりも暗号で強力なと見なされます。ただし、キーの署名操作にはより長い時間がかかります。

設定ウィザードのデフォルトの RSA キーの長さは 2048 ビットです。機密性の高いデータまたはサービスへのアクセスを提供する証明書の場合は、長さを 4096 ビットに増やすことを検討してください。ECC キーは RSA キーよりもはるかに強力であるため、ECC キーの推奨長は 256 ビットであり、これは 2048 ビットの RSA キーと同等の強度です。

X.509 v3 証明書には、証明書に任意の数の追加フィールドを追加できる拡張フィールドが含まれています。証明書拡張機能は、代替サブジェクト名や使用制限などの情報を証明書に追加する方法を提供します。Red Hat Directory Server や Red Hat Certificate System などの古い Netscape サーバーは、PKIX パート 1 標準が定義される前に開発されたため、Netscape 固有の拡張機能が必要です。

X.509 v1 証明書の仕様は、公開鍵を X.500 ディレクトリーの名前にバインドするように設計されました。証明書がインターネットおよびエクストラネットで使用されるようになり、ディレクトリールックアップを常に実行できるとは限らなかったため、元の仕様ではカバーされていなかった問題領域が発生しました。

X.509 v3 仕様は、証明書の拡張機能の一般的な形式を定義し、証明書に含めることができる拡張機能を指定することにより、証明書の形式を変更して証明書内に追加情報を含めることにより、これらの問題に対処しました。X.509 v3 証明書用に定義された拡張機能により、追加の属性をユーザーまたは公開鍵に関連付け、証明書階層を管理できます。『インターネット X.509 公開鍵インフラストラクチャー証明書および CRL プロファイル』は、インターネット証明書に使用する一連の拡張機能と、証明書または CA 情報の標準的な場所を推奨しています。これらの拡張機能は 標準拡張機能 と呼ばれます。

証明書の X.509 v3 標準を使用すると、組織はカスタム拡張機能を定義して証明書に含めることができます。これらの拡張機能は、プライベート 拡張機能、プロプライエタリー 拡張機能、またはカスタム 拡張機能と呼ばれ、組織またはビジネスに固有の情報を伝達します。アプリケーションは、プライベートの重要な拡張機能を含む証明書を検証できない可能性があるため、これらを広範囲の状況で使用することは推奨されません。

X.500 および X.509 の仕様は、主に大手通信事業者や政府機関などの国際的な通信ネットワーク関係者を対象とした国際機関である ITU (International Telecommunication Union) によって管理されています。インターネットの基礎となる標準の多くを管理する IETF (Internet Engineering Task Force) は、現在、公開鍵インフラストラクチャー X.509 (PKIX) 標準を開発しています。これらの提案された標準は、インターネットで使用するための拡張機能に対する X.509v3 アプローチをさらに改良します。証明書および CRL の推奨事項は、提案された標準ステータスに達しており、PKIX パート 1 と呼ばれるドキュメントに記載されています。

他の 2 つの標準、Abstract Syntax Notation One (ASN.1) および Distinguished Encoding Rules (DER) は、Certificate System と一般的な証明書で使用されます。これらは CCITT 勧告 X.208 および X.209 で指定されます。ASN.1 および DER の概要については、RSA Laboratories の Web サイト (http://www.rsa.com) で入手できる『A Layman's Guide to a Subset of ASN.1, BER, and DER』を参照してください。

Extension  ::=  SEQUENCE  {

extnID OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING  }

証明書には、タイプとアプリケーションが異なります。これらは、企業ネットワークのシングルサインオン環境の確立、VPN のセットアップ、電子メールの暗号化、または Web サイトへの認証に使用できます。異なる種類のユーザーに対して同じタイプの証明書に対して異なる要件が存在する可能性があるのと同様に、これらすべての証明書の要件は異なる可能性があります。これらの証明書の特性は、証明書プロファイル で設定されます。Certificate Manager は、ユーザーまたはマシンが証明書を要求するときに登録フォームとして使用する一連の証明書プロファイルを定義します。

証明書プロファイルは、認証方法、証明書の内容 (デフォルト)、内容の値の制約、証明書プロファイルの入力と出力の内容など、特定の種類の証明書の発行に関連するすべてを定義します。登録要求は証明書プロファイルに送信され、その証明書プロファイルで設定されたデフォルトと制約の対象となります。これらの制約は、要求が証明書プロファイルに関連付けられた入力フォームを介して送信されるか、他の手段を介して送信されるかに関係なく適用されます。証明書プロファイル要求から発行される証明書には、デフォルトで必要なコンテンツと、デフォルトのパラメーターで必要な情報が含まれています。制約は、証明書で許可されるコンテンツに対するルールを提供します。

たとえば、ユーザー証明書の証明書プロファイルは、証明書の有効期間を含む、その証明書のすべての側面を定義します。デフォルトの有効期間は 2 年に設定でき、この証明書プロファイルを介して要求された証明書の有効期間が 2 年を超えてはならないという制約をプロファイルに設定できます。ユーザーがこの証明書プロファイルに関連付けられた入力フォームを使用して証明書を要求すると、発行された証明書にはデフォルトで指定された情報が含まれ、2 年間有効です。ユーザーが、有効期間が 4 年の証明書を事前にフォーマットされた要求を提出した場合、制約により、このタイプの証明書の有効期間は最大 2 年となるため、要求は拒否されます。

発行する最も一般的な証明書プロファイルのセットが事前定義されました。これらの証明書プロファイルは、デフォルトと制約を定義し、認証方法を関連付け、証明書プロファイルに必要な入力と出力を定義します。

デフォルトの証明書プロファイルのパラメーターは変更できます。これには、認証方法、デフォルト、各プロファイルで使用される制約、プロファイル内の任意のパラメーターに割り当てられた値、入力、および出力が含まれます。他のタイプの証明書用に新しい証明書プロファイルを作成したり、証明書タイプ用に複数の証明書プロファイルを作成したりすることもできます。特定のタイプの証明書に複数の証明書プロファイルがあり、同じタイプの証明書を異なる認証方法またはデフォルトと制約の異なる定義で発行できます。たとえば、SSL/TLS サーバー証明書の登録用に 2 つの証明書プロファイルがあり、1 つの証明書プロファイルは 6 カ月の有効期間の証明書を発行し、もう 1 つの証明書プロファイルは 2 年の有効期間の証明書を発行します。

入力は、登録フォームのテキストフィールドと、エンドエンティティーから収集する必要のある情報の種類を設定します。これには、証明書要求を貼り付けるためのテキスト領域の設定が含まれます。これにより、必要な要求情報を使用して、入力フォームの外部で要求を作成できます。入力値は、証明書の値として設定されます。デフォルトの入力は、Certificate System で設定できません。

出力は、正常な登録に対する応答ページがどのように表示されるかを指定します。通常は、ユーザーが読み取り可能な形式で証明書を表示します。デフォルトの出力には、結果の証明書の出力可能なバージョンが表示されます。他の出力は、PKCS #7 など、登録の最後に生成される情報のタイプを設定します。

ポリシーセットは、プロファイルを通じて処理されるすべての証明書に付加される制約とデフォルトの拡張機能のセットです。拡張機能は、有効期間やサブジェクト名の要件などの証明書の内容を定義します。プロファイルは 1 つの証明書要求を処理しますが、1 つの要求に複数の証明書の情報を含めることができます。PKCS#10 リクエストには、公開鍵が 1 つ含まれています。CRMF 要求には複数の公開鍵 (つまり、複数の証明書要求) を含めることができます。プロファイルには複数のポリシーセットが含まれる場合があり、各セットは CRMF 要求内で 1 つの証明書要求を処理する方法を指定します。

管理者は、既存の認証プラグインまたはメソッドを証明書プロファイルに関連付けることにより、証明書プロファイルを設定します。デフォルトと制約を有効にして設定し、入力と出力を定義します。管理者は、既存の証明書プロファイルを使用したり、既存の証明書プロファイルを変更したり、新しい証明書プロファイルを作成したり、この PKI で使用されない証明書プロファイルを削除したりできます。

証明書プロファイルが設定されると、エージェントサービスページの Manage Certificate Profiles ページに表示され、エージェントは証明書プロファイルを承認して有効にすることができます。証明書プロファイルを有効にすると、エンドエンティティーページの Certificate Profile タブに表示され、エンドエンティティーは証明書プロファイルを使用して証明書を登録できます。

エンドエンティティーインターフェイスの証明書プロファイル登録ページには、エージェントによって有効にされた各証明書プロファイルへのリンクが含まれています。エンドエンティティーがこれらのリンクの 1 つを選択すると、その証明書プロファイルに固有の登録フォームを含む登録ページが表示されます。登録ページは、プロファイルに定義された入力から動的に生成されます。認証プラグインが設定されている場合、ユーザーを認証するために追加のフィールドが追加される場合があります。

エンドエンティティーが、エージェントが承認した (手動) 登録 (認証プラグインが設定されていない登録) に関連付けられた証明書プロファイル要求を送信すると、証明書要求はエージェントサービスインターフェイスのキューに入れられます。エージェントは、登録のいくつかの側面を変更、要求、検証、キャンセル、拒否、更新、または承認することができます。エージェントは、リクエストを送信せずに更新したり、リクエストがプロファイルのデフォルトと制約に準拠していることを検証したりできます。この検証手順は検証のみを目的としており、リクエストが送信されることはありません。エージェントは、設定された制約に拘束されます。制約に違反するような方法でリクエストを変更することはできません。署名付き承認は即座に処理され、証明書が発行されます。

証明書プロファイルが認証方法に関連付けられている場合は、要求がすぐに承認され、ユーザーが認証に成功し、必要なすべての情報が提供され、要求が証明書プロファイルに設定された制約に違反しない場合は、証明書が自動的に生成されます。サブジェクト名や有効期間など、ユーザーが指定した設定を許可するプロファイルポリシーがあります。証明書プロファイルフレームワークは、発行した証明書の元の証明書要求に設定されたユーザー定義のコンテンツを保持することもできます。

発行された証明書には、証明書の延長や有効期間など、この証明書プロファイルのデフォルトで定義されたコンテンツが含まれています。証明書の内容は、デフォルトごとに設定された制約によって制限されます。1 つのプロファイルに複数のポリシー (デフォルトと制約) を設定し、ポリシーセット ID で同じ値を使用して各セットを区別できます。これは、暗号鍵と署名鍵が同じプロファイルに送信されるデュアルキー登録を処理する場合に特に便利です。サーバーは、受け取る各リクエストで各セットを評価します。1 つの証明書が発行されると、1 つのセットが評価され、その他のセットは無視されます。デュアルキーペアが発行されると、最初のセットは最初の証明書要求で評価され、2 番目のセットは 2 番目の証明書要求で評価されます。単一の証明書を発行するために複数のセット、またはデュアルキーペアを発行するために複数のセットは必要ありません。

組織のプロファイルを、組織が使用する実際のニーズと予想される証明書の種類に合わせて調整します。

pki_san_inject=True
pki_san_for_server_cert=intca01.example.com,intca02.example.com,intca.example.com

「証明書プロファイルの使用およびカスタマイズ」 で暗示されるように、証明書プロセスの 認証 とは、証明書を要求するユーザーまたはエンティティーが、自分が本人であることを証明する方法を意味します。Certificate System がエンティティーを認証できる方法は 3 つあります。

Certificate Manager は、最初にエージェント承認の登録と CMC 認証用に設定されています。自動登録を有効にするには、認証プラグインモジュールのいずれかを設定します。サブシステムの単一インスタンスで、1 つ以上の複数の認証方法を設定できます。HTML 登録ページには、使用されるメソッドを指定する非表示値が含まれます。証明書プロファイルを使用すると、有効なプロファイルごとにエンドエンティティー登録ページが動的に生成されます。この証明書プロファイルに関連付けられた認証方法は、動的に生成される登録ページで指定します。

認証プロセスは単純です。

証明書要求の認証方法の要件は、必要なサブシステムとプロファイル設定に直接影響を与える可能性があります。たとえば、エージェントが承認した登録で、エージェントが要求者に直接会い、裏付けされた書類を使用して身元を確認する必要がある場合、認証プロセスは時間がかかるだけでなく、エージェントと要求者の両方の物理的な可用性に制約を受ける可能性があります。

CA は、証明書と CRL の両方を公開できます。証明書は、プレーンファイルまたは LDAP ディレクトリーに公開できます。CRL は、ファイルまたは LDAP ディレクトリーに公開することもできます。また、証明書の検証を処理するために OCSP レスポンダーに公開することもできます。

パブリッシュの設定は非常にシンプルで、簡単に調整できます。ただし、継続性とアクセシビリティーのためには、証明書および CRL をどこで公開する必要があるか、およびクライアントがそれらにアクセスできるようにする必要があるかを計画することが推奨されます。

LDAP ディレクトリーに公開するには、公開が機能するようにディレクトリーの特別な設定が必要です。

CA 署名証明書の有効期限が切れると、CA の対応する署名キーで署名されたすべての証明書が無効になります。エンドエンティティーは CA 証明書の情報を使用して、証明書の信頼性を検証します。CA 証明書自体が期限切れになると、アプリケーションは証明書を信頼できる CA にチェーンできません。

CA 証明書の有効期限を解決する方法は 2 つあります。

CA 証明書の更新または再発行には、問題があり、利点があります。Certificate Manager をインストールする前に、CA 証明書の更新または再発行の計画を開始し、計画された手順が PKI デプロイメントの拡張、ポリシー、およびその他の側面に与える影響を検討します。