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


CA 設定は、発行される証明書の実際のタイプに関係なく、発行する証明書の特性の多くを決定します。CA 自体の有効期間、識別名、および許可される暗号化アルゴリズムに対する制約は、発行された証明書の同じ特性に影響を与えます。さらに、Certificate Manager には、発行するさまざまな種類の証明書のルールを設定する事前定義されたプロファイルがあり、追加のプロファイルを追加または変更できます。これらのプロファイル設定は、発行した証明書にも影響します。

5.4.1. インストールする証明書の決定

Certificate System サブシステムが最初にインストールおよび設定されると、それにアクセスして管理するために必要な証明書が自動的に作成されます。これには、エージェントの証明書、サーバー証明書、およびサブシステム固有の証明書が含まれます。これらの初期証明書は 表5.1「初期サブシステム証明書」 に表示されます。
表5.1 初期サブシステム証明書
サブシステム 証明書
Certificate Manager
  • CA 署名証明書
  • OCSP 署名証明書
  • SSL/TLS サーバー証明書の場合
  • サブシステム証明書
  • ユーザー (エージェント/管理者) 証明書
  • 監査ログ署名証明書
OCSP
  • OCSP 署名証明書
  • SSL/TLS サーバー証明書の場合
  • サブシステム証明書
  • ユーザー (エージェント/管理者) 証明書
  • 監査ログ署名証明書
KRA
  • トランスポート証明書
  • ストレージ証明書
  • SSL/TLS サーバー証明書の場合
  • サブシステム証明書
  • ユーザー (エージェント/管理者) 証明書
  • 監査ログ署名証明書
TKS
  • SSL/TLS サーバー証明書の場合
  • ユーザー (エージェント/管理者) 証明書
  • 監査ログ署名証明書
TPS
  • SSL/TLS サーバー証明書の場合
  • ユーザー (エージェント/管理者) 証明書
  • 監査ログ署名証明書
既存のサブシステム証明書を置き換える際の注意点がいくつかあります。
  • ルート CA の新しい自己署名 CA 証明書を作成するときに新しいキーペアを生成すると、以前の CA 証明書で発行されたすべての証明書が無効になります。
    これは、古いキーを使用して CA によって発行または署名された証明書が機能しないことを意味します。下位 Certificate Manager、KRA、OCSP、TKS、および TPS は機能しなくなり、エージェントはエージェントインターフェイスにアクセスできなくなります。
    これと同じ状況は、下位 CA の CA 証明書が新しいキーペアを持つものに置き換えられた場合に発生します。その CA によって発行されたすべての証明書は無効になり、機能しなくなります。
    新しいキーペアから新しい証明書を作成する代わりに、既存の CA 署名証明書を更新することを検討してください。
  • CA が OCSP に公開するように設定されていて、新しい CA 署名証明書または新しい CRL 署名証明書がある場合は、CA を OCSP に対して再識別する必要があります。
  • KRA 用に新しいトランスポート証明書が作成された場合は、CA の設定ファイル CS.cfg で KRA 情報を更新する必要があります。既存のトランスポート証明書は、ca.connector.KRA.transportCert パラメーターの新しい証明書に置き換える必要があります。
  • CA のクローンが作成されている場合は、マスター Certificate Manager の新しい SSL/TLS サーバー証明書を作成するときに、クローン CA の証明書データベースが新しい SSL/TLS サーバーの全証明書で更新する必要があります。
  • Certificate Manager が証明書と CRL を LDAP ディレクトリーに公開するように設定されており、SSL/TLS クライアント認証に SSL/TLS サーバー証明書を使用する場合は、適切な拡張子を付けて新しい SSL/TLS サーバー証明書を要求する必要があります。証明書をインストールしたら、公開ディレクトリーが新しいサーバー証明書を使用するように設定する必要があります。
  • サブシステムインスタンスに対して任意の数の SSL/TLS サーバー証明書を発行できますが、実際には 1 つの SSL/TLS 証明書のみが必要です。この証明書は、必要に応じて何度でも更新または交換できます。

5.4.2. CA 識別名の計画

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 は一意で識別する必要があります。

5.4.3. CA 署名証明書の有効期間の設定

Certificate Manager 署名証明書を含むすべての証明書には有効期間が必要です。Certificate System は、指定可能な有効期間を制限しません。証明書の更新の要件、証明書階層内の CA の位置、および PKI に含まれる公開 CA の要件に応じて、有効期間をできるだけ長く設定します。
Certificate Manager は、CA 署名証明書の有効期間よりも有効期間が長い証明書を発行することはできません。CA 証明書の有効期間よりも長い期間要求が行われた場合、要求された有効日は無視され、CA 署名証明書の有効期間が使用されます。

5.4.4. 署名キーの種類と長さの選択

