5.5. CMC を使用した証明書要求の送信


このセクションでは、CMS (Certificate Management over CMS) を使用して証明書を登録する手順を説明します。
CMC を使用して証明書を登録する設定とワークフローの一般的な情報は、以下を参照してください。
  • Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』 の CMC の設定 セクションを参照してください。
  • Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』 の CMC を使用した登録 セクション
  • CMCRequest(1) の man ページを参照してください。
  • CMCResponse(1) の man ページを参照してください。
CMC の登録は、さまざまなシナリオの要件を満たすためにさまざまな方法で可能です。「CMC 登録プロセス」 は、『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』 の CMC を使用した登録 セクションを補足します。さらに、「実用的な CMC 登録シナリオ」 セクションを使用すると、管理者はどのメカニズムをどのシナリオで使用するかを決定できます。

5.5.1. CMC 登録の使用

CMC 登録により、登録クライアントは認証に CMCAuth プラグインを使用できます。これにより、証明書要求はエージェント証明書で事前署名されます。Certificate Manager は、エージェント証明書で署名した有効な要求を受け取れると、証明書を自動的に発行します。
注記
CMC 登録はデフォルトで有効になっています。設定が変更されていない限り、CMC 登録認証プラグインまたはプロファイルを有効にする必要はありません。
CMCAuth 認証プラグインは、クライアントに CMC 失効も提供します。CMC の失効により、クライアントはエージェント証明書によって署名された証明書要求を取得し、そのような要求を Certificate Manager に送信できます。Certificate Manager は、エージェント証明書で署名した有効な要求を受け取ると、証明書を自動的に取り消します。CMCRevoke コマンドラインツールを使用して、CMC 失効を作成できます。CMCRevoke の詳細は、「CMC 失効の実行」 を参照してください。
CMC リクエストは、ブラウザーのエンドエンティティーフォームから、または HttpClient などのツールを使用して送信して、適切なプロファイルにリクエストを投稿できます。この CMCRequest ツールは、署名済み証明書要求を生成し、HttpClient ツールまたはブラウザーのエンドエンティティーフォームを使用して、証明書を自動的かつ即座に登録および受信します。
CMCRequest ツールには簡単なコマンド構文があり、.cfg 入力ファイルに指定されるすべての設定が設定されます。
CMCRequest /path/to/file.cfg
以下の構文で、CMCEnroll ツールを使用して 1 回の登録を作成することもできます。
CMCEnroll -d /agent's/certificate/directory -h password -n cert_nickname -r certrequest.file -p certDB_passwd [-c "comment"]
これらのツールの詳細は、CMCEnroll(1) の man ページで説明されています。
注記
引用符で囲まれたスペースを含む値を囲みます。

5.5.1.1. CMCEnroll のテスト

  1. certutil ツールを使用して証明書要求を作成します。
  2. PKCS #10 ASCII 出力をテキストファイルにコピーします。
  3. CMCEnroll ユーティリティーを実行します。
    たとえば、入力ファイルが request34.txt を呼び出すと、エージェント証明書はブラウザーデータベースに保存され、エージェント証明書の証明書の一般名は CertificateManagerAgentsCert で、および証明書データベースのパスワードは secret で、コマンドは次のとおりです。
    CMCEnroll -d ~jsmith/.mozilla/firefox/1234.jsmith -n "CertificateManagerAgentsCert" -r /export/requests/request34.txt -p secret
    このコマンドの出力は、ファイル名に加えられた .out で同じファイル名のファイルに保存されます。
  4. エンドエンティティーを通じて署名済み証明書を提出します。
    1. エンドエンティティーを開きます。
      https://server.example.com:8443/ca/ee/ca
    2. 証明書プロファイルのリストから CMC 登録フォームを選択します。
    3. 出力ファイルの内容をこの形式の Certificate Request テキスト領域に貼り付けます。
    4. 貼り付けられたコンテンツから -----BEGIN NEW CERTIFICATE REQUEST----- および ----END NEW CERTIFICATE REQUEST----- を削除します。
    5. 連絡先情報を入力して、フォームに入力します。
  5. 証明書は即座に処理され、返されます。
  6. エージェントページを使用して、新しい証明書を検索します。

5.5.2. CMC 登録プロセス

