14.3. CA、OCSP、KRA、または TKS のユーザーおよびグループの管理


ユーザーが実行できる操作の多くは、ユーザーが属するグループによって決定されます。たとえば、CA のエージェントは証明書とプロファイルを管理し、管理者は CA サーバーの設定を管理します。
4 つのサブシステム (CA、OCSP、KRA、および TKS) Java 管理コンソールを使用してグループとユーザーを管理します。TPS には Web ベースの管理サービスがあり、ユーザーおよびグループは Web サービスページで設定されます。

14.3.1. グループの管理

14.3.1.1. 新規グループの作成

  1. 管理コンソールにログインします。
    pkiconsole https://server.example.com:8443/subsystem_type
  2. 左側のナビゲーションメニューから Users and Groups を選択します。
  3. Groups タブを選択します。
  4. Edit をクリックして、グループ情報を入力します。
    内部データベースにすでに存在するユーザーのみを追加することが可能です。
  5. ACL を編集して、グループの権限を付与します。詳細は、「ACL の編集」 を参照してください。グループの ACL に ACI が追加されていない場合、グループには Certificate System の一部にアクセスパーミッションがありません。

14.3.1.2. グループのメンバーの変更

すべてのグループからメンバーを追加または削除できます。管理者のグループには、最低でもユーザーエントリーが 1 つ必要です。
  1. 管理コンソールにログインします。
  2. 左側のナビゲーションツリーから Users and Groups を選択します。
  3. Groups タブをクリックします。
  4. 名前の一覧からグループを選択し、Edit をクリックします。
  5. 適切な変更を加えます。
    • グループの説明を変更するには、Group description フィールドに新しい説明を入力します。
    • グループからユーザーを削除するには、ユーザーを選択し、Delete をクリックします。
    • ユーザーを追加するには、Add User をクリックします。ダイアログボックスから追加するユーザーを選択し、OK をクリックします。

14.3.2. ユーザーの管理 (管理者、エージェント、および監査者)

各サブシステムのユーザーは別々に維持されます。あるサブシステムの管理者であるからといって、その人が別のサブシステムに対する権限 (またはユーザーエントリー) を持っているとは限りません。ユーザーを設定して、ユーザー証明書を使用してサブシステムのエージェント、管理者、または監査担当者として信頼できます。

14.3.2.1. ユーザーの作成