署名鍵は、サブシステムが何かを検証して封印するために使用されます。CA は、CA 署名証明書を使用して、発行する証明書または CRL に署名します。OCSP は、署名証明書を使用して、証明書ステータス要求への応答を検証します。すべてのサブシステムは、ログファイル署名証明書を使用して監査ログに署名します。
署名キーは、署名操作の保護とセキュリティーを提供するために、暗号的に強力である必要があります。以下の署名アルゴリズムがセキュアであるとみなされます。
  • SHA256withRSA
  • SHA512withRSA
  • SHA256withEC
  • SHA512withEC
注記
Certificate System には、ネイティブの ECC サポートが含まれています。ECC 対応サードパーティーの PKCS #11 モジュールを読み込み、使用することも可能です。詳細は9章ECC システム証明書を使用するインスタンスのインストールを参照してください。
キー タイプ とともに、各キーには特定の ビット長 があります。キーは、より短い鍵よりも暗号で強力なと見なされます。ただし、キーの署名操作にはより長い時間がかかります。
設定ウィザードのデフォルトの RSA キーの長さは 2048 ビットです。機密性の高いデータまたはサービスへのアクセスを提供する証明書の場合は、長さを 4096 ビットに増やすことを検討してください。ECC キーは RSA キーよりもはるかに強力であるため、ECC キーの推奨長は 256 ビットであり、これは 2048 ビットの RSA キーと同等の強度です。

5.4.5. 証明書の拡張の使用

X.509 v3 証明書には、証明書に任意の数の追加フィールドを追加できる拡張フィールドが含まれています。証明書拡張機能は、代替サブジェクト名や使用制限などの情報を証明書に追加する方法を提供します。Red Hat Directory Server や Red Hat Certificate System などの古い Netscape サーバーは、PKIX パート 1 標準が定義される前に開発されたため、Netscape 固有の拡張機能が必要です。
X.509 v1 証明書の仕様は、公開鍵を X.500 ディレクトリーの名前にバインドするように設計されました。証明書がインターネットおよびエクストラネットで使用されるようになり、ディレクトリールックアップを常に実行できるとは限らなかったため、元の仕様ではカバーされていなかった問題領域が発生しました。
  • 信用。X.500 仕様は、厳密なディレクトリー階層を使用して信頼を確立します。対照的に、インターネットおよびエクストラネットのデプロイメントには、階層的な X.500 アプローチに準拠していない分散信頼モデルが含まれることがよくあります。
  • 証明書の使用。一部の組織では、証明書の使用方法を制限しています。たとえば、一部の証明書はクライアント認証のみに制限される場合があります。
  • 複数の証明書証明書ユーザーが、同じサブジェクト名でキーマテリアルが異なる複数の証明書を所有していることは珍しくありません。この場合、どのキーと証明書をどの目的に使用するかを特定する必要があります。
  • 代替名。目的によっては、証明書の公開鍵にもバインドされている代替サブジェクト名があると便利です。
  • 追加属性。一部の組織では、ディレクトリーで情報を検索できない場合など、追加情報を証明書に保存します。
  • CA に関連。証明書チェーンに中間 CA が含まれる場合は、CA 間の関係に関する情報を証明書に埋め込むと便利です。
  • CRL チェック。証明書の失効ステータスをディレクトリーに対して、または元の認証局で常に確認できるとは限らないため、証明書に CRL を確認する場所に関する情報を含めると便利です。
X.509 v3 仕様は、証明書の拡張機能の一般的な形式を定義し、証明書に含めることができる拡張機能を指定することにより、証明書の形式を変更して証明書内に追加情報を含めることにより、これらの問題に対処しました。X.509 v3 証明書用に定義された拡張機能により、追加の属性をユーザーまたは公開鍵に関連付け、証明書階層を管理できます。『インターネット X.509 公開鍵インフラストラクチャー証明書および CRL プロファイル』は、インターネット証明書に使用する一連の拡張機能と、証明書または CA 情報の標準的な場所を推奨しています。これらの拡張機能は 標準拡張機能 と呼ばれます。
注記
標準拡張の詳細は、RFC 2459RFC 3280、および RFC 3279 を参照してください。
証明書の 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』を参照してください。

5.4.5.1. 証明書の拡張機能の構造

