計画、インストール、およびデプロイメントのガイド

対称キーの暗号化では、暗号化キーを複号鍵から計算することもできます。ほとんどの対称アルゴリズムでは、図1.1「対称鍵の暗号化」 に示されるように、同じ鍵が暗号化と復号の両方に使用されます。

図1.1 対称鍵の暗号化

対称鍵暗号化の実装は非常に効率的であるため、暗号化と復号化の結果としてユーザーに大きな時間遅延が発生することはありません。

対称鍵暗号化は、関係する 2 つの当事者によって対称鍵が秘密にされている場合にのみ有効です。他のユーザーが鍵を検出した場合は、機密性と認証の両方に影響します。承認されていない対称キーを持つユーザーは、その鍵で送信されたメッセージのみに復号できますが、新しいメッセージを暗号化して、鍵を使用して信頼できる送信者の 1 つから送信されたかのように送信することができます。

対称キーの暗号化は、SSL/TLS 通信で重要なロールを果たします。これは、TCP/IP ネットワーク上で認証、改ざん検出、および暗号化に幅広く使用されます。SSL/TLS は公開鍵の暗号化技術も使用します。これは、次のセクションで説明します。

公開鍵の暗号化 (非対称暗号化とも呼ばれます) には、エンティティーに関連付けられた鍵、公開鍵、および秘密鍵のペアが必要です。各公開鍵が公開され、対応する秘密鍵はシークレットが保持されます。(公開鍵の公開方法に関する詳細は、「証明書と認証」 を参照してください。)公開鍵で暗号化したデータは、対応する秘密鍵でのみ復号できます。図1.2「公開鍵の暗号化」 は、公開鍵の暗号化が機能する方法の簡単なビューを示しています。

図1.2 公開鍵の暗号化

図1.2「公開鍵の暗号化」 に表示されるスキームでは、公開鍵を自由に配布できますが、承認されたユーザーだけがこの鍵を使用して暗号化されたデータを読み取ることができます。一般的に、暗号化されたデータを送信するには、そのユーザーの公開鍵でデータは暗号化され、暗号化されたデータを対応する秘密鍵で復号します。

対称鍵暗号化と比較して、公開鍵暗号化はより多くの処理を必要とし、大量のデータの暗号化と復号には適さない場合があります。ただし、公開鍵の暗号化を使用して対称キーを送信できます。これにより、追加データの暗号化に使用できます。これは、SSL/TLS プロトコルによって使用される方法です。

図1.2「公開鍵の暗号化」 にあるスキームの逆もまた機能します。秘密鍵で暗号化されたデータは、対応する公開鍵でのみ復号できます。ただし、機密データを暗号化することは推奨される方法ではありません。これは、定義によって公開されている公開鍵を持つすべてのユーザーがデータを復号する可能性があるためです。それでも、秘密鍵暗号化は、電子商取引やその他の暗号化の商用アプリケーションにとって重要な要件であるデジタル署名を使用してデータに署名するために秘密鍵を使用できることを意味するため、便利です。その後、Mozilla Firefox などのクライアントソフトウェアは公開鍵を使用して、メッセージが適切な秘密鍵で署名され、署名されてから改ざんされていないことを確認できます。「デジタル署名」 は、この確認プロセスがどのように機能するかを説明しています。

暗号化アルゴリズムを 壊す と、暗号化されたデータにアクセスするための鍵をプレーンテキストで検索できます。対称アルゴリズムでは、アルゴリズムがテキストの暗号化に使用する鍵を判断しようとします。公開鍵アルゴリズムの場合、アルゴリズムを破ることは通常、2 人の受信者間で共有秘密情報を取得することを意味します。

対称アルゴリズムを壊す方法の 1 つは、適切なキーを見つけるまで、完全なアルゴリズム内のすべての鍵を単純に試すことです。公開鍵アルゴリズムの場合、鍵ペアの半分は公開されているため、残りの半分 (秘密鍵) は、複雑ではありますが、公開された数学的計算を使用して導出できます。アルゴリズムを壊す鍵を手動で検索することはブルートフォース攻撃と呼ばれます。

アルゴリズムを破ると、個人情報を傍受したり、なりすまして不正に検証したりするリスクが生じます。

アルゴリズムの キー強度 は、アルゴリズムを壊し、ブルートフォース攻撃と比較する最速な方法を見つけることで決定します。

対称キーでは、暗号化の実行に使用する鍵のサイズや 長さ において、暗号化強度が説明されています。通常は、より強力な暗号化が提供されます。キーの長さはビット単位で測定されます。

キーを破壊する最もよく知られている攻撃が、すべてのキーの可能性をテストするブルートフォース攻撃よりも速くない場合、暗号化キーは完全な強度であると見なされます。

異なるタイプのアルゴリズム (特に公開鍵アルゴリズム) では、対称鍵暗号と同じレベルの暗号化強度を実現するために、異なる鍵の長さが必要になる場合があります。RSA 暗号は、それが基づいている数学的問題の性質により、特定の長さのキーに対して可能なすべての値のサブセットのみを使用できます。対称キーの暗号化に使用されるその他の暗号は、特定の長さのキーに可能なすべての値を使用できます。より一致するオプションがあると、セキュリティーが強化されます。

RSA 鍵を解読することは比較的簡単であるため、RSA 公開鍵暗号化暗号は、暗号的に強力であると見なされるために、非常に長い鍵 (少なくとも 2048 ビット) を持っている必要があります。一方、対称鍵暗号は、ほとんどのアルゴリズムで 80 ビットという非常に短いキー長を使用すると、同等に強力であると見なされます。同様に、Elliptic Curve Digital Signature Algorithm (ECDSA) 暗号などの楕円曲線暗号 (ECC) に基づく公開鍵暗号では、RSA 暗号化よりもビットも少なくなる必要があります。

証明書とは、個人、サーバー、会社、または他のエンティティーを特定し、そのアイデンティティーを公開鍵に関連付けるために使用される電子ドキュメントです。運転免許または乗車のように、証明書は、一般的にユーザーのアイデンティティーを証明する証明を提供します。公開鍵暗号では、証明書を使用してなりすましの問題に対処します。

運転免許申請などの個人 ID を取得するには、そのユーザーが本人であることを検証する、他の形式の識別が必要です。証明書はほぼ同じように機能します。認証局 (CA) は ID を検証し、証明書を発行します。CA は、独立したサードパーティー、Certificate System などの独自の証明書発行サーバーソフトウェアを実行している組織のいずれかです。アイデンティティーの検証に使用される方法は、要求する証明書のタイプの特定の CA のポリシーによって異なります。証明書を実行する前に、CA は標準検証手順を使用してユーザーの ID を確認する必要があります。

CA によって発行された証明書は、特定の公開鍵を、従業員やサーバーの名前など、証明書が識別するエンティティーの名前にバインドします。証明書は、なりすましのための偽の公開鍵の使用を防ぐのに役立ちます。証明書で認定された公開鍵のみが、証明書で識別されたエンティティーが所有する対応する秘密鍵で機能します。

公開鍵の他に、証明書には常に識別するエンティティーの名前、有効期限、証明書を発行した CA 名、シリアル番号が含まれます。証明書には、発行する CA のデジタル署名が常に含まれます。CA のデジタル署名により、証明書は CA を把握して信頼しているが、証明書で識別したエンティティーを認識しないユーザーの有効な認証情報として機能できます。

CA のロールの詳細は、「CA 証明書による信頼の仕組み」 を参照してください。

認証 とは、アイデンティティーの確認を行うプロセスです。ネットワークの対話では、認証に、別の当事者による識別が必要です。ネットワーク上で認証を使用する方法は複数あります。証明書はその方法の 1 つになります。

通常、ネットワークの対話は、Web ブラウザーやサーバーなどのクライアント間で行われます。クライアント認証 とは、サーバーによりクライアント (ソフトウェアの使用を前提としたユーザー) を特定することを指します。サーバーの認証 とは、クライアントによりサーバー (ネットワークアドレスでサーバーの実行を想定している組織) を特定することを指します。

クライアントおよびサーバーの認証は、証明書がサポートする認証形式ではありません。たとえば、送信者を特定する証明書とともに、電子メールメッセージ上のデジタル署名は、メッセージの送信者を認証できます。同様に、HTML フォームのデジタル署名は、署名者を識別する証明書と組み合わせて、その証明書によって識別された人がフォームの内容に同意したという証拠を提供できます。認証に加えて、どちらの場合もデジタル署名はある程度の否認防止を保証します。デジタル署名は、署名者が後で電子メールまたはフォームを送信していないと主張することを困難にします。

クライアント認証は、ほとんどのイントラネットまたはエクストラネット内のネットワークセキュリティーの重要な要素です。クライアント認証には、主に 2 つの形式があります。

図1.4「パスワードを使用したクライアントのサーバーへの認証」 は、ユーザー名とパスワードを使用してユーザーを認証するプロセスを示しています。この例では、以下を前提としています。

図1.4 パスワードを使用したクライアントのサーバーへの認証

この認証プロセスの手順は次のとおりです。

この方法では、ユーザーがアクセスする各サーバーに新しいパスワードを提供する必要があり、管理者は各ユーザーの名前とパスワードを追跡する必要があります。

1.3.2.1. 証明書ベースの認証

証明書ベースの認証の利点の 1 つは、認証の最初の 3 ステップを、ネットワークを越えて送信されない 1 つのパスワードを供給する仕組みに置き換えることができ、管理者がユーザーの認証を一元的に制御できることです。これは シングルサインオン と呼ばれます。

図1.5「証明書を使用してクライアントをサーバーに対して認証する」 は、証明書と SSL/TLS を使用してクライアント認証がどのように機能するかを示しています。ユーザーをサーバーに認証するには、クライアントが無作為に生成されたデータの一部に署名し、ネットワーク全体で証明書と署名済みデータの両方を送信します。サーバーは、証明書および署名されたデータのデータに基づいてユーザーのアイデンティティーを認証します。

図1.4「パスワードを使用したクライアントのサーバーへの認証」 と同様に、図1.5「証明書を使用してクライアントをサーバーに対して認証する」 ではユーザーがすでにサーバーを信頼し、リソースを要求したこと、および要求されたリソースへのアクセスを付与する前にクライアント認証が要求されていることを前提としています。

図1.5 証明書を使用してクライアントをサーバーに対して認証する

図1.4「パスワードを使用したクライアントのサーバーへの認証」 の認証プロセスとは異なり、図1.5「証明書を使用してクライアントをサーバーに対して認証する」 の認証プロセスには SSL/TLS が必要です。図1.5「証明書を使用してクライアントをサーバーに対して認証する」 も、クライアントがサーバーに対してクライアントを識別するために使用できる有効な証明書を持っていることを前提としています。証明書ベースの認証は、秘密鍵を所有し、パスワードを知っているユーザーの両方に基づいているため、パスワードベースの認証よりも優先されます。ただし、これら 2 つの仮定は、権限のない担当者がユーザーのマシンまたはパスワードにアクセスできず、クライアントソフトウェアの秘密鍵データベースのパスワードが設定されており、ソフトウェアが適度な頻度でパスワードを要求するように設定されている場合にのみ当てはまります。

注記

パスワードベースの認証または証明書ベースの認証は、個々のマシンまたはパスワードへの物理的なアクセスに関連するセキュリティーの問題に対応します。公開鍵暗号は、一部のデータの署名に使用される秘密鍵が証明書の公開鍵に対応していることを確認することしかできません。マシンの物理的なセキュリティーを保護し、秘密鍵のパスワードを秘密にしておくことは、ユーザーの責任です。

図1.5「証明書を使用してクライアントをサーバーに対して認証する」 に記載されている認証手順は以下のとおりです。

1. クライアントソフトウェアは、そのクライアントに対して発行された証明書に発行される公開鍵に対応する秘密鍵のデータベースを維持します。クライアントは、証明書ベースのクライアント認証を必要とする SSL/TLS 対応サーバーに初めてアクセスしようとしたときなど、特定のセッション中にクライアントが初めてデータベースにアクセスする必要があるときに、このデータベースのパスワードを要求します。

   このパスワードを一度入力すると、他の SSL/TLS 対応サーバーにアクセスする場合でも、残りのセッションに対して再度入力する必要はありません。