CMC を使用して証明書を要求および発行するには、次の一般的な手順を使用します。
  1. Certificate Signing Request (CSR) を、以下のいずれかの形式で作成します。
    • PKCS #10 形式
    • Certificate Request Message Format (CRMF) 形式
    これらの形式で CSR を作成する方法は、「証明書署名リクエストの作成」 を参照してください。
  2. 管理証明書をクライアントの NSS データベースにインポートします。以下に例を示します。
    • 以下のコマンドを実行して、.p12 ファイルから管理クライアント証明書を抽出します。
      $ openssl pkcs12 -in /root/.dogtag/instance/ca_admin_cert.p12 -clcerts -nodes -nokeys -out /root/.dogtag/instance/ca_admin_cert.crt
    • Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』の証明書/キー暗号化トークンの管理セクションに従って、管理クライアント証明書の検証およびインポートを行います。
      $ PKICertImport -d . -n "CA Admin - Client Certificate" -t ",," -a -i /root/.dogtag/instance/ca_admin_cert.crt -u C
      重要
      CA 管理クライアント証明書をインポートする前に、中間証明書とルート CA 証明書がインポートされていることを確認します。
    • 証明書に関連付けられた秘密鍵をインポートします。
      $ pki -c password pkcs12-import --pkcs12-file /root/.dogtag/instance/ca_admin_cert.p12 --pkcs12-password-file /root/.dogtag/instance/ca/pkcs12_password.conf
  3. 以下の内容で、/home/user_name/cmc-request.cfg などの CMC 要求用の設定ファイルを作成します。
    # NSS database directory where CA agent certificate is stored
    dbdir=/home/user_name/.dogtag/nssdb/
    
    # NSS database password
    password=password
    
    # Token name (default is internal)
    tokenname=internal
    
    # Nickname for signing certificate
    nickname=subsystem_admin
    
    # Request format: pkcs10 or crmf
    format=pkcs10
    
    # Total number of PKCS10/CRMF requests
    numRequests=1
    
    # Path to the PKCS10/CRMF request
    # The content must be in Base-64 encoded format.
    # Multiple files are supported. They must be separated by space.
    input=/home/user_name/file.csr
    
    # Path for the CMC request
    output=/home/user_name/cmc-request.bin
    詳細は、CMCRequest(1) の man ページを参照してください。
  4. CMC 要求を作成します。
    $ CMCRequest /home/user_name/cmc-request.cfg
    コマンドが成功すると、CMCRequest ユーティリティーは、要求設定ファイルの output パラメーターで指定されたファイルに CMC 要求を保存します。
  5. /home/user_name/cmc-submit.cfg などの HttpClient の設定ファイルを作成します。このファイルは、後で CMC 要求を CA に送信します。作成されたファイルに以下の内容を追加します。
    # PKI server host name
    host=server.example.com
    
    # PKI server port number
    port=8443
    
    # Use secure connection
    secure=true
    
    # Use client authentication
    clientmode=true
    
    # NSS database directory where the CA agent certificate is stored.
    dbdir=/home/user_name/.dogtag/nssdb/
    
    # NSS database password
    password=password
    
    # Token name (default: internal)
    tokenname=internal
    
    # Nickname of signing certificate
    nickname=subsystem_admin
    
    # Path for the CMC request
    input=/home/user_name/cmc-request.bin
    
    # Path for the CMC response
    output=/home/user_name/cmc-response.bin
    重要
    nickname パラメーターで指定された証明書のニックネームは、CMC 要求で以前使用された内容と一致させる必要があります。
  6. 要求する証明書のタイプに応じて、前の手順で作成した設定ファイルに次のパラメーターを追加します。
    servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=profile_name
    CA 署名証明書の場合の例を以下に示します。
    servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCcaCert
    重要
    エージェントが次のステップで CMC 要求を送信する場合は、このパラメーターで指定したプロファイルは CMCAuth 認証プラグインを使用する必要があります。ユーザーが作成した登録では、プロファイルは CMCUserSignedAuth プラグインを使用する必要があります。詳細は、「CMC 認証プラグイン」 を参照してください。
  7. CMC 要求を CA に送信します。
    $ HttpClient /home/user_name/cmc-submit.cfg
  8. CMC の応答を PKCS #7 証明書チェーンに変換するには、CMCResponse ユーティリティーの -i パラメーターに CMC レスポンスファイルを渡します。以下に例を示します。
    $ CMCResponse -i /home/user_name/cmc-response.bin -o /home/user_name/cert_chain.crt