RFC 3280 では、X.509 証明書拡張は以下のように定義されます。
Extension  ::=  SEQUENCE  {

extnID OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING  }
証明書の拡張機能が次のもので設定されていることを意味します。
  • 拡張のオブジェクト識別子 (OID)。この識別子は、拡張子を一意に識別します。また、値フィールドの ASN.1 タイプの値や、値が解釈される方法も決定します。拡張機能が証明書に表示されると、OID は拡張機能 ID フィールド (extnID) として示されます。また、対応する ASN.1 エンコード構造は、オクテット文字列の値 (extnValue) として示されます。
  • critical というフラグまたはブール値フィールド
    このフィールドに割り当てられた値 (true または false のいずれか) は、拡張子が証明書にとって重要かどうかを示します。
    • 拡張機能が重要であり、拡張機能の ID に基づいて拡張機能を理解しないアプリケーションに証明書が送信された場合は、アプリケーションが証明書を拒否する必要があります。
    • 拡張機能が重要ではなく、拡張機能の ID に基づいて拡張機能を理解しないアプリケーションに証明書が送信された場合、アプリケーションは拡張機能を無視して証明書を受け入れることができます。
  • 拡張の値の DER エンコーディングを含む octet 文字列。
通常、証明書を受信するアプリケーションは、拡張 ID をチェックして、ID を認識できるかどうかを判断します。可能であれば、エクステンション ID を使用して、使用する値のタイプを判断します。
X.509 v3 標準仕様で定義されている標準拡張には、以下が含まれます。
  • 証明書の署名に使用されるキーである CA の公開キーを識別する Authority Key Identifier 拡張。
  • サブジェクトの公開キーを識別するサブジェクトキー識別子拡張。キーは認証されています。
注記
すべてのアプリケーションがバージョン 3 拡張機能の証明書をサポートするわけではありません。これらの拡張機能をサポートするアプリケーションは、これらの特定の拡張機能の一部またはすべてを解釈できない場合があります。

5.4.6. 証明書プロファイルの使用およびカスタマイズ

証明書には、タイプとアプリケーションが異なります。これらは、企業ネットワークのシングルサインオン環境の確立、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 で必要となる証明書プロファイルを決定します。発行される証明書のタイプごとに、少なくとも 1 つのプロファイルが必要です。証明書の種類ごとに複数の証明書プロファイルを用意して、特定の種類の証明書に対して異なる認証方法や異なるデフォルトや制約を設定することができます。管理インターフェイスで使用可能な証明書プロファイルはすべて、エージェントによって承認され、エンドエンティティーによって登録に使用されます。
  • 使用されていない証明書プロファイルを削除します。
  • 会社の証明書の特定の特性について、既存の証明書プロファイルを変更します。
    • 証明書プロファイルに設定されているデフォルト、デフォルトに設定されているパラメーターの値、または証明書の内容を制御する制約を変更します。
    • パラメーターの値を変更して、設定された制約を変更します。
    • 認証方法を変更します。
    • 入力ページのフィールドを制御する証明書プロファイルの入力を追加または削除して、入力を変更します。
    • 出力を追加または削除します。

5.4.6.1. SSL サーバー証明書への SAN 拡張機能の追加

Certificate System を使用すると、ルート以外の CA またはその他の Certificate System インスタンスのインストール時に、SSL サーバー証明書にサブジェクト代替名 (SAN) 拡張機能を追加できます。これを行うには、/usr/share/pki/ca/profiles/ca/caInternalAuthServerCert.cfg ファイルの指示に従い、pkispawn ユーティリティーに提供されている設定ファイルに次のパラメーターを追加します。
pki_san_inject
このパラメーターの値を True に設定します。
pki_san_for_server_cert
必要な SAN 拡張機能のリストをコンマで区切って指定します。
以下に例を示します。
pki_san_inject=True
pki_san_for_server_cert=intca01.example.com,intca02.example.com,intca.example.com

5.4.7. 認証方法の計画

「証明書プロファイルの使用およびカスタマイズ」 で暗示されるように、証明書プロセスの 認証 とは、証明書を要求するユーザーまたはエンティティーが、自分が本人であることを証明する方法を意味します。Certificate System がエンティティーを認証できる方法は 3 つあります。
  • エージェントの承認 登録では、承認のためにエンドエンティティーがエージェントに送信されます。エージェントは証明書要求を承認します。
  • 自動 登録では、エンドエンティティー要求はプラグインを使用して認証され、証明書要求が処理されます。エージェントは登録プロセスに関与していません。
  • CMC 登録 では、サードパーティーのアプリケーションが、エージェントによって署名されてから自動的に処理される要求を作成できます。