Certificate System をインストールしたら、セットアップ時に作成したユーザーのみが存在します。本セクションでは、追加のユーザーを作成する方法を説明します。
注記
セキュリティー上の理由から、Certificate System ユーザーに個別のアカウントを作成します。
14.3.2.1.1. コマンドラインでのユーザーの作成
コマンドラインでユーザーを作成するには、以下を実行します。
  1. ユーザーアカウントを追加します。たとえば、example ユーザーを CA に追加するには、以下を実行します。
    # pki -d ~/.dogtag/pki-instance_name/ca/alias/ -c password -n caadmin \
         ca-user-add example --fullName "Example User"
    ---------------------
    Added user "example"
    ---------------------
      User ID: example
      Full name: Example User
    このコマンドは、caadmin ユーザーを使用して新規アカウントを追加します。
  2. 必要に応じて、グループにユーザーを追加します。たとえば、example ユーザーを Certificate Manager Agents グループに追加するには、次のコマンドを実行します。
    # pki -d ~/.dogtag/pki-instance_name/ -p password -n "caadmin" \
         user-add-membership example Certificate Manager Agents
  3. 証明書要求を作成します。
    • Certificate System 環境に Key Recovery Authority (KRA) が存在する場合は、以下を行います。
      # CRMFPopClient -d ~/.dogtag/pki-instance_name/ -p password \
           -n "user_name" -q POP_SUCCESS -b kra.transport -w "AES/CBC/PKCS5Padding" \
           -v -o ~/user_name.req
      このコマンドは、証明書署名要求 (CSR) を ~/user_name.req ファイルに CRMF 形式を保存します。
    • 証明書システム環境に Key Recovery Authority (KRA) が存在しない場合は、以下を行います。
      • NSS データベースディレクトリーを作成します。
        # export pkiinstance=ca1
        # echo ${pkiinstance}
        # export agentdir=~/.dogtag/${pkiinstance}/agent1.dir
        # echo ${agentdir}
        # pki -d ${agentdir}/ -C ${somepwdfile} client-init
      • CSR を -o オプションで指定された PKCS-#10 フォーマットファイルに保存し、初期化された NSS データベースディレクトリーへのパスの場合は -d、パスワードファイルの場合は -P オプション、パスワードの場合は -p、サブジェクト DN の場合は -n を保存します。
        # PKCS10Client -d ${agentdir}/ -P ${somepwdfile} -n "cn=agent1,uid=agent1" -o ${agentdir}/agent1.csr
        PKCS10Client: Certificate request written into /.dogtag/ca1/agent1.dir/agent1.csr
        PKCS10Client: PKCS#10 request key id written into /.dogtag/ca1/agent1.dir/agent1.csr.keyId
        
  4. 登録リクエストを作成します。
    1. ~/cmc.role_crmf.cfg ファイルを以下の内容で作成します。
      #numRequests: Total number of PKCS10 requests or CRMF requests.
      numRequests=1
      
      #input: full path for the PKCS10 request or CRMF request,
      #the content must be in Base-64 encoded format
      #Multiple files are supported. They must be separated by space.
      input=~/user_name.req
      
      #output: full path for the CMC request in binary format
      output=~/cmc.role_crmf.req
      
      #tokenname: name of token where agent signing cert can be found (default is internal)
      tokenname=internal
      
      #nickname: nickname for agent certificate which will be used
      #to sign the CMC full request.
      nickname=PKI Administrator for Example.com
      
      #dbdir: directory for cert8.db, key3.db and secmod.db
      dbdir=~/.dogtag/pki-instance_name/
      
      #password: password for cert8.db which stores the agent
      #certificate
      password=password
      
      #format: request format, either pkcs10 or crmf
      format=crmf
      直前の手順で使用した環境および CSR 形式に基づいて、パラメーターを設定します。
    2. 以前に作成した設定ファイルを CMCRequest ユーティリティーに渡して、CMC 要求を作成します。
      # CMCRequest ~/cmc.role_crmf.cfg
  5. CMS (CMC) 要求で Certificate Management を送信します。
    1. ~/HttpClient_role_crmf.cfg ファイルを以下の内容で作成します。
      # #host: host name for the http server
      host=server.example.com
      
      #port: port number
      port=8443
      
      #secure: true for secure connection, false for nonsecure connection
      secure=true
      
      #input: full path for the enrollment request, the content must be in binary format
      input=~/cmc.role_crmf.req
      
      #output: full path for the response in binary format
      output=~/cmc.role_crmf.resp
      
      #tokenname: name of token where SSL client authentication cert can be found (default is internal)
      #This parameter will be ignored if secure=false
      tokenname=internal
      
      #dbdir: directory for cert8.db, key3.db and secmod.db
      #This parameter will be ignored if secure=false
      dbdir=~/.dogtag/pki-instance_name/
      
      #clientmode: true for client authentication, false for no client authentication
      #This parameter will be ignored if secure=false
      clientmode=true
      
      #password: password for cert8.db
      #This parameter will be ignored if secure=false and clientauth=false
      password=password
      
      #nickname: nickname for client certificate
      #This parameter will be ignored if clientmode=false
      nickname=PKI Administrator for Example.com
      
      #servlet: servlet name
      servlet=/ca/ee/ca/profileSubmitCMCFull
      
      環境に応じてパラメーターを設定します。
    2. CA に要求を送信します。
      # HttpClient ~/HttpClient_role_crmf.cfg
      Total number of bytes read = 3776
      after SSLSocket created, thread token is Internal Key Storage Token
      client cert is not null
      handshake happened
      writing to socket
      Total number of bytes read = 2523
      MIIJ1wYJKoZIhvcNAQcCoIIJyDCCCcQCAQMxDzANBglghkgBZQMEAgEFADAxBggr
      ...
      The response in data format is stored in ~/cmc.role_crmf.resp
    3. 結果を確認します。
      # CMCResponse ~/cmc.role_crmf.resp
      Certificates:
          Certificate:
              Data:
                  Version:  v3
                  Serial Number: 0xE
                  Signature Algorithm: SHA256withRSA - 1.2.840.113549.1.1.11
                  Issuer: CN=CA Signing Certificate,OU=pki-instance_name Security Domain
                  Validity:
                      Not Before: Friday, July 21, 2017 12:06:50 PM PDT America/Los_Angeles
                      Not  After: Wednesday, January 17, 2018 12:06:50 PM PST America/Los_Angeles
                  Subject: CN=user_name
      ...
      Number of controls is 1
      Control #0: CMCStatusInfoV2
         OID: {1 3 6 1 5 5 7 7 25}
         BodyList: 1
         Status: SUCCESS
  6. 必要に応じて、証明書をユーザー自身の ~/.dogtag/pki-instance_name/ データベースにインポートするには、次のコマンドを実行します。
    # certutil -d ~/.dogtag/pki-instance_name/ -A -t "u,u,u" -n "user_name certificate" -i ~/cmc.role_crmf.resp
  7. ユーザーレコードに証明書を追加します。
    1. ユーザーのシリアル番号を検出できる証明書を一覧表示します。たとえば、証明書のサブジェクトに example ユーザー名が含まれる証明書を一覧表示するには、次のコマンドを実行します。
      pki -d ~/.dogtag/pki-instance_name/ -c password -n caadmin ca-user-cert-find example
      -----------------
      1 entries matched
      -----------------
        Cert ID: 2;6;CN=CA Signing Certificate,O=EXAMPLE;CN=PKI Administrator,E=example@example.com,O=EXAMPLE
        Version: 2
        Serial Number: 0x6
        Issuer: CN=CA Signing Certificate,O=EXAMPLE
        Subject: CN=PKI Administrator,E=example@example.com,O=EXAMPLE
      ----------------------------
      Number of entries returned 1
      次の手順では、証明書のシリアル番号が必要です。
    2. シリアル番号を使用して、証明書リポジトリーから Certificate System データベースのユーザーアカウントに証明書を追加します。たとえば、CA ユーザーの場合は以下を実行します。
      pki -c password -n caadmin ca-user-cert-add example --serial 0x6