2. クライアントは秘密鍵データベースのロックを解除し、ユーザーの証明書の秘密鍵を取得し、その秘密鍵を使用してクライアントとサーバーの両方からランダムなデータに署名します。このデータとデジタル署名は、秘密鍵の有効性の証拠となります。デジタル署名はその秘密鍵でのみ作成でき、SSL/TLS セッションに固有の署名済みデータに対して、対応する公開鍵で検証できます。
3. クライアントは、ユーザーの証明書とランダムに生成されたデータの両方をネットワーク経由で送信します。
4. サーバーは、証明書と署名済みデータを使用してユーザーのアイデンティティーを認証します。
5. サーバーは、クライアントが提示する証明書が LDAP ディレクトリー内のユーザーのエントリーに保存されていることを確認するなど、他の認証タスクを実行できます。その後、サーバーは、指定のユーザーが要求されたリソースにアクセスできるかどうかを確認します。この評価プロセスでは、LDAP ディレクトリーまたは企業のデータベースで追加情報を使用すると、さまざまな標準的な承認メカニズムを使用できます。評価の結果が正である場合、サーバーは、要求されたリソースにクライアントがアクセスすることを許可します。

証明書は、クライアントとサーバーと間の相互作用の認証部分を置き換えます。ユーザーがネットワーク全体でパスワードを送信しなければならない代わりに、シングルサインオンでは、ネットワーク経由で送信せずに、ユーザーが秘密鍵のデータベースパスワードを一度入力する必要があります。セッションの残りの部分では、クライアントはユーザーの証明書を提示して、遭遇したそれぞれの新しいサーバーでユーザーを認証します。認証されたユーザー ID に基づく既存の承認メカニズムには影響はありません。

証明書の目的は、信頼を確立することです。その使用法は、それが保証するために使用される信頼の種類によって異なります。提示した者の ID を確認するために、いくつかの種類の証明書が使用されたり、オブジェクトまたはアイテムが改ざんされていないことを確認したりするために使用されます。

Certificate System は、さまざまな用途、およびさまざまな形式で、さまざまな種類の証明書を生成できます。PKI インスタンスと Certificate System インスタンスの両方を管理するには、必要な証明書を計画し、必要な形式の決定や更新の計画方法など、証明書の管理方法を計画することが重要です。

LDAP ディレクトリー、ファイル署名証明書、およびその他のサブシステム証明書のデュアル用途証明書用の証明書登録フォームがあります。これらのフォームは、Certificate Manager のエンドエンティティーページで ui`8443/ca/ee/ca` から入手できます。

さまざまな Certificate System サブシステムがインストールされると、必要となる基本的な証明書とキーが生成されます。たとえば、Certificate Manager を設定すると、自己署名ルート CA の CA 署名証明書と、内部 OCSP 署名、監査署名、SSL/TLS サーバー、およびエージェントユーザー証明書が生成されます。KRA 設定時に、Certificate Manager はストレージ、トランスポート、監査署名、およびエージェント証明書を生成します。追加の証明書を個別に作成してインストールできます。

証明書の内容は、国際標準化団体である国際電気通信連合 (ITU) によって推奨されている X.509v3 証明書仕様に従って編成されています。

通常は、証明書の正確な内容について懸念する必要はありません。ただし、証明書を操作するシステム管理者は、証明書に含まれる情報にある程度精通している必要がある場合があります。

-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----

uid=doe, cn=John Doe,o=Example Corp.,c=US

Certificate:
Data:
   Version: v3 (0x2)
   Serial Number: 3 (0x3)
   Signature Algorithm: PKCS #1 MD5 With RSA Encryption
   Issuer: OU=Example Certificate Authority, O=Example Corp, C=US
   Validity:
    Not Before: Fri Oct 17 18:36:25 1997
    Not  After: Sun Oct 17 18:36:25 1999
   Subject: CN=Jane Doe, OU=Finance, O=Example Corp, C=US
   Subject Public Key Info:
    Algorithm: PKCS #1 RSA Encryption
    Public Key:
       Modulus:
          00:ca:fa:79:98:8f:19:f8:d7:de:e4:49:80:48:e6:2a:2a:86:
          ed:27:40:4d:86:b3:05:c0:01:bb:50:15:c9:de:dc:85:19:22:
          43:7d:45:6d:71:4e:17:3d:f0:36:4b:5b:7f:a8:51:a3:a1:00:
          98:ce:7f:47:50:2c:93:36:7c:01:6e:cb:89:06:41:72:b5:e9:
          73:49:38:76:ef:b6:8f:ac:49:bb:63:0f:9b:ff:16:2a:e3:0e:
          9d:3b:af:ce:9a:3e:48:65:de:96:61:d5:0a:11:2a:a2:80:b0:
          7d:d8:99:cb:0c:99:34:c9:ab:25:06:a8:31:ad:8c:4b:aa:54:
          91:f4:15
       Public Exponent: 65537 (0x10001)
   Extensions:
    Identifier: Certificate Type
      Critical: no
      Certified Usage:
      TLS Client
    Identifier: Authority Key Identifier
      Critical: no
      Key Identifier:
        f2:f2:06:59:90:18:47:51:f5:89:33:5a:31:7a:e6:5c:fb:36:
        26:c9
   Signature:
    Algorithm: PKCS #1 MD5 With RSA Encryption
   Signature:
 6d:23:af:f3:d3:b6:7a:df:90:df:cd:7e:18:6c:01:69:8e:54:65:fc:06:
 30:43:34:d1:63:1f:06:7d:c3:40:a8:2a:82:c1:a4:83:2a:fb:2e:8f:fb:
 f0:6d:ff:75:a3:78:f7:52:47:46:62:97:1d:d9:c6:11:0a:02:a2:e0:cc:
 2a:75:6c:8b:b6:9b:87:00:7d:7c:84:76:79:ba:f8:b4:d2:62:58:c3:c5:
 b6:c1:43:ac:63:44:42:fd:af:c8:0f:2f:38:85:6d:d6:59:e8:41:42:a5:
 4a:e5:26:38:ff:32:78:a1:38:f1:ed:dc:0d:31:d1:b0:6d:67:e9:46:a8:
 d:c4

-----BEGIN CERTIFICATE-----
MIICKzCCAZSgAwIBAgIBAzANBgkqhkiG9w0BAQQFADA3MQswCQYDVQQGEwJVUzER
MA8GA1UEChMITmV0c2NhcGUxFTATBgNVBAsTDFN1cHJpeWEncyBDQTAeFw05NzEw
MTgwMTM2MjVaFw05OTEwMTgwMTM2MjVaMEgxCzAJBgNVBAYTAlVTMREwDwYDVQQK
EwhOZXRzY2FwZTENMAsGA1UECxMEUHViczEXMBUGA1UEAxMOU3Vwcml5YSBTaGV0
dHkwgZ8wDQYJKoZIhvcNAQEFBQADgY0AMIGJAoGBAMr6eZiPGfjX3uRJgEjmKiqG
7SdATYazBcABu1AVyd7chRkiQ31FbXFOGD3wNktbf6hRo6EAmM5/R1AskzZ8AW7L
iQZBcrXpc0k4du+2Q6xJu2MPm/8WKuMOnTuvzpo+SGXelmHVChEqooCwfdiZywyZ
NMmrJgaoMa2MS6pUkfQVAgMBAAGjNjA0MBEGCWCGSAGG+EIBAQQEAwIAgDAfBgNV
HSMEGDAWgBTy8gZZkBhHUfWJM1oxeuZc+zYmyTANBgkqhkiG9w0BAQQFAAOBgQBt
I6/z07Z635DfzX4XbAFpjlRl/AYwQzTSYx8GfcNAqCqCwaSDKvsuj/vwbf91o3j3
UkdGYpcd2cYRCgKi4MwqdWyLtpuHAH18hHZ5uvi00mJYw8W2wUOsY0RC/a/IDy84
hW3WWehBUqVK5SY4/zJ4oTjx7dwNMdGwbWfpRqjd1A==
-----END CERTIFICATE-----

CA は ID を検証し、証明書を発行します。CA は、独立したサードパーティー、Certificate System などの独自の証明書発行サーバーソフトウェアを実行している組織のいずれかです。

証明書をサポートするクライアントまたはサーバーソフトウェアは、信頼できる CA 証明書のコレクションを維持します。これらの CA 証明書は、ソフトウェアが信頼または検証できる証明書の発行者を決定します。最も単純なケースでは、ソフトウェアは、証明書を持っている CA の 1 つによって発行された証明書のみを検証できます。信頼できる CA 証明書を CA 証明書のチェーンの一部にすることもできます。各証明書は、証明書階層の上位にある CA によって発行されます。

以下のセクションでは、証明書階層と証明書チェーンを使用して、信頼できる証明書ソフトウェアを決定する方法を説明します。

1.3.6.1. CA 階層

大規模な組織では、証明書を発行する責任を複数の CA に委任できます。たとえば、必要な証明書の数が多すぎて、単一の CA が維持できない場合があります。組織単位が異なれば、ポリシー要件も異なる場合があります。または、CA は、証明書を発行している人と同じ地理的領域に物理的に配置する必要がある場合があります。

これらの証明書発行の責任は、下位の CA 間で分割できます。X.509 標準には、CA の階層を設定するモデルが含まれています (例: 図1.6「認証局の階層の例」)。

図1.6 認証局の階層の例

ルート CA は階層の上部にあります。ルート CA の証明書は 自己署名証明書 です。つまり、証明書は、証明書を識別する同じエンティティーによってデジタル署名されます。ルート CA に直接従属する CA には、ルート CA によって署名された CA 証明書があります。階層内の下位 CA の下にある CA には、上位レベルの下位 CA によって署名された CA 証明書があります。

組織は、CA 階層の設定方法に多くの柔軟性を備えています。図1.6「認証局の階層の例」 では、例を 1 つだけ示します。

1.3.6.2. 証明書チェーン

CA 階層は証明書チェーンに反映されます。証明書チェーン は、連続する CA により発行された一連の証明書です。図1.7「証明書チェーンの例」 は、図1.6「認証局の階層の例」 に示される CA 階層に基づいて、2 つの下位 CA 証明書を介してルート CA の CA 証明書へのエンティティーを識別する証明書からそれに続く証明書チェーンを示しています。

図1.7 証明書チェーンの例

証明書チェーンは、階層のブランチから階層のルートへの証明書のパスを追跡します。証明書チェーンでは、以下が発生します。

• 各証明書の後に、その発行者の証明書が追加されます。

• 各証明書には、その証明書の発行者の名前 (DN) が含まれており、チェーン内の次の証明書のサブジェクト名と同じです。

  図1.7「証明書チェーンの例」 では、エンジニアリング CA 証明書には、その証明書を発行した CA (USA CA) の DN が含まれます。USA CA の DN はチェーン内の次の証明書のサブジェクト名でもあります。

• 各証明書は、発行者の秘密鍵で署名されます。この署名は、発行者の証明書内の公開鍵 (チェーン内の次の証明書) で検証できます。

  図1.7「証明書チェーンの例」 では、USA CA の証明書内の公開鍵を使用して、エンジニアリング CA に対して、USA CA の証明書のデジタル署名を検証できます。

1.3.6.3. 証明書チェーンの確認

証明書チェーンの検証では、特定の証明書チェーンが適切な形式で、有効で、適切に署名され、信頼できるものであることを確認します。以下のプロセスの説明は、認証用に提示される証明書から、証明書チェーンを形成および検証する最も重要な手順を示しています。

1. 証明書の有効期間は、検証者のシステムクロックによって提供される現在時刻に対してチェックされます。
2. 発行者の証明書が位置しています。ソースは、クライアントまたはサーバーのローカル証明書データベース、または SSL/TLS 接続と同様に、サブジェクトが提供した証明書チェーンのいずれかになります。
3. 証明書の署名は、発行者の証明書の公開鍵を使用して検証されます。
4. サービスのホスト名は、SAN (Subject Alternative Name) 拡張と照合されます。証明書にそのような拡張がない場合、ホスト名はサブジェクトの CN に対して比較されます。
5. システムは、証明書の基本制約要件、つまり、証明書が CA であるかどうか、および署名が許可されている子会社の数を確認します。
6. 発行者の証明書が検証者の証明書データベース内の検証者によって信頼されている場合、検証はここで正常に停止します。それ以外の場合は、発行者の証明書をチェックして、証明書タイプ拡張に適切な下位 CA 表示が含まれていることを確認し、チェーン検証をこの新しい証明書からやり直します。図1.8「ルート CA への証明書チェーンの確認」 は、このプロセスの例を示しています。

図1.8 ルート CA への証明書チェーンの確認

図1.8「ルート CA への証明書チェーンの確認」 は、ルート CA のみが検証機能のローカルデータベースに含まれる場合に何が発生するかを示しています。Engineering CA など、中間 CA のいずれかの証明書が検証者のローカルデータベースにある場合は、図1.9「中間認証局までの証明書チェーンの検証」 に示されているように、検証はその証明書で停止します。

図1.9 中間認証局までの証明書チェーンの検証

有効期限が切れている、署名が無効である、または証明書チェーンのいずれかの時点で発行元 CA の証明書がない場合は、認証が失敗します。図1.10「検証できない証明書チェーン」 は、root CA 証明書も中間 CA 証明書も検証者のローカルデータベースに含まれていない場合に、検証がどのように失敗するかを示しています。