5.5.3. 実用的な CMC 登録シナリオ

このセクションでは、CA 管理者がどの状況でどの CMC メソッドを使用するかを決定できるようにするための、頻繁な実際の使用シナリオとそのワークフローを説明します。
CMC を使用して証明書を登録する一般的なプロセスは、「CMC 登録プロセス」 を参照してください。

5.5.3.1. システム証明書およびサーバー証明書の取得

LDAP や Web サーバーなどのサービスで TLS サーバー証明書が必要な場合、このサーバーの管理者はサービスのドキュメントに基づいて CSR を作成し、承認のために CA のエージェントに送信します。このプロセスには、「CMC 登録プロセス」 で説明されている手順を使用します。また、以下の要件を考慮してください。
登録プロファイル
エージェントは、「CMC 認証プラグイン」 にリストされている既存の CMC プロファイルのいずれかを使用する必要があります。または、CMCAuth 認証メカニズムを使用するカスタムプロファイルを作成します。
CMC 署名証明書
システム証明書の場合、CA エージェントは CMC 要求を生成して署名する必要があります。そのためには、CMCRequest 設定ファイルの nickname パラメーターを CA エージェントのニックネームに設定します。
注記
CA エージェントは、独自の秘密鍵にアクセスできるようにする必要があります。
HttpClient TLS Client Nickname
HttpClient の設定ファイル内で TLS クライアント認証に関するユーティリティーの設定ファイルに対して、CMCRequest ユーティリティー設定ファイルへのサインインに同じ証明書を使用します。
HttpClient servlet パラメーター
HttpClient ユーティリティーに渡される設定ファイルの servlet では、要求を処理する CMC サーブレットおよび登録プロファイルが参照されます。
要求する証明書のタイプに応じて、直前の手順で作成した設定ファイルに以下のエントリーのいずれかを追加します。
  • CA 署名証明書の場合:
    servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCcaCert
  • KRA トランスポート証明書の場合:
    servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCkraTransportCert
  • OCSP 署名証明書の場合:
    servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCocspCert
  • 監査署名証明書の場合:
    servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCauditSigningCert
  • サブシステム証明書の場合:
    • RSA 証明書の場合:
      servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCsubsystemCert
    • ECC 証明書の場合:
      servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCECCsubsystemCert
  • TLS サーバー証明書の場合:
    • RSA 証明書の場合:
      servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCserverCert
    • ECC 証明書の場合:
      servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCECCserverCert
  • 管理証明書の場合:
    servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caFullCMCUserCert
詳細は以下を参照してください。
  • エージェントが CSR を事前署名する場合、エージェントは識別のために CSR を調べるため、Proof of Identification が確立されたと見なされます。追加の CMC 固有の識別証明は必要ありません。
  • PKCS #10 ファイルはすでに Proof of Possession (POP) 情報を提供し、追加の Proof of Possession (POP) は必要ありません。
  • エージェントの事前承認済みリクエストでは、識別はエージェントによってチェックされるため、PopLinkWittnessV2 機能を無効にする必要があります。

5.5.3.2. ユーザーの初回署名証明書の取得