14.3.2.1.2. コンソールを使用したユーザーの作成
PKI コンソールを使用してユーザーを作成するには、次のコマンドを実行します。
  1. 管理コンソールにログインします。
    pkiconsole https://server.example.com:8443/subsystem_type
  2. Configuration タブで、Users and Groups を選択します。Add をクリックします。
  3. Edit User Information ダイアログに情報を入力します。
    情報のほとんどは、ユーザー名、メールアドレス、パスワードなどの標準のユーザー情報です。このウィンドウには、User State と呼ばれるフィールドも含まれ、このフィールドには、ユーザーに関する追加情報を追加するのに使用される文字列を含めることができます。ほとんどの場合、このフィールドは、アクティブユーザーであるかどうかを確認できます。
  4. ユーザーが属するグループを選択します。ユーザーのグループメンバーシップは、ユーザーが持つ特権を決定します。エージェント、管理者、および監査人を適切なサブシステムグループに割り当てます。
  5. ユーザーの証明書を保存します。
    1. CA エンドエンティティーサービスページでユーザー証明書を要求します。
    2. ユーザープロファイルに対して自動登録が設定されていない場合は、証明書要求を承認します。
    3. 通知メールで提供される URL を使用して証明書を取得し、base-64 でエンコードされた証明書をローカルファイルまたはクリップボードにコピーします。
    4. 新しいユーザーエントリーを選択し、Certificates をクリックします。
    5. Import をクリックし、Base-64 でエンコードされた証明書に貼り付けます。

14.3.2.2. 証明書システムユーザー証明書の変更

  1. 管理コンソールにログインします。
  2. Users and Groups を選択します。
  3. ユーザー ID の一覧から編集するユーザーを選択し、Certificates をクリックします。
  4. Import をクリックして、新しい証明書を追加します。
  5. Import Certificate ウィンドウで、テキストエリアに新しい証明書を貼り付けます。-----BEGIN CERTIFICATE----- および -----END CERTIFICATE----- マーカー行を含めます。

14.3.2.3. 管理者、エージェント、および監査ユーザー証明書の更新