図1.10 検証できない証明書チェーン

証明書失効リスト (CRL) の詳細は、「CRL」 を参照してください。

オンライン証明書ステータスプロトコル (OCSP) の詳細は、「OCSP サービス」 を参照してください。

証明書を発行するプロセスは、証明書を発行する CA と、それが使用する目的によって異なります。非デジタル形式の ID の発行も、同様の方法で異なります。ライブラリーカードを取得する要件は、ドライバーのライセンスを取得する方法とは異なります。同様に、異なる CA には、さまざまな種類の証明書を発行するためのさまざまな手順があります。証明書を受け取るための要件は、認証された文書の電子メールアドレスまたはユーザー名とパスワード、身元調査、および個人面接のように単純な場合があります。

組織のポリシーに応じて、証明書を発行するプロセスは、ユーザーに対して完全に透過的であるものから、ユーザーの多大な参加と複雑な手順を要求するものまでさまざまです。一般に、証明書を発行するプロセスは柔軟である必要があります。これにより、組織は変化するニーズに合わせて証明書を調整できます。

証明書のライセンスと同様、証明書は、有効である期間を指定します。有効期間の前後に認証に証明書を使用しようとすると失敗します。証明書の有効期限および更新の管理は、証明書管理ストラテジーの重要な部分です。たとえば、管理者は、証明書の有効期限が近づいたときに自動的に通知を受け取り、システムの動作を中断することなく適切な更新プロセスを完了できるようにすることができます。更新プロセスでは、同じ公開鍵のペアを再使用するか、新しい鍵を発行できます。

さらに、従業員が会社を辞めたり、会社内の別の部署で新しい仕事に異動したりした場合など、証明書の有効期限が切れる前に証明書を取り消す必要がある場合があります。

証明書失効は複数の方法で処理できます。

証明書の更新に関する詳細は、「証明書の更新」 を参照してください。CRL や OCSP を含む証明書の取り消しの詳細は、「証明書の取り消しとステータスの確認」 を参照してください

Red Hat Certificate System は、すべてのサブシステムに個別の PKI インスタンスのデプロイメントをサポートします。

または、Certificate System は、共有 PKI インスタンスのデプロイメントをサポートします。

Java アプリケーションサーバーは、サーバーアプリケーションを実行する Java フレームワークです。Certificate System は、Java アプリケーションサーバー内で実行されるように作られています。現在、サポートされている唯一の Java アプリケーションサーバーは Tomcat 8 です。他のアプリケーションサーバーのサポートは今後追加される可能性があります。詳細は、http://tomcat.apache.org/ を参照してください。

Certificate System の各インスタンスは Tomcat サーバーインスタンスです。Tomcat 設定は server.xml に保存されます。Tomcat 設定の詳細は、https://tomcat.apache.org/tomcat-8.0-doc/config/ を参照してください。

各 Certificate System サブシステム (CA や KRA など) は、Tomcat に Web アプリケーションとしてデプロイされます。Web アプリケーション設定は web.xml ファイルに保存され、Java Servlet 3.1 仕様で定義されます。詳細は、https://www.jcp.org/en/jsr/detail?id=340 を参照してください。

Certificate System の設定自体は CS.cfg に保存されます。

これらのファイルの場所は、「インスタンスのレイアウト」 を参照してください。

Java サービスには、アプリケーションを実行するための安全でない操作と安全な操作を定義する Security Manager オプションがあります。サブシステムがインストールされると、Security Manager が自動的に有効になります。つまり、各 Tomcat インスタンスは Security Manager が実行されている状態で起動します。

pkispawn を実行し、独自の Tomcat セクションで pki_security_manager=false オプションを指定するオーバーライド設定ファイルを使用すると、Security Manager が無効になります。

以下の手順に従って、インストールされたインスタンスから Security Manager を無効にすることができます。

インスタンスを起動または再起動すると、pkidaemon によって次のファイルから Java セキュリティーポリシーが構築または再構築されます。

/usr/share/pki/server/conf/catalina.policy
/usr/share/tomcat/conf/catalina.policy
/var/lib/pki/$PKI_INSTANCE_NAME/conf/pki.policy
/var/lib/pki/$PKI_INSTANCE_NAME/conf/custom.policy

その後、/var/lib/pki/instance_name/conf/catalina.policy に保存されます。

Representational state transfer (REST) は、HTTP を使用して Web サービスを定義し、整理する手段で、他のアプリケーションとの相互運用性を単純化します。Red Hat Certificate System は、サーバーのさまざまなサービスにアクセスするための REST インターフェイスを提供します。

Red Hat Certificate System の REST サービスは、RESTEasy フレームワークを使用して実装されます。RESTEasy は実際には Web アプリケーションのサーブレットとして実行されるため、RESTEasy の設定は、対応するサブシステムの web.xml にあります。RESTEasy の詳細は、http://resteasy.jboss.org/ を参照してください。

各 REST サービスは、個別の URL として定義されます。以下に例を示します。

一部のサービスは、プレーンの HTTP 接続を使用してアクセスできますが、セキュリティーに HTTPS 接続が必要になる場合があります。

REST 操作は HTTP メソッドとして指定されます (たとえば、GET、PUT、POST、DELETE)。たとえば、クライアントが GET /ca/rest/users リクエストを送信する CA ユーザーを取得する場合は、次のコマンドを実行します。

REST リクエストおよび応答メッセージは、XML または JSON 形式で送信できます。以下に例を示します。

{
	"id":"admin",
	"UserID":"admin",
	"FullName":"Administrator",
	"Email":"admin@example.com",
	...
}

CLI、Web UI、または汎用 REST クライアントなどのツールを使用して、REST インターフェイスにアクセスできます。Certificate System は、プログラムでサービスにアクセスするための Java、Python、および JavaScript ライブラリーも提供します。

REST インターフェイスは、2 種類の認証方法をサポートします。

各サービスに必要な認証方法は、/usr/share/pki/ca/conf/auth-method.properties で定義されます。

REST インターフェイスでは、サービスへのアクセスに特定のパーミッションが必要になる場合があります。パーミッションは LDAP の ACL リソースで定義されます。REST インターフェイスは、/usr/share/pki/<subsystem>/conf/acl.properties の ACL リソースにマッピングされます。

REST インターフェイスの詳細は、http://www.dogtagpki.org/wiki/REST を参照してください。

Java Security Services (JSS) は、NSS が実行する暗号化操作の Java インターフェイスを提供します。Certificate System アーキテクチャーの JSS 以降は、Java Virtual Machine (JVM) 内からネイティブシステムライブラリーへのアクセスを提供する Java Native Interface (JNI) で構築されます。この設計により、システムの一部として配布される NSS などの FIPS で承認された暗号化プロバイダーを使用できます。JSS は、NSS でサポートされるセキュリティー標準および暗号化技術の多くに対応しています。JSS は、ASN.1 タイプと BER-DER エンコードの純粋な Java インターフェイスも提供します。

Red Hat Certificate System の Java ベースのサブシステムは、Tomcat Server HTTP エンジンと JSS 間のブリッジとして tomcatjss と呼ばれる単一の JAR ファイルを使用します。これは、NSS が実行するセキュリティー操作の Java インターフェイスです。Tomcatjss は、Tomcat の Java Security Services (JSS) を使用した Java Secure Socket Extension (JSSE) 実装です。

Tomcatjss は、TLS を使用して TLS ソケットを作成するために必要なインターフェイスを実装します。tomcatjss が実装するソケットファクトリーは、以下に挙げるさまざまなプロパティーを使用して、ソケットをリッスンして tomcat に戻ります。tomcatjss 自体は、Java JSS システムを利用して、最終的にマシン上のネイティブ NSS 暗号化サービスと通信します。

Tomcat サーバーおよび Certificate System クラスが読み込まれると、tomcatjss が読み込まれます。ロードプロセスの説明を以下に示します。

ソケットが起動時に作成されると、Tomcat は、基礎となる JSS セキュリティーサービスと実際に処理される Certificate System の 最初 のエンティティーになります。最初のリスニングソケットが処理されると、後で使用できるように JSS のインスタンスが作成されます。

server.xml ファイルの詳細は、「Tomcat Engine および Web サービスの設定ファイル」 を参照してください。

Public-Key Cryptography Standard (PKCS) #11 は、暗号化情報を保持するデバイスと通信し、暗号化操作を実行するのに使用する API を指定します。Certificate System は、PKCS #11 に対応しているため、Certificate System は、さまざまなハードウェアおよびソフトウェアデバイスと互換性があります。

Certificate System サブシステムインスタンスで、少なくとも 1 つの PKCS #11 モジュールが利用可能である必要があります。PKCS #11 モジュール (暗号化モジュールまたは暗号化サービスプロバイダーとも呼ばれる) は、暗号化や復号などの暗号化サービスを管理します。PKCS #11 モジュールは、ハードウェアまたはソフトウェアのいずれかで実装できる暗号化デバイスのドライバーに類似しています。Certificate System には、ビルトイン PKCS #11 モジュールが含まれており、サードパーティーモジュールに対応します。

PKCS #11 モジュールには、常に 1 つ以上のスロットがあり、スマートカードなどの物理リーダーの物理ハードウェアスロットとして、またはソフトウェアの概念スロットとして実装できます。PKCS #11 モジュールの各スロットには、トークンを追加できます。このトークンは、暗号化サービスを実際に提供し、必要に応じて証明書と鍵を保存するハードウェアまたはソフトウェアのデバイスです。

Certificate System は、内部 と 外部 の 2 種類のトークンを定義します。内部トークンは、証明書トラストアンカーを保存するために使用されます。外部トークンは、Certificate System サブシステムに属するキーペアと証明書を保存するために使用されます。

セキュリティードメイン は PKI サービスのレジストリーです。CA などのサービスは、これらのドメインに独自の情報を登録するため、PKI サービスのユーザーはレジストリーを確認して他のサービスを検索できます。RHCS のセキュリティードメインサービスは、Certificate System サブシステムの PKI サービスの登録と、共有信頼ポリシーのセットの両方を管理します。

詳細は、「セキュリティードメインの計画」 を参照してください。