ユーザーの最初の署名証明書を承認する方法は 2 つあります。
5.5.3.2.1. エージェント証明書を使用した CMC 要求の署名
エージェント証明書を使用して CMC 要求に署名するプロセスは、「システム証明書およびサーバー証明書の取得」 で説明されているシステム証明書およびサーバー証明書の場合と同じです。唯一の違いは、ユーザーが CSR を作成し、承認のために CA エージェントに送信することです。
5.5.3.2.2. 共有シークレットを使用した証明書の登録の認証
ユーザーが最初の署名証明書を取得したいが、エージェントが、「エージェント証明書を使用した CMC 要求の署名」 で説明されているように要求を承認できない場合は、共有トークンを使用できます。このトークンを使用すると、ユーザーは最初の署名証明書を取得できます。次に、この証明書を使用してユーザーの他の証明書に署名できます。
このシナリオでは、Shared Secret のメカニズムを使用して、ユーザーの最初の署名証明書を取得します。「CMC 登録プロセス」 とともに以下の情報を使用します。
  1. ユーザーまたは CA 管理者として共有トークンを作成します。詳細は、『Red Hat Certificate System 計画、インストール、およびデプロイメントガイド』 の 共有シークレットワークフロー セクションを参照してください。
    以下の点に留意してください。
    • ユーザーがトークンを作成した場合、ユーザーはトークンを CA 管理者に送信する必要があります。
    • CA 管理者がトークンを作成した場合、管理者はユーザーがトークンを生成するのに使用するパスワードを共有する必要があります。セキュアな方法でパスワードを送信します。
  2. CA 管理者として、LDAP のユーザーエントリーに Shared Token を追加します。詳細は、『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』 の 「証明書の登録用ユーザーエントリーへの CMC 共有シークレットの追加」 および CMC 共有シークレット機能の有効化 セクションを参照してください。
  3. CMCRequest ユーティリティーに渡される設定ファイルで以下のパラメーターを使用します。
    • identification.enable
    • witness.sharedSecret
    • identityProofV2.enable
    • identityProofV2.hashAlg
    • identityProofV2.macAlg
    • request.useSharedSecret
    • request.privKeyId
  4. CA で必要な場合は、CMCRequest ユーティリティーに渡される設定ファイルで以下のパラメーターも使用します。
    • popLinkWitnessV2.enable
    • popLinkWitnessV2.keyGenAlg
    • popLinkWitnessV2.macAlg

5.5.3.3. ユーザーの暗号化のみの証明書の取得

このセクションでは、既存のユーザー署名証明書で署名された暗号化のみの証明書を取得するワークフローを説明します。
注記
ユーザーがさまざまな用途で複数の証明書を所有していて、1 つが署名している場合、ユーザーは最初に署名証明書を取得する必要があります。ユーザーが署名証明書を所有すると、CMC Shared Secret メカニズムを設定して依存することなく、Proof Of Origin に使用できます。
ユーザーの最初の署名証明書を取得する方法は、「ユーザーの初回署名証明書の取得」 を参照してください。
ユーザーとして以下を行います。
  1. Network Security Services (NSS) データベースまたはユーザーの署名証明書および鍵が含まれるスマートカードに保存されている暗号化トークンを使用します。
  2. PKCS #10 形式または CRMF 形式で CSR を生成します。
    注記
    (キーのアーカイブが必要な場合は) CRMF 形式を使用してください。
  3. CMC 要求を生成します。
    これは暗号のみの証明書であるため、秘密鍵は署名できません。そのため、Proof Of Possession (POP) は含まれていません。このため、登録には、2 つの手順が必要です。最初のリクエストが成功すると、EncryptedPOP 制御のある CMC 状態が生じます。次に、ユーザーは応答を使用して、DecryptedPOP 制御を含む CMC 要求を生成し、2 番目のステップで送信します。
    1. 最初のステップでは、デフォルトのパラメーターに加えて、ユーザーは、CMCRequest ユーティリティーに渡される設定ファイルに次のパラメーターを設定する必要があります。
      • identification.enable
      • witness.sharedSecret
      • identityProofV2.enable
      • identityProofV2.hashAlg
      • identityProofV2.macAlg
      • popLinkWitnessV2.enable (CA で必要な場合)
      • popLinkWitnessV2.keyGenAlg (CA で必要な場合)
      • popLinkWitnessV2.macAlg (CA で必要な場合)
      • request.privKeyId
      詳細は、CMCRequest(1) の man ページを参照してください。
      応答には以下が含まれます。
      • CMC で暗号化された POP コントロール
      • POP の required エラーでの CMCStatusInfoV2 コントロール
      • リクエスト ID
    2. 次のステップでは、デフォルトのパラメーターに加えて、ユーザーは、CMCRequest ユーティリティーに渡される設定ファイルに次のパラメーターを設定する必要があります。
      • decryptedPop.enable
      • encryptedPopResponseFile
      • decryptedPopRequestFile
      • request.privKeyId
      詳細は、CMCRequest(1) の man ページを参照してください。