証明書を更新する方法は 2 つあります。証明書を 再生成 すると、元の鍵と元のプロファイルと要求を取得し、新しい有効期間と有効期限で同一の鍵を再作成します。証明書のキーを再入力 すると、最初の証明書要求が元のプロファイルに再送信されますが、新しいキーペアが生成されます。管理者証明書は、キーを再入力することで更新できます。
各サブシステムには、サブシステムの作成時に作成されたブートストラップユーザーがあります。デフォルトの更新プロファイルの 1 つを使用して、元の証明書の有効期限が切れる前に、このユーザーに新しい証明書を要求できます。
管理ユーザーの証明書は、元の証明書のシリアル番号を使用して、エンドユーザー登録フォームで直接更新できます。
  1. 「証明書ベースの更新」 の説明に従って、CA のエンドユーザーフォームで管理ユーザー証明書を更新します。これは、最初に発行した証明書 (またはそのクローン) と同じ CA である必要があります。
    エージェント証明書は、エンドエンティティーページで証明書ベースの更新フォームを使用して更新できます。Self-renew user SSL client certificate。このフォームは、ブラウザーの証明書ストアに保存されている証明書を直接認識して更新します。
    注記
    「certutil を使用した証明書の更新」 で説明されているように、certutil を使用して証明書を更新することもできます。ブラウザーに保存されている証明書を使用して更新を開始するのではなく、certutil は元のキーで入力ファイルを使用します。
  2. 更新されたユーザー証明書を内部 LDAP データベースのユーザーエントリーに追加します。
    1. サブシステムのコンソールを開きます。
      pkiconsole https://server.example.com:admin_port/subsystem_type
    2. 設定 | ユーザーとグループ | ユーザー | 管理 | 証明書 | インポート
    3. Configuration タブで、Users and Groups を選択します。
    4. Users タブで、更新された証明書でユーザーエントリーをダブルクリックして、Certificates をクリックします。
    5. Import をクリックし、Base-64 でエンコードされた証明書に貼り付けます。
    これは、ldapmodify を使用して、uid=admin,ou=people,dc=subsystem-base-DN など、ユーザーエントリーの userCertificate 属性を置き換え、内部の LDAP データベースでユーザーエントリーに直接更新した証明書を追加しました。

14.3.2.4. 期限切れの管理者、エージェント、および監査者のユーザー証明書の更新

有効なユーザー証明書の有効期限がすでに切れている場合、Web サービスページも、認証が必要な pki コマンドラインツールも使用できなくなります。このようなシナリオでは、pki-server cert-fix コマンドを使用して、期限切れの証明書を更新できます。
続行する前に、次のことを確認してください。
  • 有効な CA 証明書があります。
  • root 権限がある

手順14.1 期限切れの管理者、エージェント、および監査者のユーザー証明書の更新

  1. セルフテストを無効にします。
    • 次のコマンドを実行します。
      # pki-server selftest-disable -i PKI_instance
    • または、CA の CS.cfg ファイルから次の行を削除し、CA サブシステムを再起動します。
      selftests.container.order.startup=CAPresence:critical, SystemCertsVerification:critical
  2. クライアントの NSS データベースで期限切れの証明書を確認し、証明書のシリアル番号 (証明書 ID) を見つけます。
    1. ユーザー証明書をリスト表示します。
      # certutil -L -d /root/nssdb/
    2. 更新する期限切れの証明書のシリアル番号を取得します。
      # certutil -L -d /root/nssdb/ -n Expired_cert | grep Serial
          Serial Number: 16 (0x10)
  3. 証明書を更新します。ローカル LDAP サーバーには、LDAP Directory Manager のパスワードが必要です。
    # pki-server cert-fix --ldap-url ldap://host389 --agent-uid caadmin -i PKI_instance -p PKI_https_port --extra-cert 16
  4. セルフテストを再度有効にします。
    • 次のコマンドを実行します。
      # pki-server selftest-enable -i PKI_instance
    • または、次の行を CA の CS.cfg ファイルに追加して、CA サブシステムを再起動します。
      selftests.container.order.startup=CAPresence:critical, SystemCertsVerification:critical
証明書の更新に成功したことを確認するには、次のコマンドを実行して、証明書に関する十分な情報を表示できます。
# pki ca-cert-find
属性、拡張機能、公開鍵モジュラス、ハッシュなどを含む特定の証明書の完全な詳細を表示するには、次を実行することもできます。
# pki ca-cert-show 16 --pretty

14.3.2.5. 証明書システムユーザーの削除

ユーザーは内部データベースから削除できます。内部データベースからユーザーを削除すると、そのユーザーが属するすべてのグループから削除されます。特定のグループからユーザーを削除するには、グループメンバーシップを変更します。
以下の手順を実行して、内部データベースから特権ユーザーを削除します。
  1. 管理コンソールにログインします。
  2. 左側のナビゲーションメニューから Users and Groups を選択します。
  3. ユーザー ID の一覧からユーザーを選択して、Delete をクリックします。
  4. プロンプトが表示されたら、削除を確認します。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.