デフォルトの設定では、RHCS サブシステムインスタンスはクライアントとして機能し、LDAP 内部データベース (TLS クライアント認証が設定されていない限り、代わりに証明書が認証に使用されます、NSS トークンデータベース、またはパスワードを持つ HSM などの他のサービスに認証する必要があります。管理者は、インストール設定時にこのパスワードを設定するように求められます。このパスワードは、<instance_dir>/conf/password.conf ファイルに書き込まれます。同時に、識別文字列は、パラメーター cms.passwordlist の一部としてメインの設定ファイル CS.cfg に保存されます。

設定ファイル CS.cfg は Red Hat Enterprise Linux により保護され、PKI 管理者のみがアクセスできます。パスワードは CS.cfg に保存されません。

インストール時に、インストーラーは内部ソフトウェアトークンまたはハードウェア暗号化トークンのいずれかを選択してログインします。これらのトークンへのログインパスフレーズは、password.conf にも記述されます。

設定では、後でパスワードを password.conf に配置することもできます。LDAP 公開は、公開ディレクトリーに対して新たに設定された Directory Manager パスワードが password.conf に送信される一例です。

Nuxwdog (watchdog) は、サーバープログラムを起動、停止、監視、および再設定するために使用される軽量な補助デーモンプロセスです。サーバーを起動するためにユーザーにパスワードの入力を求める必要がある場合に最も役立ちます。これは、これらのパスワードをカーネルキーリングに安全にキャッシュし、サーバーがクラッシュした場合に自動的に再起動できるようにするためです。

インストールが完了したら、password.conf ファイルを完全に削除できます。再起動すると、nuxwdog ウォッチドッグプログラムは、cms.passwordlist パラメーター (HSM が使用されている場合は cms.tokenList) を要求対象のパスワードのリストとして使用し、管理者に必要なパスワードの入力を要求します。その後、パスワードは nuxwdog によってカーネルキーリングにキャッシュされ、サーバークラッシュからの自動リカバリーが可能になります。制御されていないシャットダウン (クラッシュ) が原因で、この自動リカバリー (自動サブシステム再起動) が発生します。管理者が制御したシャットダウンの場合は、管理者がパスワードを再度要求します。

ウォッチドッグサービスを使用する場合は、RHCS インスタンスの起動と停止が異なります。詳細は、「Certificate System の Watchdog サービスの使用」 を参照してください。

詳細は、「システムパスワードの管理」 を参照してください。

Red Hat Certificate System は、証明書、要求、ユーザー、ロール、ACL、およびその他のさまざまな内部情報などの情報を格納するための内部データベースとして Red Hat Directory Server (RHDS) を採用しています。Certificate System は、パスワードを使用して内部 LDAP データベースと通信するか、SSL 認証により安全な方法で通信します。

Certificate System インスタンスと Directory Server 間で証明書ベースの認証が必要な場合は、これら 2 つのエンティティー間で信頼を設定する手順を実行することが重要です。このような Certificate System インスタンスをインストールするには、適切な pkispawn オプションも必要です。

詳細は、「Red Hat Directory Server のインストール」 を参照してください。

SELinux は、承認されていないアクセスと改ざんを制限するためにシステム全体で実施される、必須のアクセス制御ルールのコレクションです。SELinux の詳細は、Red Hat Enterprise Linux 8 の SELinux 使用ガイド を参照してください。

基本的に、SELinux はシステム上の オブジェクト を識別します。これは、ファイル、ディレクトリー、ユーザー、プロセス、ソケット、または Linux ホスト上その他のリソースになります。これらのオブジェクトは Linux API オブジェクトに対応します。各オブジェクトは セキュリティーコンテキスト にマッピングされ、オブジェクトのタイプと、Linux サーバーでの機能が可能になります。

オブジェクトはドメインにグループ化でき、各ドメインには適切なルールが割り当てられます。各セキュリティーコンテキストには、実行できる操作、アクセスできるリソース、および所有するアクセス許可に制限を設定するルールがあります。

Certificate System の SELinux ポリシーは、標準のシステムの SELinux ポリシーに組み込まれています。これらの SELinux ポリシーは、Certificate System が使用するすべてのサブシステムとサービスに適用されます。SELinux で Certificate System を実行すると、Certificate System で作成および維持される情報のセキュリティーが強化されます。

図2.1 CA SELinux ポートポリシー

Certificate System SELinux ポリシーは、すべてのサブシステムインスタンスの SELinux 設定を定義します。

Certificate System の場合、各サブシステムは SELinux オブジェクトとして扱われ、各サブシステムには一意のルールが割り当てられます。定義済みの SELinux ポリシーを使用すると、Certificate System オブジェクトが Enforcing モードで SELinux を設定して実行できます。

pkispawn が実行されるたびに、Certificate System サブシステム、そのサブシステムに関連付けられたファイル、およびポートには、必要な SELinux コンテキストのラベルが付けられます。特定のサブシステムが pkidestroy を使用して削除されると、このコンテキストは削除されます。

SELinux ポリシーの中央定義は pki_tomcat_t ドメインです。Certificate System インスタンスは Tomcat サーバーであり、pki_tomcat_t ドメインは標準の tomcat_t Tomcat ドメインのポリシーを拡張します。サーバー上のすべての Certificate System インスタンスが同じドメインを共有します。

各 Certificate System プロセスが開始すると、最初に制限のないドメイン (unconfined_t) で実行され、次に pki_tomcat_t ドメインに移行します。その後、このプロセスには、pki_tomcat_log_t というラベルが付けられたログファイルへの書き込みアクセス、pki_tomcat_etc_rw_t というラベルが付いた設定ファイルへの読み書きアクセス、http_port_t ポートのオープンおよび書き込み機能など、特定のアクセスパーミッションが設定されます。

SELinux モードは、Enforcing から Permissive に変更できますが、これは推奨されません。

Red Hat Certificate System は、起動時またはオンデマンド、あるいはその両方で PKI システムの整合性をチェックできるセルフテストフレームワークを提供します。クリティカルでない自己テストに失敗すると、メッセージはログファイルに保存されますが、重大なセルフテストに失敗すると、メッセージはログファイルに保存されますが、Certificate System サブシステムは適切にシャットダウンします。管理者は、起動時にセルフテストレポートを確認する場合、サブシステムの起動時にセルフテストログを監視する必要があります。起動後にログを表示することもできます。

セルフテストの失敗によりサブシステムがシャットダウンすると、自動的に無効になります。これは、サブシステムが部分的に実行されなくなり、誤解を招く応答を生成するために行われます。問題が解決されると、サーバーで以下のコマンドを実行してサブシステムを再度有効にできます。

# pki-server subsystem-enable <subsystem>

セルフテストの設定方法の詳細は、「セルフテストの設定」 を参照してください。

Certificate System サブシステムは、管理、サーバーがサポートするプロトコルを使用した通信、およびサブシステムで使用されるその他のさまざまなプロセスなどのアクティビティーに関連するイベントを記録するログファイルを作成します。サブシステムインスタンスが実行中に、それが管理するすべてのコンポーネントの情報およびエラーメッセージのログを保持します。また、Apache および Tomcat の Web サーバーはエラーを生成し、ログにアクセスします。

各サブシステムインスタンスは、インストール、監査、およびその他のログに記録された機能に対する独自のログファイルを維持します。

ログプラグインモジュールは、Java™ クラスとして実装され、設定フレームワークに登録されるリスナーです。

監査ログを除くすべてのログファイルとローテーションされたログファイルは、pkispawn によるインスタンスの作成時に、pki_subsystem_log_path に指定されているすべてのディレクトリーに配置されます。

通常の監査ログは他のログタイプとともにログディレクトリーに置かれ、署名された監査ログは /var/log/pki/ instance_name/subsystem_name/signedAudit に書き込まれます。ログのデフォルトの場所を変更するには、設定を変更してください。

インストール中のログ設定の詳細および追加情報は、17章ログの設定 を参照してください。

インストール後のログ管理の詳細は、Red Hat Certificate System 管理ガイド の サブシステムログの設定 セクションを参照してください。

id_number processor - [date:time] [number_of_operations] [result] servlet: message

10439.http-13443-Processor25 - [19/May/{YEAR}:14:16:51 CDT] [11] [3] UGSubsystem: Get User Error User not found

id_number.processor - [date:time] [number_of_operations] [result] servlet: message

11438.http-8443-Processor25 - [27/May/{YEAR}:07:56:18 CDT] [1] [1] archival reqID 4 fromAgent agentID: CA-server.example.com-8443 authenticated by noAuthManager is completed DN requested: UID=recoverykey,E=recoverykey@email.com,CN=recover key serial number: 0x3

[date:time] [processor]: servlet: message

[10/Jun/{YEAR}:05:14:51][main]: Established LDAP connection using basic authentication to host localhost port 389 as cn=Directory Manager

[06/Jun/{YEAR}:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.requestowner$ value=KRA-server.example.com-8443

[06/Jun/{YEAR}:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.profileapprovedby$ value=admin
				[06/Jun/{YEAR}:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.cert_request$ value=MIIBozCCAZ8wggEFAgQqTfoHMIHHgAECpQ4wDDEKMAgGA1UEAxMBeKaBnzANBgkqhkiG9w0BAQEFAAOB...
				[06/Jun/{YEAR}:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.profile$ value=true
				[06/Jun/{YEAR}:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.cert_request_type$ value=crmf
				[06/Jun/{YEAR}:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.requestversion$ value=1.0.0
				[06/Jun/{YEAR}:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.req_locale$ value=en
				[06/Jun/{YEAR}:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.requestowner$ value=KRA-server.example.com-8443
				[06/Jun/{YEAR}:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.dbstatus$ value=NOT_UPDATED
				[06/Jun/{YEAR}:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.subject$ value=uid=jsmith, e=jsmith@example.com
				[06/Jun/{YEAR}:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.requeststatus$ value=begin
				[06/Jun/{YEAR}:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.auth_token.user$ value=uid=KRA-server.example.com-8443,ou=People,dc=example,dc=com
				[06/Jun/{YEAR}:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.req_key$ value=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDreuEsBWq9WuZ2MaBwtNYxvkLP^M
				HcN0cusY7gxLzB+XwQ/VsWEoObGldg6WwJPOcBdvLiKKfC605wFdynbEgKs0fChV^M
				k9HYDhmJ8hX6+PaquiHJSVNhsv5tOshZkCfMBbyxwrKd8yZ5G5I+2gE9PUznxJaM^M
				HTmlOqm4HwFxzy0RRQIDAQAB
				[06/Jun/{YEAR}:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.auth_token.authmgrinstname$ value=raCertAuth
				[06/Jun/{YEAR}:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.auth_token.uid$ value=KRA-server.example.com-8443
				[06/Jun/{YEAR}:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.auth_token.userid$ value=KRA-server.example.com-8443
				[06/Jun/{YEAR}:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.requestor_name$ value=
				[06/Jun/{YEAR}:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.profileid$ value=caUserCert
				[06/Jun/{YEAR}:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.auth_token.userdn$ value=uid=KRA-server.example.com-4747,ou=People,dc=example,dc=com
				[06/Jun/{YEAR}:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.requestid$ value=20
				[06/Jun/{YEAR}:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.auth_token.authtime$ value=1212782378071
				[06/Jun/{YEAR}:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.req_x509info$ value=MIICIKADAgECAgEAMA0GCSqGSIb3DQEBBQUAMEAxHjAcBgNVBAoTFVJlZGJ1ZGNv^M
				bXB1dGVyIERvbWFpbjEeMBwGA1UEAxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4X^M
				DTA4MDYwNjE5NTkzOFoXDTA4MTIwMzE5NTkzOFowOzEhMB8GCSqGSIb3DQEJARYS^M
				anNtaXRoQGV4YW1wbGUuY29tMRYwFAYKCZImiZPyLGQBARMGanNtaXRoMIGfMA0G^M
				CSqGSIb3DQEBAQUAA4GNADCBiQKBgQDreuEsBWq9WuZ2MaBwtNYxvkLPHcN0cusY^M
				7gxLzB+XwQ/VsWEoObGldg6WwJPOcBdvLiKKfC605wFdynbEgKs0fChVk9HYDhmJ^M
				8hX6+PaquiHJSVNhsv5tOshZkCfMBbyxwrKd8yZ5G5I+2gE9PUznxJaMHTmlOqm4^M
				HwFxzy0RRQIDAQABo4HFMIHCMB8GA1UdIwQYMBaAFG8gWeOJIMt+aO8VuQTMzPBU^M
				78k8MEoGCCsGAQUFBwEBBD4wPDA6BggrBgEFBQcwAYYuaHR0cDovL3Rlc3Q0LnJl^M
				ZGJ1ZGNvbXB1dGVyLmxvY2FsOjkwODAvY2Evb2NzcDAOBgNVHQ8BAf8EBAMCBeAw^M
				HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMCQGA1UdEQQdMBuBGSRyZXF1^M
				ZXN0LnJlcXVlc3Rvcl9lbWFpbCQ=

[07/Jul/{YEAR}:06:25:40][http-11180-Processor25]: OCSPServlet: OCSP Request:
				[07/Jul/{YEAR}:06:25:40][http-11180-Processor25]: OCSPServlet:
				MEUwQwIBADA+MDwwOjAJBgUrDgMCGgUABBSEWjCarLE6/BiSiENSsV9kHjqB3QQU

    ==========================================================================
                                INSTALLATION SUMMARY
    ==========================================================================

      Administrator's username:             caadmin
      Administrator's PKCS #12 file:
            /root/.dogtag/pki-tomcat/ca_admin_cert.p12

      Administrator's certificate nickname:
            caadmin
      Administrator's certificate database:
            /root/.dogtag/pki-tomcat/ca/alias

      To check the status of the subsystem:
            systemctl status pki-tomcatd@pki-tomcat.service

      To restart the subsystem:
            systemctl restart pki-tomcatd@pki-tomcat.service

      The URL for the subsystem is:
            https://localhost.localdomain:8443/ca

      PKI instances will be enabled upon system boot

    ==========================================================================

# journalctl -u pki-tomcatd@instance_name.service

# journalctl -u pki-tomcatd-nuxwdog@instance_name.service

# journalctl -f -u pki-tomcatd@instance_name.service

# journalctl -f -u pki-tomcatd-nuxwdog@instance_name.service

各 Certificate System インスタンスは、多数のファイルによって異なります。その一部はインスタンス固有のフォルダーにありますが、他のサーバーインスタンスと共有される共通フォルダーに置かれています。

たとえば、サーバー設定ファイルはインスタンス固有の /etc/pki/ instance_name/server.xml に保存されますが、CA サーブレットは /usr/share/pki/ca/webapps/ca/WEB-INF/web.xml で定義されています。これはシステム上のすべてのサーバーインスタンスで共有されます。

通常、Certificate Manager は Certificate System の中核となります。リクエストから登録 (発行)、更新、失効まで、あらゆる段階で証明書を管理します。

Certificate System は、証明書の登録と発行、および Web ブラウザー、サーバー、仮想プライベートネットワーク (VPN) クライアントなどのさまざまなエンドエンティティーからの証明書要求の処理をサポートします。発行した証明書は X.509 バージョン 3 標準仕様に準拠します。

詳細は、Red Hat Certificate System 管理ガイド の 証明書の登録および更新について セクションを参照してください。

servlet=/ca/ee/ca/profileSubmitCMCSimple?profileId=caECSimpleCMCUserCert

証明書が有効期限に達すると、失効を許可するか、更新することができます。

更新 は、その証明書の既存の鍵ペアを使用して証明書要求を再生成し、要求を Certificate Manager に再送信します。更新された証明書は、同じキーマテリアルを使用して同じプロファイルから作成されているため、元の証明書と同一です。ただし、有効期限は異なり、元の証明書より後になっています。

更新された証明書は古い証明書とまったく同じように機能するため、更新により、証明書の管理とユーザーとサーバー間の関係がはるかにスムーズになります。ユーザー証明書の更新により、暗号化されたデータには失われなくてもアクセスすることができます。

証明書はファイルおよび LDAP ディレクトリー、CRL をファイル、LDAP ディレクトリー、および OCSP レスポンダーに公開できます。公開フレームワークは、3 つのすべての場所に公開するための堅牢なツールセットを提供し、証明書や CRL を公開する場所をより詳細に定義するルールを設定します。

エンドエンティティーは、独自の証明書が取り消されることを要求できます。エンドエンティティーが要求を行うとき、証明書を CA に提示する必要があります。証明書とキーが使用可能な場合、要求は処理されて Certificate Manager に送信され、証明書は取り消されます。Certificate Manager は、証明書をデータベースで取り消されたとマークし、該当する CRL に追加します。

エージェントは、エージェントサービスインターフェイスで証明書を検索し、取り消しにすることにより、Certificate Manager が発行する証明書をすべて取り消すことができます。証明書が取り消されると、証明書が公開用に設定されている場合は、データベースと公開ディレクトリーで取り消されたとマークされます。

内部の OCSP サービスが設定されている場合、サービスは内部データベースで証明書のステータスを判断します。

自動通知は、証明書失効通知メッセージを有効にして設定すると、証明書が取り消された時にエンドエンティティーに電子メールメッセージを送信するように、自動通知を設定することができます。

PKI の間、秘密鍵のアーカイブを使用すると、秘密鍵が失われた場合に暗号化されたデータのリカバリーが可能になります。秘密鍵は、ハードウェア障害、パスワード忘れ、スマートカードの紛失、パスワード所有者の資格喪失など、さまざまな理由で失われる可能性があります。このようなアーカイブおよびリカバリー機能は、RHCS の Key Recovery Authority (KRA) サブシステムによって提供されます。

データの暗号化にのみ使用されるキーのみをアーカイブする必要があります。特に署名キーは決してアーカイブされるべきではありません。署名キーのコピーが 2 つあると、誰がキーを使用したかを確実に特定することができなくなります。2 番目にアーカイブされたコピーを使用して、元のキー所有者のデジタル ID を偽装することができます。

2.4.5.1. キーのアーカイブ

KRA で提供されるキーアーカイブメカニズムには、以下の 2 つのタイプがあります。

• クライアント側のキー生成: このメカニズムを使用すると、クライアントは CRMF 形式で CSR を生成し、登録とキーのアーカイブのために (適切な KRA セットアップを使用して) CA に要求を送信します。Red Hat Certificate System 管理ガイド の CRMFPopClient を使用した CSR の作成 セクションを参照してください。
• サーバー側の鍵生成: このメカニズムでは、適切に装備された証明書登録プロファイルにより、PKI キーが KRA で生成され、任意で新しく発行された証明書とともにアーカイブされます。Red Hat Certificate System 管理ガイド の サーバー側の鍵生成を使用した CSR の生成 セクションを参照してください。

アーカイブが設定されている場合、KRA は秘密鍵を自動的にアーカイブします。

KRA は秘密鍵を安全な鍵リポジトリーに格納します。各キーは暗号化され、キーレコードとして保存され、一意の鍵 ID が付与されます。

鍵のアーカイブコピーは、KRA のストレージキーでラップされます。ストレージ証明書の対応する秘密鍵ペアを使用することによってのみ、復号またはラップ解除が可能になります。1 つ以上のキーリカバリー (または KRA) エージェントの証明書の組み合わせは、KRA で鍵のリカバリーを完了して秘密鍵を取得し、その証明書を使用してアーカイブされた秘密鍵を復号または再作成できるようにします。「コマンドラインでのエージェント承認キーリカバリーの設定」 を参照してください。

KRA インデックスは、キー番号、所有者名、および公開鍵のハッシュ別に保存されるため、非常に効率的な検索を可能にします。キーリカバリーエージェントには、キーレコードの挿入、削除、および検索を行うための特権があります。

• キーリカバリーエージェントがキー ID で検索されると、その ID に対応するキーのみが返されます。
• ユーザー名でエージェントを検索すると、その所有者に属する保存されたすべてのキーが返されます。
• 証明書の公開鍵でエージェントを検索すると、対応する秘密鍵のみが返されます。

Certificate Manager がキーのアーカイブオプションを含む証明書要求を受信すると、自動的に要求を KRA に転送して暗号鍵をアーカイブします。秘密鍵はトランスポートキーで暗号化され、KRA は暗号化されたコピーを受け取り、キーをキーリポジトリーに保存します。キーをアーカイブするには、KRA は以下の 2 つの特別なキーペアを使用します。

• トランスポートキーペアと対応する証明書。
• ストレージキーペア

図2.2「クライアント側のキー生成における鍵アーカイブプロセスの仕組み」 は、サーバー側の鍵の生成時に、最終的にエンティティーが証明書を要求する際に鍵のアーカイブプロセスがどのように発生するかを示しています。

図2.2 クライアント側のキー生成における鍵アーカイブプロセスの仕組み

1. クライアントは CRMF リクエストを生成し、CA の登録ポータルを介して送信します。

   1. クライアントの秘密鍵は CRMF リクエスト内にラップされ、KRA によってだけラップできます。
2. CA は、キーアーカイブオプションを使用した CRMF リクエストであることを検出し、秘密キーアーカイブのためにリクエストを KRA に転送します。
3. KRA は、ユーザーの秘密鍵を復号/ラップ解除し、秘密鍵が公開鍵に対応していることを確認した後、内部 LDAP データベースに保存する前に再度暗号化/ラップします。
4. 秘密鍵が正常に保存されると、KRA は、鍵が正常にアーカイブされたことを確認する CA に応答します。
5. CA は、証明書情報コンテンツの作成と検証のために、登録プロファイルフレームワークにリクエストを送信します。すべてが渡されると、証明書を発行し、応答でエンドエンティティーに送り返します。

2.4.5.2. キーのリカバリー

KRA は、agent-initiated key recovery をサポートします。エージェントが開始するリカバリーとは、指定されたリカバリーエージェントが KRA エージェントサービスポータルのキーリカバリーフォームを使用して、キーリカバリー要求を処理および承認する場合です。特定の数のエージェントを承認すると、システムは、キーの所有者が利用できない、またはキーが失われた場合にキーを回復できます。

キーリカバリーエージェントは、KRA エージェントサービスポータルを介して、秘密暗号化キーと関連する証明書をまとめて承認し、PKCS #12 パッケージに取得して、クライアントにインポートできます。

キーリカバリー許可では、キーリカバリーエージェントの 1 つが、必要なすべてのリカバリーエージェントに、差し迫ったキーリカバリーを通知します。すべてのリカバリーエージェントは、KRA キーリカバリーポータルにアクセスします。エージェントの 1 つが、キーリカバリープロセスを開始します。KRA はエージェントへの通知を返します。これには、エージェントの認証に必要な特定のキーリカバリー要求を指定するリカバリー承認参照番号が含まれます。各エージェントは参照番号を使用し、キーの復元を個別に承認します。

KRA は 非同期リカバリー をサポートします。つまり、リカバリープロセスの各ステップ (最初の要求と後続の承認または承認または拒否) は、キーエントリーの KRA の内部 LDAP データベースに保存されます。元のブラウザーセッションが閉じられたり、KRA がシャットダウンしている場合でも、リカバリープロセスのステータスデータを取得することができます。エージェントは、参照番号を使用せずにキーをリカバリーすることができます。

この非同期リカバリーオプションは、図2.3「非同期リカバリー」 で説明されています。

図2.3 非同期リカバリー

KRA は、認可のステータスキーリカバリープロセスを開始したエージェントに通知します。

すべての承認を入力すると、KRA は情報をチェックします。提示された情報が正しい場合は、要求されたキーを取得し、PKCS #12 パッケージの形式で、キーリカバリープロセスを開始したエージェントに、対応する証明書を返します。

警告

PKCS #12 パッケージには、暗号化された秘密鍵が含まれます。キーの不正使用のリスクを最小限に抑えるには、リカバリーエージェントはセキュアな方法を使用して PKCS #12 パッケージおよびパスワードを鍵受信者に提供する必要があります。このエージェントは、PKCS #12 パッケージを暗号化するために適切なパスワードを使用し、適切な配信メカニズムを設定する必要があります。

キーリカバリーエージェントスキーム は、キーリカバリーエージェントが属するグループを認識するように KRA を設定し、アーカイブされた鍵を復元する前にキーリカバリー要求を承認するために必要なこれらのリカバリーエージェントの数を指定します。

重要

上記の情報は、Firefox などの Web ブラウザーを使用することを指します。ただし、KRA の使用に重要な機能は、ブラウザーの新しいバージョンではなくなりました。このような場合は、pki ユーティリティーを使用してこの動作を複製する必要があります。詳細は、pki(1) および pki-key(1) の man ページを参照するか、CRMFPopClient --help および man CMCRequest を実行してください。

KRA は非対称鍵を保存する他に、ボリューム暗号化シークレット、パスワード、パスフレーズなどの対称鍵やシークレットも格納することができます。pki ユーティリティーは、これらのタイプのシークレットの保存および取得を可能にするオプションをサポートします。

Token Key Service (TKS) は、1 つ以上のマスターキーを管理します。これは マスターキー を保持し、キーマテリアルにアクセスできる TMS 内の唯一のエンティティーです。運用環境では、有効な各スマートカードトークンには、マスターキーと、カード (CUID) に固有の ID の両方から派生した対称鍵のセットが含まれます。

最初に、対称キーのデフォルト (製造元のマスターキーごとにのみ一意) のセットが、製造元によって各スマートカードで初期化されます。このデフォルトのセットは、Key Changeover 操作を実行して TKS で新しいマスターキーを生成することで、デプロイメントサイトで変更する必要があります。マスターキーの唯一の所有者として、スマートカードの CUID が付与されると、TKS はその特定のスマートカードにある対称キーのセットを導出できます。これにより、TKS は、TMS と個々のスマートカード間の安全な通信用にセッションベースの セキュアチャネル を確立できます。

Token Processing System (TPS) は、スマートカード証明書登録の登録認証局です。これは、クライアント側のスマートカードトークンと対話するユーザー中心のエンタープライズセキュリティークライアント (ESC) と、認証局 (CA) やキーリカバリー認証局 (KRA) などの Certificate System バックエンドサブシステムとの間のパイプ役として機能します。

TMS では、スマートカードを管理するために TPS が必要です。これは、TPS が APDU コマンドと応答を理解する唯一の TMS エンティティーであるためです。TPS は、スマートカードにコマンドを送信して、ユーザーやデバイスなどの特定のエンティティーのキーと証明書を生成および保存できるようにします。スマートカード操作は TPS を経由して、証明書を生成するために CA や、鍵を生成、アーカイブ、または復元する KRA などのアクションのために適切なサブシステムに転送されます。

tokendb.allowedTransitions=0:1,0:2,0:3,0:6,3:2,3:6,4:1,4:2,4:3,4:6,6:7

tps.operations.allowedTransitions=0:0,0:4,4:4,4:0,7:0

# Token states
UNFORMATTED         = Unformatted
FORMATTED           = Formatted (uninitialized)
ACTIVE              = Active
SUSPENDED           = Suspended (temporarily lost)
PERM_LOST           = Permanently lost
DAMAGED             = Physically damaged
TEMP_LOST_PERM_LOST = Temporarily lost then permanently lost
TERMINATED          = Terminated

# Token state transitions
FORMATTED.DAMAGED        = This token has been physically damaged.
FORMATTED.PERM_LOST      = This token has been permanently lost.
FORMATTED.SUSPENDED      = This token has been suspended (temporarily lost).
FORMATTED.TERMINATED     = This token has been terminated.
SUSPENDED.ACTIVE         = This suspended (temporarily lost) token has been found.
SUSPENDED.PERM_LOST      = This suspended (temporarily lost) token has become permanently lost.
SUSPENDED.TERMINATED     = This suspended (temporarily lost) token has been terminated.
SUSPENDED.FORMATTED      = This suspended (temporarily lost) token has been found.
ACTIVE.DAMAGED           = This token has been physically damaged.
ACTIVE.PERM_LOST         = This token has been permanently lost.
ACTIVE.SUSPENDED         = This token has been suspended (temporarily lost).
ACTIVE.TERMINATED        = This token has been terminated.
TERMINATED.UNFORMATTED   = Reuse this token.

RE_ENROLL=YES;RENEW=NO;FORCE_FORMAT=NO;PIN_RESET=NO;RESET_PIN_RESET_TO_NO=NO;RENEW_KEEP_OLD_ENC_CERTS=YES

TMS のインストール時に、トークンキーサービスとトークン処理システム間に共有された対称鍵が確立されます。この鍵の目的は、Secure Channel に不可欠であるセッションキーをラップしてアンラップすることです。

Enterprise Security Client は、Web ブラウザーに似た HTTP クライアントアプリケーションであり、TPS と通信し、クライアント側からスマートカードトークンを処理します。ESC と TPS の間で HTTPS 接続が確立されている間、各 TLS セッション内のトークンと TMS の間でも基盤となる Secure Channel が確立されます。

証明書の発行や取り消し時など、特定のイベントが発生すると、通知は指定のメールアドレスに直接送信できます。通知フレームワークには、有効化および設定できるデフォルトのモジュールが同梱されています。

自動ジョブは、定義した間隔で実行されます。

Certificate System と各サブシステムは、システムの監視およびデバッグを可能にするためにシステムイベントを記録する豊富なシステムおよびエラーログを生成します。すべてのログレコードは、迅速に取得するためにローカルファイルシステムに保存されます。ログは設定可能なため、ログは特定タイプのイベントおよび必要なログレベルで作成できます。

Certificate System を使用すると、ログをアーカイブしたり、監査用に配布したりする前に、ログにデジタル署名することができます。この機能により、署名後に改ざんの可能性をログファイルがチェックできるようになります。

Certificate System は、証明書の要求、発行、取り消し、CRL の公開など、すべてのイベントの監査ログを維持します。これらのログは署名されます。これにより、承認されたアクセスやアクティビティーの検出が可能になります。その後、外部監査人は必要に応じてシステムを監査できます。割り当てられた監査ユーザーアカウントは、署名された監査ログを表示できる唯一のアカウントです。このユーザーの証明書は、ログを署名および暗号化するために使用されます。監査ロギングは、ログに記録されるイベントを指定するよう設定されます。

Certificate System は、システムの起動時に自動的に実行されるシステムのセルフテストフレームワークを提供し、オンデマンドで実行できます。設定可能なセルフテストのセットはすでに Certificate System に含まれています。

Certificate System ユーザーはグループ (ロールとも呼ばれる) に割り当てることができます。グループには、どのユーザーが所属するグループにも特権があります。ユーザーには、ユーザーが作成したサブシステムのインスタンスと、ユーザーがメンバーとなるグループの権限のみが付与されます。

認証 は、Certificate System サブシステムが、証明書プロファイルまたはサービスインターフェイスのいずれかに対して認証されているか、クライアントのアイデンティティーを検証するのに使用されます。クライアントが認証を実行するには、単純なユーザー名/パスワード、SSL/TLS クライアント認証、LDAP 認証、NIS 認証、CMC など、さまざまな方法があります。サブシステムへの任意のアクセスに対して認証を実行できます。たとえば、証明書の登録の場合、プロファイルはリクエスターが CA に対して認証する方法を定義します。

クライアントが識別および認証されると、サブシステムは 許可 チェックを実行して、特定のユーザーがサブシステムへのアクセスをどのレベルで許可されているかを判別します。

承認は、個々のユーザーに直接ではなく、グループ、ロール、パーミッションに関連付けられます。Certificate System は、グループを作成し、アクセス制御をそれらのグループに割り当てる認可フレームワークを提供します。既存のグループのデフォルトのアクセス制御は変更可能で、アクセス制御は個々のユーザーおよび IP アドレスに割り当てることができます。システムの主要な部分に対して承認のアクセスポイントが作成され、その位置ごとにアクセス制御ルールを設定できます。

高可用性 のプランニングは、1 つ以上のサブシステムのクローンを利用できることで、予定外の停止やその他の問題を削減します。ホストマシンがダウンすると、複製されたサブシステムは要求を処理してサービスを実行し、マスター (元の) サブシステムからシームレスに引き継ぎ、サービスを中断することなく維持できます。

クローン作成されたサブシステムを使用すると、PKI システムのサービスを中断せずに、修復、トラブルシューティング、またはその他の管理タスクのためにシステムをオフラインにできます。

クローン作成は、証明書要求を処理するなど、異なるマシン上のインスタンスを分離することで、PKI にスケーラビリティーを提供する 1 つの方法です。マスターとそのクローンの内部データベースは相互に複製されるため、1 つのサブシステムの証明書要求またはアーカイブされたキーに関する情報は、他のすべてのサブシステムで利用できます。

通常、マスターおよびクローンインスタンスは異なるマシンにインストールされ、それらのマシンは ロードバランサー の内側に配置されます。ロードバランサーは、Certificate System サブシステムに送信された HTTP および HTTPS 要求を受け入れ、それらのリクエストをマスターインスタンスとクローンインスタンスとの間で適切にダイレクトします。一方のマシンに障害が発生した場合、ロードバランサーは、もう一方のマシンがオンラインに戻るまで、まだ実行中のマシンにすべての要求を透過的にリダイレクトします。

図2.5 クローン作成の例

Certificate System サブシステムの前にあるロードバランサーは、高可用性システムで実際のフェイルオーバーサポートを提供するものです。ロードバランサーは、Certificate System サブシステムの一部として以下の利点があります。

通常、システムのクローンを作成すると、設定サーブレットは内部 LDAP データベース間でレプリカ合意を設定します。ただし、一部のユーザーは、独自のレプリカ合意を確立して管理する場合があります。PKI インスタンスに [Tomcat] セクションを追加し、そのセクションに次の 2 つの name=value ペアを追加することにより、pkispawn 実行ファイルが変更され、これを許可するようになりました。

[Tomcat]
pki_clone_setup_replication=False
pki_clone_reindex_data=False

クローンサブシステムのインストール中に使用できるように、証明書を p12 ファイルにエクスポートする必要があります。このコマンドは、クローンサブシステムをインストールまたは設定するのではなく、インストールの準備をします。pki-server SUBSYSTEM-clone-prepare コマンドを使用してサブシステム証明書をエクスポートする方法の例を次に示します。

pki-server ca-clone-prepare --i topology-02-CA --pkcs12-file /tmp/caclone.p12 --pkcs12-password SECret.123
-----------------------------------------------------
Added certificate "subsystemCert cert-topology-02-CA"
-----------------------------------------------------
--------------------------------------------------------
Added certificate "caSigningCert cert-topology-02-CA CA"
--------------------------------------------------------
----------------------------------------------------------
Added certificate "ocspSigningCert cert-topology-02-CA CA"
----------------------------------------------------------
-----------------------------------------------------------
Added certificate "auditSigningCert cert-topology-02-CA CA"
-----------------------------------------------------------

エクスポートされた p12 ファイルに証明書が含まれていることを確認できます。次の例では、pki pkcs12-cert-find の出力で 4 つの証明書が返されます。

pki pkcs12-cert-find --pkcs12-file /tmp/caclone.p12 --pkcs12-password SECret.123
---------------
4 entries found
---------------
Certificate ID: 4649cef11b90c78d126874b91654de98ded54073
Serial Number: 0x4
Nickname: subsystemCert cert-topology-02-CA
Subject DN: CN=Subsystem Certificate,OU=topology-02-CA,O=topology-02_Foobarmaster.org
Issuer DN: CN=CA Signing Certificate,OU=topology-02-CA,O=topology-02_Foobarmaster.org
Trust Flags: u,u,u
Has Key: true

Certificate ID: a304cf107abd79fbda06d887cd279fb02cefe438
Serial Number: 0x1
Nickname: caSigningCert cert-topology-02-CA CA
Subject DN: CN=CA Signing Certificate,OU=topology-02-CA,O=topology-02_Foobarmaster.org
Issuer DN: CN=CA Signing Certificate,OU=topology-02-CA,O=topology-02_Foobarmaster.org
Trust Flags: CTu,Cu,Cu
Has Key: true

Certificate ID: 4a09e057c1edfee40f412551db1959831abe117d
Serial Number: 0x2
Nickname: ocspSigningCert cert-topology-02-CA CA
Subject DN: CN=CA OCSP Signing Certificate,OU=topology-02-CA,O=topology-02_Foobarmaster.org
Issuer DN: CN=CA Signing Certificate,OU=topology-02-CA,O=topology-02_Foobarmaster.org
Trust Flags: u,u,u
Has Key: true

Certificate ID: 3f42f88026267f90f59631d38805cc60ee4c711a
Serial Number: 0x5
Nickname: auditSigningCert cert-topology-02-CA CA
Subject DN: CN=CA Audit Signing Certificate,OU=topology-02-CA,O=topology-02_Foobarmaster.org
Issuer DN: CN=CA Signing Certificate,OU=topology-02-CA,O=topology-02_Foobarmaster.org
Trust Flags: u,u,Pu
Has Key: true

エクスポートされた p12 ファイルを使用して、クローンサブシステムを設定できるようになりました。

クローン作成されたインスタンスはマスターと全く同じ秘密鍵を持つため、それらの証明書は同じになります。CA の場合、つまり、CA 署名証明書が元のマスター CA およびそのクローン作成された CA と同一であることを意味します。クライアントの観点からは、これは単一の CA に似ています。

クローンとマスターの両方のすべての CA は、証明書を発行し、失効要求を処理できます。

複製された CA を管理する主な問題は、発行する証明書にシリアル番号を割り当てる方法です。複製された CA が異なれば、異なるレートのシリアル番号を使用してトラフィックのレベルが異なる可能性があり、2 つの複製された CA が同じシリアル番号の証明書を発行しないことが不可欠です。これらのシリアル番号範囲は、各 CA の範囲を定義する共有の複製エントリーと、1 つの CA 範囲が少なくなったときに再割り当てする次の使用可能な範囲を使用して、動的に割り当ておよび管理されます。

クローン CA を使用するシリアル番号の範囲は fluid です。すべての複製された CA は、次の利用可能な範囲を定義する共通の設定エントリーを共有します。1 つの CA が利用可能な数未満の実行を開始すると、この設定エントリーをチェックし、次の範囲を要求します。エントリーは自動的に更新されます。これにより、次の CA が新規範囲を取得します。

範囲は begin*Number 属性と end*Number 属性で定義され、要求と証明書のシリアル番号には別々の範囲が定義されます。以下に例を示します。

 dbs.beginRequestNumber=1
 dbs.beginSerialNumber=1
 dbs.enableSerialManagement=true
 dbs.endRequestNumber=9980000
 dbs.endSerialNumber=ffe0000
 dbs.replicaCloneTransferNumber=5

CRL を生成、キャッシュ、公開できるのは 1 つの複製 CA のみになります。これは CRL CA です。複製された他の CA に送信された CRL 要求は、すぐに CRL CA にリダイレクトされます。複製された他の CA は、以前 CRL CA によって生成された CRL を取り消し、表示、インポート、およびダウンロードできますが、新しい CRL を生成すると、同期の問題が発生する可能性があります。CRL 生成を別の複製された CA に移動する方法は、「CA クローンおよびマスターの変換」 を参照してください。

マスター CA は、内部データベースへのレプリケーションの変更を監視することで、クローンされた CA 間の関係と情報共有も管理します。

KRA では、1 つの KRA にアーカイブされるすべての鍵が他の KRA の内部データベースに複製されます。これにより、キーがアーカイブされた KRA に関係なく、クローンの KRA で鍵のリカバリーを開始できます。

鍵のリカバリーが処理されると、リカバリーの記録はクローンされたすべての KRA の内部データベースに保存されます。

同期キーリカバリーではクローンでリカバリープロセスが開始できますが、開始された単一の KRA で完了する必要があります。これは、適切な承認数が KRA エージェントから取得されてからのみ復元操作がレプリケートされたデータベースに記録されるためです。それまでは、リカバリーが開始する KRA だけが、リカバリー操作について知っています。

レプリケートされた TKS には実際の運用上の違いはありません。その 1 つで作成または維持される情報は、その他のサーバーに複製されます。

OCSP の場合、1 つの複製された OCSP のみが CRL 更新を受け取り、公開された CRL はクローンに複製されます。

サブシステムのクローンを作成すると、同じ機能を実行するサーバープロセス 2 つが作成されます。別のサブシステムの新規インスタンスが作成され、同じ鍵と証明書を使用してその操作を実行するように設定されます。マスタークローン用の鍵を保存する場所に応じて、キーにアクセスするための方法が非常に異なります。

鍵と証明書が内部ソフトウェアトークンに保存されている場合は、初回の設定時にマスターサブシステムからエクスポートする必要があります。マスターインスタンスの設定時に、pkispawn 設定ファイルで pki_backup_keys および pki_backup_password パラメーターを指定することにより、システムキーと証明書を PKCS #12 ファイルにバックアップできます。詳細は、pki_default.cfg(5) man ページの BACKUP PARAMETERS セクションを参照してください。

初期設定時に鍵がバックアップされていない場合は、「ソフトウェアデータベースからのサブシステムキーのバックアップ」 に記載されているように、PKCS12Export ユーティリティーを使用して PKCS #12 ファイルに鍵を抽出できます。

次に、PKCS #12 ファイルをクローンサブシステムにコピーし、pki_clone_pkcs12_password および pki_clone_pkcs12_path パラメーターを使用して pkispawn 設定ファイルでその場所とパスワードを定義します。詳細は、pkispawn(8) man ページの Installing a Clone セクションを参照してください。特に、PKCS#12 ファイルが pkiuser ユーザーからアクセスできることを確認し、正しい SELinux ラベルがあることを確認します。

鍵と証明書がハードウェアトークンに保存されている場合は、ハードウェアトークン固有のユーティリティーを使用して鍵と証明書をコピーするか、またはトークンで直接参照する必要があります。

「クローン」 で説明したように、クローン作成の動作の一部は、複製されたサブシステム間で情報を複製することです。これにより、サブシステムは同一のデータセットとレコードから機能します。つまり、レプリケートされたサブシステムの LDAP サーバーが通信できる必要があります。

Directory Server インスタンスが異なるホストにある場合は、Directory Server インスタンスが相互に接続できるように、適切なファイアウォールアクセスがあることを確認してください。

サブシステムは、LDAPS ポートを介した SSL/TLS または LDAP ポートを介した標準接続のいずれかを使用して、内部データベースに接続できます。サブシステムが複製されると、複製インスタンスはそのマスターと同じ接続方法 (SSL/TLS または標準) を使用してデータベースに接続します。ただし、クローン作成では、追加のデータベース接続があります。マスターの Directory Server データベースからクローンの Directory Server データベースへの接続です。この接続には、以下の 3 つの接続オプションがあります。

マスターが使用する接続メソッド (セキュアまたは標準) はクローンで使用し、クローンを設定する前に Directory Server データベースに対して適切に設定する必要があります。

クローン作成は、マスターインスタンスの Directory Server と、クローンインスタンスの Directory Server との間でレプリカ合意を設定することをベースとしています。

レプリケーションとともに関連するサーバーは、同じレプリケーション トポロジー にあります。サブシステムインスタンスのクローンが作成されるたびに、トポロジー全体に追加されます。Directory Server は、レプリカ ID 番号 に基づいてトポロジー内の異なるサーバー間で区別されません。このレプリカ ID は、トポロジー内のすべてのサーバーで一意である必要があります。

要求および証明書に使用されるシリアル番号の範囲 (「CA のクローン作成」) と同様に、すべてのサブシステムには、許可されるレプリカ ID の範囲が割り当てられます。サブシステムのクローン時に、レプリカ ID の 1 つをその範囲から新しいクローンインスタンスに割り当てます。

dbs.beginReplicaNumber=1
dbs.endReplicaNumber=95

インスタンスが現在の範囲を使い果たし始めると、レプリカ ID の範囲を新しい番号で更新できます。

クローンの作成後、クローン間、またはマスターとクローンの間で 設定 の変更は複製されません。インスタンスの設定は、複製されたデータベースの外部にある CS.cfg ファイルにあります。

たとえば、CA にはマスターとクローンの 2 つがあります。設定に関連付けられる新しい KRA が、マスター CA とともにインストールされている。CA-KRA コネクター情報はマスター CA の CS.cfg ファイルに保存されますが、このコネクター情報はクローン CA 設定に追加されません。キーアーカイブを含む証明書要求がマスター CA に送信される場合は、CA-KRA コネクター情報を使用してキーのアーカイブが KRA に転送されます。要求がクローン CA に送信される場合、KRA は認識されず、キーのアーカイブ要求は許可されません。

マスターサーバーまたはクローンサーバーの設定に加えた変更は、他のクローンインスタンスに複製されません。クローンを作成するには、重要な設定を手動で追加する必要があります。

暗号化およびハッシュアルゴリズムは、さまざまな脆弱性とセキュリティー強度に関して絶えず変化しています。原則として、Red Hat Certificate System は NIST ガイドライン に従い、サーバーキーに関連する TLS 1.1 および TLS 1.2 暗号スイートをサポートします。

Transport Layer Security (TLS) プロトコルは、クライアントとサーバー間の認証と暗号化された通信の汎用的な標準です。Red Hat Certificate System は TLS 1.1 および 1.2 をサポートします。

サーバーがサーバーまたはクライアントとして機能している場合、Red Hat Certificate System は以下の暗号スイートをサポートします。

Certificate System PKI の中核は、Certificate Manager (認証局) です。CA は証明書要求を受け取り、すべての証明書を発行します。

図5.1 CA のみの Certificate System

要求および発行のための基本処理はすべて、Certificate Manager が処理でき、これは唯一の必須サブシステムです。組織の要求に応じて、単一または多数の Certificate Manager をさまざまな関係で配置することができます。

証明書の発行に加えて、Certificate Manager は証明書を取り消すこともできます。管理者にとっての 1 つの質問は、証明書が紛失、侵害された場合、または証明書が発行された人や機器が会社をいなくなった場合に、証明書をどのように処理するかです。証明書要求を失効すると、失効日前に証明書を無効化し、失効した証明書のリストがコンパイルされ、発行 CA によって公開され、クライアントが証明書のステータスを検証できるようになります。

CA が実行できない操作の 1 つがキーのアーカイブとリカバリーです。非常に現実的なシナリオとして、ユーザーに秘密鍵を紛失があります。たとえば、鍵がブラウザーデータベースから削除されたり、スマートカードを家に忘れてきたりする可能性があります。多くの一般的なビジネスオペレーションでは、暗号化された電子メールなどの暗号化されたデータが使用され、そのデータのロックを解除するキーを失うと、データ自体が失われます。会社のポリシーによっては、交換用の証明書を再生成または再インポートするためにキーをリカバリーする方法が必要になる可能性があり、どちらの操作にも秘密キーが必要です。

これには、キーを特別にアーカイブおよび取得するサブシステムである KRA が必要です。

図5.2 CA および KRA

キーリカバリー認証局は暗号鍵 (キーアーカイブ) を保存し、CA が証明書 (キーのリカバリー) を再発行できるようにこれらのキーを取得できます。KRA は、通常の証明書に対して実行される場合でも、スマートカードを登録する場合でも、Certificate System によって生成された証明書のキーを格納できます。

キーのアーカイブおよびリカバリーのプロセスは、「キーのアーカイブ、リカバリー、ローテーション」 で詳しく説明されています。

サブシステムを連携させる方法のもう 1 つが負荷分散です。サイトのトラフィックが多い場合は、相互のクローンとして、またはフラット階層 (各 CA が独立している場合) やツリー階層 (一部の CA が他の CA に従属している場合) として、多数の CA を簡単にインストールできます。詳細は、「認証局階層の定義」 を参照してください。

証明書が有効期間内にありますが無効にする必要がある場合は、取り消すことができます。Certificate Manager は、取り消された証明書のリストを公開することができます。これにより、クライアントが証明書が有効であることを確認する必要がある場合は、リストを確認できます。これらの要求は、オンライン証明書ステータスプロトコル要求 で、特定の要求と応答の形式を持ちます。Certificate Manager には、OCSP レスポンダーが組み込まれており、OCSP 要求を自分で検証できます。

ただし、証明書要求トラフィックと同様に、サイトには、証明書のステータスを確認するためのクライアントの要求が多数ある可能性があります。Example Corp. には大規模な Web ストアがあり、各顧客のブラウザーは SSL/TLS 証明書の有効性を検証しようとします。ここでも、CA は証明書の発行数を処理することができますが、要求トラフィックが高いとパフォーマンスに影響します。この場合、Example Corp. は外部の OCSP Manager サブシステムを使用して証明書のステータスを確認し、Certificate Manager は更新された CRL を頻繁に公開するだけで済みます。

図5.3 CA および OCSP

スマートカードは、キーと証明書のデータを格納するために物理的な媒体を使用するため、通常、直接の登録と承認のプロセスが必要です。つまり、複数のエージェントが TPS にアクセスでき、多くの場合は、異なるオフィスまたは地理的な場所にある複数の TPS サブシステムが必要になります。

トークン管理システムは非常にスケーラブルです。複数の TPS は、単一の CA、TKS、または KRA インスタンスと連携するように設定できますが、複数の Enterprise Security Clients は 1 つの TPS と通信できます。追加のクライアントがインストールされると、TPS を再設定せずに TPS インスタンスを参照できます。同様に、TPS が追加されるため、これらのサブシステムを再設定せずに、同じ CA、TKS、および KRA インスタンスを参照することができます。

インストール後に、TPS 設定を編集して、フェイルオーバーのサポートに追加の CA インスタンス、KRA インスタンス、および TKS インスタンスを使用できます。そのため、プライマリーサブシステムが利用できない場合、TPS はトークンサービスを中断せずに次に利用可能なシステムに切り替えます。

Certificate System CA をサードパーティー公開 CA にチェーンすると、公開 CA が、下位 CA が発行できる証明書の種類と証明書チェーンの性質に課す制限が導入されます。たとえば、サードパーティー CA にチェーンする CA は、SSL/TLS サーバー証明書ではなく、S/MIME (Secure Multipurpose Internet Mail Extensions) および SSL/TLS クライアント認証証明書のみの発行に制限される可能性があります。パブリック CA を使用する方法は他にもあります。これは一部の PKI デプロイメントに許可されないことがあります。

パブリック CA にチェーンする利点の 1 つは、サードパーティーがルート CA 証明書を Web ブラウザーまたは他のクライアントソフトウェアに送信することです。これは、管理者が制御できないブラウザーを使用してさまざまな企業がアクセスする証明書を持つエクストラネットにとって大きな利点になる可能性があります。CA 階層にルート CA を作成するということは、ローカル組織が、Certificate System によって発行された証明書を使用するすべてのブラウザーにルート証明書を取得する必要があることを意味します。イントラネット内でこれを行うためのツールはありますが、エクストラネットでは実現が難しい場合があります。

Certificate System CA は ルート CA として機能するため、サーバーは独自の CA 署名証明書、およびその他の CA 署名証明書に署名し、組織固有の CA 階層を作成します。このサーバーは、下位 A として設定することもできます。つまり、サーバーの CA 署名鍵が既存の CA 階層にある別の CA により署名されます。

Certificate System CA をルート CA として設定すると、発行した CA 署名証明書の内容を制御するポリシーを設定し、Certificate System 管理者がすべての下位 CA を制御することができます。下位 CA は、ルート CA の設定とは対照的に、独自の認証および証明書プロファイル設定を評価することで証明書を発行します。

Certificate System の Certificate Manager は、リンクされた CA として機能し、検証用のサードパーティーまたはパブリック CA までチェーンできます。これにより、会社の証明書階層外で証明書チェーンを検証できます。Certificate Manager は、サードパーティーの CA から Certificate Manager の CA 署名証明書 を要求して、サードパーティーの CA にチェーンされます。

これに関連し、Certificate Manager は、クロスペア または クロス署名の証明書 を発行することもできます。これら 2 つの CA 間でクロス署名証明書を発行および格納することにより、2 つの異なる CA 間で信頼される関係を作成できます。クロス署名付き証明書ペアを使用すると、組織の PKI 以外で発行された証明書は、システム内で信頼できます。

これらは、連邦ブリッジ認証局 (FBCA) の定義に関連して、ブリッジ証明書 とも呼ばれます。

ルート CA と従属 CA の階層を作成する代わりに、Certificate Manager の複数のクローンを作成し、シリアル番号の範囲内で証明書を発行するように各クローンを設定することができます。

クローン として作成された Certificate Manager は、同じ CA 署名鍵と、別の Certificate Manager (マスター Certificate Manager) を使用します。

クローン CA と元の CA は、同じ CA 署名鍵と証明書を使用して、発行する証明書に署名するため、すべての証明書の 発行者名 は同じです。クローン CA と元の Certificate Manager は、単一の CA であるかのように証明書を発行します。高可用性フェイルオーバーのサポートのために、これらのサーバーは異なるホストに置くことができます。

クローン作成の利点は、Certificate Manager の負荷を複数のプロセスまたは複数の物理マシンに分散することです。登録需要の高い CA の場合は、クローン作成から得られる配布により、指定された時間間隔でより多くの証明書に署名して発行できます。

クローン作成された Certificate Manager には、エージェントやエンドエンティティーゲートウェイ機能など、通常の Certificate Manager と同じ機能があります。

クローンが発行する証明書のシリアル番号は、動的に分散されます。各クローンとマスターのデータベースが複製されるため、すべての証明書要求と発行された証明書の両方も複製されます。これにより、シリアル番号の競合が発生せず、クローンされた Certificate Manager にシリアル番号の範囲を手動で割り当てる必要がなくなります。

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 デプロイメントの拡張、ポリシー、およびその他の側面に与える影響を検討します。

Certificate System サブシステムでファイアウォールを使用する方法は 2 つあります。

CA、KRA、および TKS には、セキュリティーが侵害された場合に壊滅的なセキュリティー結果を引き起こす可能性のある重要な情報が含まれているため、常にファイアウォールの内側に置かれます。

TPS および OCSP は、ファイアウォールの外に置くことができます。同様に、Certificate System で使用される他のサービスやクライアントは、ファイアウォールの外側にある別のマシンに置くことができます。この場合、ファイアウォールの背後にあるサブシステムとファイアウォールの外側にあるサービスとの間のアクセスを許可するようにローカルネットワークを設定する必要があります。

LDAP データベースは、それを使用するサブシステムとは異なるネットワーク上であっても、異なるサーバー上に配置できます。この場合、ディレクトリーサービスへのトラフィックを許可するために、すべての LDAP ポート (デフォルトでは LDAP の場合は 389、LDAPS の場合は 636) を開く必要があります。LDAP データベースにアクセスしないと、すべてのサブシステム操作が失敗します。

ファイアウォールの設定の一環として、iptables が有効になっている場合は、適切な Certificate System ポートを介した通信を許可するようにポリシーを設定する必要があります。iptables の設定は、firewalld の使用および設定ガイド を参照してください。

それらが保持する機密データのため、CA、KRA、および TKS を適切な物理的アクセス制限のある安全な施設に保管することを検討してください。システムへのネットワークアクセスを制限する必要があるのと同様に、物理アクセスも制限する必要があります。

安全な場所を見つけることに加えて、サブシステムのエージェントと管理者への近さを考慮してください。たとえば、キーリカバリーには、複数のエージェントの承認が必要となる場合があります。これらのエージェントが広い地域に分散している場合は、時間差がキーの取得能力に悪影響を及ぼす可能性がある。サブシステムの物理的な場所を計画し、次にサブシステムを管理するエージェントと管理者の場所に従って計画します。

各 Certificate System サーバーは、最大 4 つのポートを使用します。

Red Hat Certificate System 管理ガイド の Red Hat Certificate System ユーザーインターフェイス の章で説明されているすべてのサービスページとインターフェイスは、インスタンスの URL と対応するポート番号を使用して接続されます。以下に例を示します。

https://server.example.com:8443/ca/ee/ca

管理コンソールにアクセスするには、URL は管理ポートを指定します。

pkiconsole https://server.example.com:8443/ca

すべてのエージェントおよび管理機能に、SSL/TLS クライアント認証が必要です。エンドエンティティーからの要求の場合、Certificate System は SSL/TLS (暗号化) ポートと非 SSL/TLS ポートの両方でリッスンします。

ポートは server.xml ファイルで定義します。ポートを使用しない場合は、そのファイルで無効にできます。以下に例を示します。

<Service name="Catalina">
    <!--Connector port="8080" ... /-->  unused standard port
    <Connector port="8443" ... />

新しいインスタンスをインストールするときは常に、新しいポートがホストシステム上で一意であることを確認してください。

ポートが使用できることを確認するには、オペレーティングシステムに適切なファイルを確認します。ネットワークアクセス可能なサービスのポート番号は通常、services という名前のファイルで維持されます。Red Hat Enterprise Linux では、現在 SELinux コンテキストを持っているすべてのポートを一覧表示する semanage port -l コマンドを実行して、ポートが SELinux によって割り当てられていないことを確認することも役立ちます。

新しいサブシステムインスタンスが作成されると、1〜65535 の任意の番号をセキュアポート番号として指定できます。

SELinux (Security-Enhanced Linux) は、Linux カーネルに必須のアクセス制御メカニズムを実装しておりで、標準の任意アクセス制御がチェックされた後、許可された操作をチェックします。SELinux は、定義されたポリシーに基づいて、Linux システム内のファイルとプロセス、およびそれらのアクションにルールを適用できます。

ほとんどの場合、enforcing モードで SELinux を使用して Certificate System を実行するために必要なアクションはありません。ハードウェアセキュリティーモジュール (HSM) を使用する場合など、Certificate System のドキュメントの手順で SELinux 関連の設定を手動で行う必要がある場合は、対応するセクションに記載されています。

デフォルトでは、Red Hat Enterprise Linux をインストールした後、SELinux が有効になり、enforcing モードで実行します。それ以上のアクションは必要ありません。

SELinux の詳細は、SELinux 使用ガイド を参照してください。

以下の表は、Certificate System サブシステムで使用されるデフォルトのポートを示しています。

pkispawn ユーティリティーを使用して Certificate System を設定すると、ポート番号をカスタマイズできます。上記のデフォルトとは異なるポートを使用する場合は、ファイアウォールで必要なポートを開くの説明に従ってファイアウォールで対応して開きます。ポートの詳細は、「ポートの計画」 を参照してください。

Directory Server にアクセスするために必要なポートは、Directory Server インストールガイド の該当するセクションを参照してください。

特定のデプロイメントでは、FIPS モードを使用するように HSM を設定する必要があります。HSM で FIPS モードを有効にするには、特定の手順は、HSM ベンダーのドキュメントを参照してください。

このセクションでは、特定の HSM に対して FIPS モードが有効になっているかどうかを確認する方法を説明します。その他の HSM は、ハードウェアの製造元のドキュメントを参照してください。

# /opt/nfast/bin/nfkminfo

特定の HSM では、Certificate System をインストールする前に、手動で SELinux 設定を更新する必要があります。

以下のセクションでは、対応している HSM に必要なアクションを説明します。

対応している HSM の詳細は、「サポート対象のハードウェアセキュリティーモジュール」 を参照してください。

「pkispawn ユーティリティーを使用して RHCS をインストールする」 では、HSM を使用して Certificate System をインストールする場合は、pkispawn ユーティリティーに渡す設定ファイルで以下のパラメーターを使用します。

...
[DEFAULT]
##########################
# Provide HSM parameters #
##########################
pki_hsm_enable=True
pki_hsm_libfile=hsm_libfile
pki_hsm_modulename=hsm_modulename
pki_token_name=hsm_token_name
pki_token_password=pki_token_password

########################################
# Provide PKI-specific HSM token names #
########################################
pki_audit_signing_token=hsm_token_name
pki_ssl_server_token=hsm_token_name
pki_subsystem_token=hsm_token_name
...

以下のセクションでは、各 HSM の設定を説明します。HSM がリストにない場合は、HSM の製造元のドキュメントを参照してください。

pki_hsm_libfile=/opt/nfast/toolkits/pkcs11/libcknfast.so
pki_hsm_modulename=nfast

[root@example911 ~]# /opt/nfast/bin/nfkminfo
World
 generation  2

...snip...

Cardset
 name          "NHSM6000-OCS"
 k-out-of-n    1/4
 flags         NotPersistent PINRecoveryRequired(enabled) !RemoteEnabled
 timeout       none

...snip...

pki_token_name=NHSM6000-OCS

pki_hsm_libfile=/usr/safenet/lunaclient/lib/libCryptoki2_64.so
pki_hsm_modulename=lunasa

# /usr/safenet/lunaclient/bin/vtl verify

The following Luna SA Slots/Partitions were found:

Slot    Serial #            Label
===    ===============    =====
   0       1209461834772     lunasaQE

pki_token_name=lunasaQE

現在の FQDN を確認するには、次のコマンドを実行します。

# hostname
pki.example.com

ホスト名が予想と異なる場合は、hostnamectl を実行してホスト名を設定します。以下に例を示します。

Red Hat Directory Server パッケージをインストールするには、次の手順を実行します。

注記: DS インスタンスをインストールする前に、次の手順が実行されていることを確認してください。

PKI サーバー用のローカル DS インスタンスを準備するには、次のプロセスに従います。

注記: DS のインストールにより、SSL 接続用のブートストラップサーバー証明書を発行するブートストラップ自己署名付き証明書が自動的に生成されます。PKI インストールでは、これにより提供されるセキュリティーを利用してインストールを完了します。ブートストラップサーバー証明書は、インストール後の手順として実際の CA により発行されたサーバー証明書に置き換えることができます。

ブートストラップ証明書の生成と SSL 接続を無効にする場合は、以下の sed コマンドで self_sign_cert = False を設定します。ブートストラップ証明書を使用して DS で SSL 接続を有効にする の手順に従って、後から SSL を有効にすることもできます。

$ dscreate create-template ds.inf

$ sed -i \
    -e "s/;instance_name = ./instance_name = localhost/g" \ -e "s/;root_password = ./root_password = Secret.123/g" \
    -e "s/;suffix = ./suffix = dc=example,dc=com/g" \ -e "s/;create_suffix_entry = ./create_suffix_entry = True/g" \
    -e "s/;self_sign_cert = .*/self_sign_cert = True/g" \
    ds.inf

$ dscreate from-file ds.inf

$ ldapadd -H ldap://$HOSTNAME -x -D "cn=Directory Manager" -w Secret.123 << EOF
dn: dc=pki,dc=example,dc=com
objectClass: domain
dc: pki
EOF

dc=example,dc=com
+ dc=pki
  + dc=ca
  + dc=kra
  + dc=ocsp
  + dc=tks
  + dc=tps
  + dc=acme
  + dc=est

$ dsctl localhost remove --do-it

Certificate System をインストールおよび更新する前に、対応するリポジトリーを有効にする必要があります。

必要なパッケージのインストールについては、7章Red Hat Certificate System のインストールと設定 に記載されています。

Certificate System パッケージおよびオペレーティングシステムパッケージを更新するには、以下の手順に従います。

インストールせずに更新をダウンロードするには、上記の手順で --downloadonly オプションを使用します。

yum update --downloadonly

ダウンロードしたパッケージは /var/cache/yum/ ディレクトリーに保存されます。最新バージョンであれば、yum update は後でパッケージを使用します。

Red Hat Certificate System の製品バージョンは、/usr/share/pki/CS`SERVER_VERSION ファイルに保存されます。バージョンを表示するには、以下を実行します。

# cat /usr/share/pki/CS_SERVER_VERSION
Red Hat Certificate System {Version} (Batch Update 1)

実行中のサーバーの製品バージョンを検索するには、ブラウザーから以下の URL にアクセスします。

pkispawn ユーティリティーには設定ファイルが必要です。このファイルには、セクションにグループ化されたパラメーターが含まれています。これらのセクションは積み重ねられているため、前のセクションで定義されたパラメーターを後のセクションで定義されたパラメーターでオーバーライドできます。セクションは次の順序で読まれます。

実行すると、pkispawn は以下を行います。

/root/pki/config.subsystem.txt などの pkispawn 設定用のテキストファイルを作成し、以下で説明する設定を入力します。対応する [ ] セクションの下にすべての設定を追加する必要があります。適切な配置を確認するには、/usr/share/pki/server/etc/default.cfg ファイルを参照してください。

このセクションで説明するパラメーターは、pki_default.cfg(5) の man ページを参照してください。

インストールするサブシステムとは関係なく、設定ファイルの [DEFAULT] セクションで次の設定を指定できます。

pkispawn は、シングルステップインストール または ツーステップインストール のいずれかで実行できます。

# pkispawn -s [CA, OCSP, KRA, TKS, TPS, ACME, EST] -f cs_inst.cfg –debug

# pkispawn -s CA -f rootca_inst.cfg --precheck --debug
# pkispawn -s CA -f rootca_inst.cfg --debug

# pkispawn -s CA -f rootca_inst.cfg --skip-installation --precheck --debug
# pkispawn -s CA -f rootca_inst.cfg --skip-installation --debug

シングルステップ方式を使用して RootCA インスタンスを設定するには、設定ファイルを作成し、pkispawn ツールを 1 回実行する必要があります。

この例では、RootCA は rhcs10.example.com (および他のインスタンス) にインストールされ、その内部ディレクトリーサーバーは rhds11.example.com にあります。

ツーステップ方式を使用して RootCA インスタンスを設定するには、設定ファイルを作成し、pkispawn ツールを 2 回実行する必要があります。

この例では、RootCA は rhcs10.example.com にインストールされます。