5.5.3.3.1. キーアーカイブを使用した暗号化のみの証明書の取得例
キーアーカイブを使用して登録を実行するには、CRMF 要求にユーザーの暗号化された秘密鍵を含む CMC 要求を生成します。以下の手順は、ユーザーが署名証明書をすでに所有していることを前提としています。この署名証明書のニックネームは、手順の設定ファイルに設定されます。
注記
以下の手順は、署名に使用できない暗号のみの鍵で使用される 2 通の発行を説明します。証明書に署名できるキーを使用する場合は、-q POP_NONE の代わりに -q POP_SUCCESS オプションを、単一トリップ発行のために CRMFPopClient ユーティリティーに渡します。
  1. KRA トランスポート証明書を検索します。以下に例を示します。
    $ pki cert-find --name KRA_transport_certificate_subject_CN
  2. 前の手順で取得した KRA トランスポート証明書のシリアル番号を使用して、証明書をファイルに保存します。たとえば、/home/user_name/kra.cert ファイルに 12345 シリアル番号がある証明書を保存するには、次のコマンドを実行します。
    $ pki cert-show 12345 --output /home/user_name/kra.cert
  3. CRMFPopClient ユーティリティーを使用して以下を行います。
    • キーアーカイブを使用して CSR を作成します。
      1. 証明書が要求されるユーザーまたはエンティティーの証明書データベースディレクトリーに移動します。以下に例を示します。
        $ cd /home/user_name/
      2. RSA 秘密鍵が KRA トランスポート証明書によりラップされる CRMF 要求を作成するには、CRMFPopClient ユーティリティーを使用します。たとえば、要求を /home/user_name/crmf.req ファイルに保存するには、以下のコマンドを実行します。
        $ CRMFPopClient -d . -p token_password -n subject_DN -q POP_NONE \
        		 -b /home/user_name/kra.cert -w "AES/CBC/PKCS5Padding" \
        		 -v -o /home/user_name/crmf.req
        コマンドで表示される秘密鍵の ID をメモします。ID は、2 番目のトリップの設定ファイルの request.privKeyId パラメーターの値として、後のステップで必要になります。
  4. 以下の内容を含む、/home/user_name/cmc.cfg など、CRMRequest ユーティリティー用の設定ファイルを作成します。
    #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
    input=/home/user_name/crmf.req
    
    #output: full path for the CMC request in binary format
    output=/home/user_name/cmc.req
    
    #tokenname: name of token where agent signing cert can be found
    #(default is internal)
    tokenname=internal
    
    #nickname: nickname for user certificate which will be used
    #to sign the CMC full request.
    nickname=signing_certificate
    
    #dbdir: directory for cert9.db, key4.db and pkcs11.txt
    dbdir=/home/user_name/.dogtag/nssdb/
    
    #password: password for cert9.db which stores the agent certificate
    password=password
    
    #format: request format, either pkcs10 or crmf
    format=crmf
  5. CMC 要求を作成します。
    $ CMCRequest /home/user_name/cmc.cfg
    コマンドが成功すると、CMCRequest ユーティリティーは、要求設定ファイルの output パラメーターで指定されたファイルに CMC 要求を保存します。
  6. /home/user_name/cmc-submit.cfg などの HttpClient の設定ファイルを作成します。このファイルは、後で CMC 要求を CA に送信します。作成されたファイルに以下の内容を追加します。
    #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=/home/user_name/cmc.req
    
    #output: full path for the response in binary format
    output=/home/user_name/cmc-response_round_1.bin
    
    #tokenname: name of token where TLS 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/user_name/.dogtag/nssdb/
    
    #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=signing_certificate
    
    #servlet: servlet name
    servlet=/ca/ee/ca/profileSubmitUserSignedCMCFull?profileId=caFullCMCUserSignedCert
  7. CMC 要求を CA に送信します。
    $ HttpClient /home/user_name/cmc-submit.cfg
    コマンドが成功すると、HTTPClient ユーティリティーは、CMC 応答を、設定ファイルの output パラメーターで指定されたファイルに保存します。
  8. 応答ファイルを CMCResponse ユーティリティーに渡して応答を確認します。以下に例を示します。
    $ CMCResponse -d /home/user_name/.dogtag/nssdb/ -i /home/user_name/cmc-response_round_1.bin
    最初のトリップが成功した場合は、CMCResponse は、以下のような出力を表示します。
    Certificates:
    		Certificate:
    				Data:
    						Version:  v3
    						Serial Number: 0x1
    						Signature Algorithm: SHA256withRSA - 1.2.840.113549.1.1.11
    						Issuer: CN=CA Signing Certificate,OU=pki-tomcat,O=unknown00262DFC6A5E Security Domain
    						Validity:
    								Not Before: Wednesday, May 17, 2017 6:06:50 PM PDT America/Los_Angeles
    								Not  After: Sunday, May 17, 2037 6:06:50 PM PDT America/Los_Angeles
    						Subject: CN=CA Signing Certificate,OU=pki-tomcat,O=unknown00262DFC6A5E Security Domain
    ...
    Number of controls is 3
    Control #0: CMC encrypted POP
    	 OID: {1 3 6 1 5 5 7 7 9}
    		 encryptedPOP decoded
    Control #1: CMCStatusInfoV2
    	 OID: {1 3 6 1 5 5 7 7 25}
    	 BodyList: 1
    	 OtherInfo type: FAIL
    		 failInfo=POP required
    Control #2: CMC ResponseInfo
    	 requestID: 15
  9. 2 番目のトリップの場合は、後の手順で使用する /home/user_name/cmc_DecryptedPOP.cfg などの DecryptedPOP の設定ファイルを作成します。作成されたファイルに以下の内容を追加します。
    #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
    #this field is actually unused in 2nd trip
    input=/home/user_name/crmf.req
    
    #output: full path for the CMC request in binary format
    #this field is actually unused in 2nd trip
    output=/home/user_name/cmc2.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=signing_certificate
    
    #dbdir: directory for cert9.db, key4.db and pkcs11.txt
    dbdir=/home/user_name/.dogtag/nssdb/
    
    #password: password for cert9.db which stores the agent
    #certificate
    password=password
    
    #format: request format, either pkcs10 or crmf
    format=crmf
    
    decryptedPop.enable=true
    encryptedPopResponseFile=/home/user_name/cmc-response_round_1.bin
    request.privKeyId=-25aa0a8aad395ebac7e6a19c364f0dcb5350cfef
    decryptedPopRequestFile=/home/user_name/cmc.DecryptedPOP.req
  10. DecryptPOP CMC 要求を作成します。
    $ CMCRequest /home/user_name/cmc.DecryptedPOP.cfg
    コマンドが成功すると、CMCRequest ユーティリティーは、要求設定ファイルの decryptedPopRequestFile パラメーターで指定されたファイルに CMC 要求を保存します。
  11. /home/user_name/decrypted_POP_cmc-submit.cfg などの HttpClient の設定ファイルを作成します。このファイルは、後で DecryptedPOP CMC 要求を CA に送信します。作成されたファイルに以下の内容を追加します。
    #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=/home/user_name/cmc.DecryptedPOP.req
    
    #output: full path for the response in binary format
    output=/home/user_name/cmc-response_round_2.bin
    
    #tokenname: name of token where TLS 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/user_name/.dogtag/nssdb/
    
    #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=singing_certificate
    
    #servlet: servlet name
    servlet=/ca/ee/ca/profileSubmitUserSignedCMCFull?profileId=caFullCMCUserCert
  12. DecryptedPOP CMC 要求を CA に送信します。
    $ HttpClient /home/user_name/decrypted_POP_cmc-submit.cfg
    コマンドが成功すると、HTTPClient ユーティリティーは、CMC 応答を、設定ファイルの output パラメーターで指定されたファイルに保存します。
  13. CMC の応答を PKCS #7 証明書チェーンに変換するには、CMCResponse ユーティリティーの -i パラメーターに CMC レスポンスファイルを渡します。以下に例を示します。
    $ CMCResponse -i /home/user_name/cmc-response_round_2.bin -o /home/user_name/certs.p7
    または、個々の証明書を PEM 形式で表示するには、-v ユーティリティーに渡します。
    次のトリップが成功した場合は、CMCResponse は、以下のような出力を表示します。
    Certificates:
    		Certificate:
    				Data:
    						Version:  v3
    						Serial Number: 0x2D
    						Signature Algorithm: SHA256withRSA - 1.2.840.113549.1.1.11
    						Issuer: CN=CA Signing Certificate,OU=pki-tomcat,O=unknown00262DFC6A5E Security Domain
    						Validity:
    								Not Before: Thursday, June 15, 2017 3:43:45 PM PDT America/Los_Angeles
    								Not  After: Tuesday, December 12, 2017 3:43:45 PM PST America/Los_Angeles
    						Subject: CN=user_name,UID=example,OU=keyArchivalExample
    ...
    Number of controls is 1
    Control #0: CMCStatusInfo
    	 OID: {1 3 6 1 5 5 7 7 1}
    	 BodyList: 1
    	 Status: SUCCESS
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.