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 のテスト
- certutil ツールを使用して証明書要求を作成します。
- PKCS #10 ASCII 出力をテキストファイルにコピーします。
- CMCEnroll ユーティリティーを実行します。たとえば、入力ファイルが
request34.txt
を呼び出すと、エージェント証明書はブラウザーデータベースに保存され、エージェント証明書の証明書の一般名は CertificateManagerAgentsCert で、および証明書データベースのパスワードは secret で、コマンドは次のとおりです。CMCEnroll -d ~jsmith/.mozilla/firefox/1234.jsmith -n "CertificateManagerAgentsCert" -r /export/requests/request34.txt -p secret
このコマンドの出力は、ファイル名に加えられた .out で同じファイル名のファイルに保存されます。 - エンドエンティティーを通じて署名済み証明書を提出します。
- エンドエンティティーを開きます。
http
s
://server.example.com:8443/ca/ee/ca
- 証明書プロファイルのリストから CMC 登録フォームを選択します。
- 出力ファイルの内容をこの形式の Certificate Request テキスト領域に貼り付けます。
- 貼り付けられたコンテンツから -----BEGIN NEW CERTIFICATE REQUEST----- および ----END NEW CERTIFICATE REQUEST----- を削除します。
- 連絡先情報を入力して、フォームに入力します。
- 証明書は即座に処理され、返されます。
- エージェントページを使用して、新しい証明書を検索します。
5.5.2. CMC 登録プロセス
CMC を使用して証明書を要求および発行するには、次の一般的な手順を使用します。
- Certificate Signing Request (CSR) を、以下のいずれかの形式で作成します。
- PKCS #10 形式
- Certificate Request Message Format (CRMF) 形式
これらの形式で CSR を作成する方法は、「証明書署名リクエストの作成」 を参照してください。 - 管理証明書をクライアントの 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
- 以下の内容で、
/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 ページを参照してください。 - CMC 要求を作成します。
$ CMCRequest /home/user_name/cmc-request.cfg
コマンドが成功すると、CMCRequest ユーティリティーは、要求設定ファイルのoutput
パラメーターで指定されたファイルに CMC 要求を保存します。 /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 要求で以前使用された内容と一致させる必要があります。- 要求する証明書のタイプに応じて、前の手順で作成した設定ファイルに次のパラメーターを追加します。
servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=profile_name
CA 署名証明書の場合の例を以下に示します。servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCcaCert
重要エージェントが次のステップで CMC 要求を送信する場合は、このパラメーターで指定したプロファイルはCMCAuth
認証プラグインを使用する必要があります。ユーザーが作成した登録では、プロファイルはCMCUserSignedAuth
プラグインを使用する必要があります。詳細は、「CMC 認証プラグイン」 を参照してください。 - CMC 要求を CA に送信します。
$ HttpClient /home/user_name/cmc-submit.cfg
- 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 NicknameHttpClient
の設定ファイル内で 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 つあります。
- エージェントは CMC 要求を署名します。「エージェント証明書を使用した CMC 要求の署名」 を参照してください。
- 証明書の登録は、共有シークレットを使用して認証されます。「共有シークレットを使用した証明書の登録の認証」 を参照してください。
5.5.3.2.1. エージェント証明書を使用した CMC 要求の署名
エージェント証明書を使用して CMC 要求に署名するプロセスは、「システム証明書およびサーバー証明書の取得」 で説明されているシステム証明書およびサーバー証明書の場合と同じです。唯一の違いは、ユーザーが CSR を作成し、承認のために CA エージェントに送信することです。
5.5.3.3. ユーザーの暗号化のみの証明書の取得
このセクションでは、既存のユーザー署名証明書で署名された暗号化のみの証明書を取得するワークフローを説明します。
注記
ユーザーがさまざまな用途で複数の証明書を所有していて、1 つが署名している場合、ユーザーは最初に署名証明書を取得する必要があります。ユーザーが署名証明書を所有すると、CMC Shared Secret メカニズムを設定して依存することなく、Proof Of Origin に使用できます。
ユーザーの最初の署名証明書を取得する方法は、「ユーザーの初回署名証明書の取得」 を参照してください。
ユーザーとして以下を行います。
- Network Security Services (NSS) データベースまたはユーザーの署名証明書および鍵が含まれるスマートカードに保存されている暗号化トークンを使用します。
- PKCS #10 形式または CRMF 形式で CSR を生成します。注記(キーのアーカイブが必要な場合は) CRMF 形式を使用してください。
- CMC 要求を生成します。これは暗号のみの証明書であるため、秘密鍵は署名できません。そのため、Proof Of Possession (POP) は含まれていません。このため、登録には、2 つの手順が必要です。最初のリクエストが成功すると、
EncryptedPOP
制御のある CMC 状態が生じます。次に、ユーザーは応答を使用して、DecryptedPOP
制御を含む CMC 要求を生成し、2 番目のステップで送信します。- 最初のステップでは、デフォルトのパラメーターに加えて、ユーザーは、
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
- 次のステップでは、デフォルトのパラメーターに加えて、ユーザーは、
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
ユーティリティーに渡します。
POP_SUCCESS で
CRMFPoPClient
を使用する方法は、「CRMFPopClient
を使用したキー Archival を持つ CSR の作成」 および 「CRMFPopClient
を使用した SharedSecret ベースの CMC の CSR の作成」 を参照してください。
- KRA トランスポート証明書を検索します。以下に例を示します。
$ pki cert-find --name KRA_transport_certificate_subject_CN
- 前の手順で取得した KRA トランスポート証明書のシリアル番号を使用して、証明書をファイルに保存します。たとえば、
/home/user_name/kra.cert
ファイルに 12345 シリアル番号がある証明書を保存するには、次のコマンドを実行します。$ pki cert-show 12345 --output /home/user_name/kra.cert
CRMFPopClient
ユーティリティーを使用して以下を行います。- キーアーカイブを使用して CSR を作成します。
- 証明書が要求されるユーザーまたはエンティティーの証明書データベースディレクトリーに移動します。以下に例を示します。
$ cd /home/user_name/
- 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
パラメーターの値として、後のステップで必要になります。
- 以下の内容を含む、
/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
- CMC 要求を作成します。
$ CMCRequest /home/user_name/cmc.cfg
コマンドが成功すると、CMCRequest ユーティリティーは、要求設定ファイルのoutput
パラメーターで指定されたファイルに CMC 要求を保存します。 /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
- CMC 要求を CA に送信します。
$ HttpClient /home/user_name/cmc-submit.cfg
コマンドが成功すると、HTTPClient ユーティリティーは、CMC 応答を、設定ファイルのoutput
パラメーターで指定されたファイルに保存します。 - 応答ファイルを
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
- 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
DecryptPOP
CMC 要求を作成します。$ CMCRequest /home/user_name/cmc.DecryptedPOP.cfg
コマンドが成功すると、CMCRequest ユーティリティーは、要求設定ファイルのdecryptedPopRequestFile
パラメーターで指定されたファイルに CMC 要求を保存します。/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
DecryptedPOP
CMC 要求を CA に送信します。$ HttpClient /home/user_name/decrypted_POP_cmc-submit.cfg
コマンドが成功すると、HTTPClient ユーティリティーは、CMC 応答を、設定ファイルのoutput
パラメーターで指定されたファイルに保存します。- 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