Certificate Manager は、最初にエージェント承認の登録と CMC 認証用に設定されています。自動登録を有効にするには、認証プラグインモジュールのいずれかを設定します。サブシステムの単一インスタンスで、1 つ以上の複数の認証方法を設定できます。HTML 登録ページには、使用されるメソッドを指定する非表示値が含まれます。証明書プロファイルを使用すると、有効なプロファイルごとにエンドエンティティー登録ページが動的に生成されます。この証明書プロファイルに関連付けられた認証方法は、動的に生成される登録ページで指定します。
認証プロセスは単純です。
  1. エンドエンティティーは登録のリクエストを送信します。リクエストの送信に使用されるフォームは、認証および登録のメソッドを識別します。すべての HTML フォームはプロファイルにより動的に生成され、適切な認証方法をフォームと自動的に関連付けます。
  2. 認証方法がエージェント承認の登録である場合、要求は CA エージェントの要求キューに送信されます。キューの要求に対する自動通知が設定されている場合は、新しい要求が受信された適切なエージェントにメールが送信されます。エージェントは、そのフォームに対して許可される要求とそのプロファイル制約を修正できます。承認されると、要求は Certificate Manager に設定された証明書プロファイルに合格する必要があり、合格すると証明書が発行されます。証明書が発行されると、内部データベースに保存され、シリアル番号または要求 ID によってエンドエンティティーページのエンドエンティティーによって取得できます。
  3. 認証方法が自動化されている場合、エンドエンティティーは、LDAP ユーザー名やパスワードなど、ユーザーを認証するために必要な情報とともに要求を送信します。ユーザーが正常に認証されると、リクエストはエージェントのキューに送信されずに処理されます。要求が Certificate Manager の証明書プロファイル設定に合格すると、証明書が発行され、内部データベースに保管されます。HTML フォームを介して即座に終了エンティティーに配信されます。
証明書要求の認証方法の要件は、必要なサブシステムとプロファイル設定に直接影響を与える可能性があります。たとえば、エージェントが承認した登録で、エージェントが要求者に直接会い、裏付けされた書類を使用して身元を確認する必要がある場合、認証プロセスは時間がかかるだけでなく、エージェントと要求者の両方の物理的な可用性に制約を受ける可能性があります。

5.4.8. 証明書および CRL の公開

CA は、証明書と CRL の両方を公開できます。証明書は、プレーンファイルまたは LDAP ディレクトリーに公開できます。CRL は、ファイルまたは LDAP ディレクトリーに公開することもできます。また、証明書の検証を処理するために OCSP レスポンダーに公開することもできます。
パブリッシュの設定は非常にシンプルで、簡単に調整できます。ただし、継続性とアクセシビリティーのためには、証明書および CRL をどこで公開する必要があるか、およびクライアントがそれらにアクセスできるようにする必要があるかを計画することが推奨されます。
LDAP ディレクトリーに公開するには、公開が機能するようにディレクトリーの特別な設定が必要です。
  • 証明書がディレクトリーに公開されている場合、証明書が発行されるすべてのユーザーまたはサーバーに、LDAP ディレクトリーに対応するエントリーがある必要があります。
  • CRL がディレクトリーに公開されている場合は、CRL を発行した CA のエントリーに公開する必要があります。
  • SSL/TLS の場合、ディレクトリーサービスは SSL/TLS で設定する必要があり、任意で、Certificate Manager が証明書ベースの認証を使用できるように設定する必要があります。
  • ディレクトリー管理者は、LDAP ディレクトリーへの DN (エントリー名) とパスワードベースの認証を制御するための適切なアクセス制御ルールを設定する必要があります。

5.4.9. CA 署名証明書の更新または再発行

CA 署名証明書の有効期限が切れると、CA の対応する署名キーで署名されたすべての証明書が無効になります。エンドエンティティーは CA 証明書の情報を使用して、証明書の信頼性を検証します。CA 証明書自体が期限切れになると、アプリケーションは証明書を信頼できる CA にチェーンできません。
CA 証明書の有効期限を解決する方法は 2 つあります。
  • CA 証明書を 更新 するには、古い CA 証明書と同じサブジェクト名と公開鍵および秘密鍵の内容を使用し、有効期間を延長した新しい CA 証明書を発行する必要があります。古い CA 証明書の有効期限が切れる前に、新しい CA 証明書がすべてのユーザーに配布される限り、証明書を更新すると、古い CA 証明書で発行された証明書は、有効期間の全期間にわたって機能し続けることができます。
  • CA 証明書を 再発行すること には、新しい名前、公開鍵と秘密鍵の内容、および有効期限を持つ新しい CA 証明書を発行することが含まれます。これにより、CA 証明書の更新に関連するいくつかの問題が回避されますが、管理者とユーザーの両方が実装するためにより多くの作業が必要になります。有効期限が切れていないものも含め、古い CA によって発行されたすべての証明書は、新しい CA によって更新する必要があります。
CA 証明書の更新または再発行には、問題があり、利点があります。Certificate Manager をインストールする前に、CA 証明書の更新または再発行の計画を開始し、計画された手順が PKI デプロイメントの拡張、ポリシー、およびその他の側面に与える影響を検討します。
注記
拡張機能 (たとえば authorityKeyIdentifier 拡張機能) の正しい使用は、古い CA 証明書から新しい CA 証明書への移行に影響を与える可能性があります。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.