11.3. CA、OCSP、KRA、TKS のユーザーおよびグループの管理
ユーザーが実行できる操作の多くは、ユーザーが属するグループによって決定されます。たとえば、CA のエージェントは証明書とプロファイルを管理し、管理者は CA サーバーの設定を管理します。
4 つのサブシステム (CA、OCSP、KRA、および TKS) は、Java 管理コンソールを使用してグループとユーザーを管理します。TPS には Web ベースの管理サービスがあり、ユーザーおよびグループは Web サービスページで設定されます。
11.3.1. グループの管理
11.3.1.1. 新規グループの作成
管理コンソールにログインします。
# pkiconsole -d nssdb -n 'optional client cert nickname' https://server.example.com:8443/subsystem_type
注記pkiconsole
は非推奨となり、今後のメジャーリリースで新しいブラウザーベースの UI に置き換えられます。pkiconsole
は代替 UI がリリースされるまで引き続き使用できますが、今後新しいブラウザーベースの UI が使用可能になった場合でも pki CLI のサポートおよび改良は継続されるため、現時点ではpkiconsole
に相当するコマンドラインの使用が推奨されます。- 左側のナビゲーションメニューから Users and Groups を選択します。
- Groups タブを選択します。
内部データベースにすでに存在するユーザーのみを追加することが可能です。
- ACL を編集して、グループの権限を付与します。詳細は、「ACL の編集」 を参照してください。グループの ACL に ACI が追加されていない場合、グループには Certificate System の一部にアクセスパーミッションがありません。
11.3.1.2. グループのメンバーの変更
すべてのグループからメンバーを追加または削除できます。管理者のグループには、最低でもユーザーエントリーが 1 つ必要です。
- 管理コンソールにログインします。
- 左側のナビゲーションツリーから Users and Groups を選択します。
- Groups タブをクリックします。
- 名前のリストからグループを選択し、 をクリックします。
適切な変更を加えます。
- グループの説明を変更するには、Group description フィールドに新しい説明を入力します。
- グループからユーザーを削除するには、ユーザーを選択し、 をクリックします。
- ユーザーを追加するには、 をクリックします。ダイアログボックスから追加するユーザーを選択し、 をクリックします。
11.3.2. ユーザーの管理 (管理者、エージェント、および監査者)
各サブシステムのユーザーは別々に維持されます。あるサブシステムの管理者であるからといって、その人が別のサブシステムに対する権限 (またはユーザーエントリー) を持っているとは限りません。ユーザーを設定して、ユーザー証明書を使用してサブシステムのエージェント、管理者、または監査担当者として信頼できます。
11.3.2.1. ロールユーザーの作成
Certificate System をインストールした後は、セットアップ中に作成されたブートストラップユーザーのみ存在します。追加のロールユーザーを作成するには、コマンドラインまたはコンソールを使用します。このセクションでは、計画、インストール、デプロイメントのガイド (Common Criteria Edition) の 7.12「PKI ロールユーザーの作成」に従って、CA 管理ユーザー (例: jgenie
) と CA エージェントユーザー (例: jsmith
) を作成したと想定します。
セキュリティーと監査上の理由から、Certificate System のユーザーと管理者用に個別のアカウントを作成します。
11.3.2.1.1. ユーザー証明書の登録
ロールユーザーは、認証のために個人証明書を所有している必要があります。次の手順では、ユーザーが証明書を登録する方法について説明します。
ユーザーとして証明書要求を作成し、それを CA エージェントに送信します。
Certificate System 環境に Key Recovery Authority (KRA) が存在する場合は、以下を行います。
# CRMFPopClient -d /home/example-user/certs_db -p password -n "CN=user_name" -q POP_SUCCESS -b kra.transport -w "AES KeyWrap/Wrapped" -v -o ~/user_name.req -oaep Initializing security database: /home/example-user/certs_db archival option enabled Loading transport certificate Parsing subject DN RDN: CN=user_name Generating key pair: temporary: false Keypair private key id: 2eb823eea69e01f0892345dd7d7603be5b9ad2ec Using key wrap algorithm: AES KeyWrap/Wrapped Creating certificate request Creating signer Creating POP Creating CRMF request Storing CRMF request into /home/example-user/certs_db/user_name.req Storing CRMF request key id into /home/example-user/certs_db/user_name.req.keyId
このコマンドは、証明書署名要求 (CSR) を
~/user_name.req
ファイルにCRMF
形式で保存します。CSR 要求ファイルを CA エージェントに送信します。Certificate System 環境に Key Recovery Authority (KRA) が存在しない場合は、以下を行います。
# PKCS10Client -d /home/example-user/certs_db -p password -n "CN=user_name" -o ~/user_name.req PKCS10Client: Certificate request written into /home/example-user/certs_db/user_name.req PKCS10Client: PKCS#10 request key id written into /home/example-user/certs_db/user_name.req.keyId "
このコマンドは、CSR を
pkcs10
形式で~/user_name.req
ファイルに保存します。CSR 要求ファイルを CA エージェントに送信します。
CA エージェントとして、受信した CSR ファイルを入力として使用して登録要求を作成します。
~/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 a 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=jsmith - CA Agent for Example.com #dbdir: directory for cert9.db, key4.db and pkcs11.txt dbdir=/home/jsmith/certs_db #password: password for cert9.db which stores the agent #certificate password=password #format: request format, either pkcs10 or crmf format=crmf
直前の手順で使用した環境および CSR 形式に基づいて、パラメーターを設定します。
以前に作成した設定ファイルを
CMCRequest
ユーティリティーに渡して、CMC 要求を作成します。# CMCRequest ~/cmc.role_crmf.cfg
CA エージェント
jsmith
として、CMC (CMS 経由の証明書管理) 要求を送信します。~/HttpClient_role_crmf.cfg
ファイルを以下の内容で作成します。# #host: host name for the http server host=server.example.com #port: CA 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 cert9.db, key4.db and pkcs11.txt #This parameter will be ignored if secure=false dbdir=/home/jsmith/certs_db #clientmode: true for client authentication, false for no client authentication #This parameter will be ignored if secure=false clientmode=true #password: password for cert9.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=jsmith - CA Agent for Example.com #servlet: servlet name servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caFullCMCUserCert
環境に応じてパラメーターを設定します。
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
結果を確認します。
# CMCResponse -i ~/cmc.role_crmf.resp Certificates: Certificate: Data: Version: v3 Serial Number: 0xF9D290B Signature Algorithm: SHA512withEC - 1.2.840.10045.4.3.4 Issuer: CN=CA Signing Certificate,OU=rhcs10-ECC-SubCA,O=Example-rhcs10-ECC-RootCA Validity: Not Before: Friday, January 26, 2024 12:50:37 AM PST America/Los_Angeles Not After: Wednesday, July 24, 2024 12:50:37 AM PDT 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
発行が成功した場合は、新しく発行された
.crt
証明書ファイルを取得します。# pki -d /home/jsmith/certs_db -c password -p 8443 -n 'jsmith - CA Agent for Example.com' ca-cert-export 0xF9D290B --output-file ~/user.crt
その後、CA エージェント
jsmith
は、証明書を要求元のユーザーに送信します。
要求元のユーザーとして、CA エージェント
jsmith
から受け取った証明書を独自の<user home directory>/certs_db/
データベースにインポートします。# certutil -d ~/certs_db -A -t "u,u,u" -n "user_name" -i ~/user.crt
11.3.2.1.2. コマンドラインでのユーザーの作成
コマンドラインでユーザーを作成するには、以下を実行します。
CA 管理者 (例:
jgenie
) として、ユーザーアカウントを追加します。たとえば、user_name
ユーザーを CA に追加するには、以下を実行します。# pki -d /home/jgenie/certs_db -c password -n caadmin ca-user-add user_name --fullName "Example User" ---------------------- Added user "user_name" ---------------------- User ID: user_name Full name: Example User
このコマンドは、CA 管理者ユーザーを使用して新規アカウントを追加します。
オプションとして、CA 管理者 (例:
jgenie
) として、ユーザーをグループに追加します。たとえば、user_name
ユーザーをCertificate Manager Agents
グループに追加するには、以下を実行します。# pki -d /home/jgenie/certs_db -c password -n "caadmin" ca-user-membership-add user_name "Certificate Manager Agents" ------------------------------------------------ Added membership in "Certificate Manager Agents" ------------------------------------------------ Group: Certificate Manager Agents
CA 管理者として、ユーザーレコードに証明書を追加します。
シリアル番号または証明書ファイルを使用して、Certificate System データベース内のユーザーアカウントに証明書を追加します。たとえば、
user_name
ユーザーの場合、以下を実行します。# pki -d /home/jgenie/certs_db/ -c password -n jgenie ca-user-cert-add user_name --input ~/user.crt
OR
# pki -d /home/jgenie/certs_db/ -c password -n jgenie ca-user-cert-add user_name --serial 0xF9D290B ---------------------------------------------------------------------------------------------------------------------- Added certificate "2;261957899;CN=CA Signing Certificate,OU=rhcs10-ECC-SubCA,O=Example-rhcs10-ECC-RootCA;CN=user_name" ---------------------------------------------------------------------------------------------------------------------- Cert ID: 2;261957899;CN=CA Signing Certificate,OU=rhcs10-ECC-SubCA,O=Example-rhcs10-ECC-RootCA;CN=user_name Version: 2 Serial Number: 0xf9d290b Issuer: CN=CA Signing Certificate,OU=rhcs10-ECC-SubCA,O=Example-rhcs10-ECC-RootCA Subject: CN=user_name
証明書がユーザーレコードに追加されたことを確認します。たとえば、証明書のサブジェクトに
user_name
ユーザーが含まれる証明書をリスト表示するには、次のコマンドを実行します。# pki -d /home/jgenie/certs_db/ -c password -n jgenie ca-user-cert-find user_name ----------------- 1 entries matched ----------------- Cert ID: 2;261957899;CN=CA Signing Certificate,OU=rhcs10-ECC-SubCA,O=Example-rhcs10-ECC-RootCA;CN=user_name Version: 2 Serial Number: 0xf9d290b Issuer: CN=CA Signing Certificate,OU=rhcs10-ECC-SubCA,O=Example-rhcs10-ECC-RootCA Subject: CN=user_name ---------------------------- Number of entries returned 1 ----------------------------
11.3.2.1.3. コンソールを使用したユーザーの作成
PKI コンソールを使用してユーザーを作成するには、次のコマンドを実行します。
管理コンソールにログインします。
# pkiconsole -d nssdb -n 'optional client cert nickname' https://server.example.com:8443/subsystem_type
注記pkiconsole
は非推奨となり、今後のメジャーリリースで新しいブラウザーベースの UI に置き換えられます。pkiconsole
は代替 UI がリリースされるまで引き続き使用できますが、今後新しいブラウザーベースの UI が使用可能になった場合でも pki CLI のサポートおよび改良は継続されるため、現時点ではpkiconsole
に相当するコマンドラインの使用が推奨されます。- Configuration タブで、Users and Groups を選択します。 をクリックします。
Edit User Information ダイアログに情報を入力します。
情報のほとんどは、ユーザー名、メールアドレス、パスワードなどの標準のユーザー情報です。このウィンドウには、User State と呼ばれるフィールドも含まれ、このフィールドにはユーザーに関する追加情報を追加するために使用される文字列を含めることができます。最も基本的なことですが、このフィールドにはユーザーがアクティブかどうかが表示されます。
- ユーザーが属するグループを選択します。ユーザーのグループメンバーシップにより、ユーザーが持つ特権が決まります。エージェント、管理者、および監査人を適切なサブシステムグループに割り当てます。
ユーザーの証明書を追加します。
- CA エンドエンティティーサービスページでユーザー証明書を要求します。
- ユーザープロファイルに対して自動登録が設定されていない場合は、証明書要求を承認します。
-
user.crt
の内容 (「ユーザー証明書の登録」 どおりに実行した結果) をクリップボードにコピーします。 - 新しいユーザーエントリーを選択し、 をクリックします。
- をクリックし、base-64 でエンコードされた証明書に貼り付けます。
11.3.2.2. Certificate System ユーザー証明書の変更
- 管理コンソールにログインします。
- Users and Groups を選択します。
- ユーザー ID のリストから編集するユーザーを選択し、 をクリックします。
- をクリックして、新しい証明書を追加します。
-
Import Certificate ウィンドウで、テキストエリアに新しい証明書をペーストします。
-----BEGIN CERTIFICATE-----
および-----END CERTIFICATE-----
マーカー行を含めます。
11.3.2.3. 管理者、エージェント、および監査ユーザー証明書の更新
証明書を更新する方法は 2 つあります。証明書を 再生成 すると、元の鍵と元のプロファイルと要求を取得し、新しい有効期間と有効期限で同一の鍵を再作成します。証明書の キーを再入力 すると、最初の証明書要求が元のプロファイルに再送信されますが、新しいキーペアが生成されます。管理者証明書は、キーを再入力することで更新できます。
各サブシステムには、サブシステムの作成時に作成されたブートストラップユーザーがあります。デフォルトの更新プロファイルの 1 つを使用して、元の証明書の有効期限が切れる前に、このユーザーに新しい証明書を要求できます。
管理ユーザーの証明書は、元の証明書のシリアル番号を使用して、エンドユーザー登録フォームで直接更新できます。
- 管理ユーザー証明書を更新します。詳細は、「証明書の更新」 を参照してください。
更新されたユーザー証明書を内部 LDAP データベースのユーザーエントリーに追加します。
サブシステムのコンソールを開きます。
# pkiconsole -d nssdb -n 'optional client cert nickname' https://server.example.com:admin_port/subsystem_type
注記pkiconsole
は非推奨となり、今後のメジャーリリースで新しいブラウザーベースの UI に置き換えられます。pkiconsole
は代替 UI がリリースされるまで引き続き使用できますが、今後新しいブラウザーベースの UI が使用可能になった場合でも pki CLI のサポートおよび改良は継続されるため、現時点ではpkiconsole
に相当するコマンドラインの使用が推奨されます。- 設定 | ユーザーとグループ | ユーザー | 管理 | 証明書 | インポート
- Configuration タブで、Users and Groups を選択します。
- Users タブで、更新された証明書が含まれるユーザーエントリーをダブルクリックし、 をクリックします。
- をクリックし、base-64 でエンコードされた証明書に貼り付けます。
これは、ldapmodify
を使用して、ユーザーエントリーの userCertificate
属性 (例: uid=admin,ou=people,dc=subsystem-base-DN
) を置き換え、内部の LDAP データベースでユーザーエントリーに直接更新した証明書を追加しました。
11.3.2.4. Certificate System ユーザーの削除
ユーザーは内部データベースから削除できます。内部データベースからユーザーを削除すると、そのユーザーが属するすべてのグループから削除されます。特定のグループからユーザーを削除するには、グループメンバーシップを変更します。
以下の手順を実行して、内部データベースから特権ユーザーを削除します。
- 管理コンソールにログインします。
- 左側のナビゲーションメニューから Users and Groups を選択します。
- ユーザー ID のリストからユーザーを選択して、 をクリックします。
- プロンプトが表示されたら削除を確認します。
または、管理者として CLI で次のコマンドを実行することで、システムユーザーを削除することもできます。
# pki -d /home/jgenie/certs_db -c password -n caadmin ca-user-del user_name ------------------------ Deleted user "user_name" ------------------------