7.9. KRA インスタンスの作成および設定


このセクションでは、SubCA に対する KRA インスタンスのインストールと設定を説明します。この例では、KRA は rhcs10.example.com にインストールされ、その内部ディレクトリーサーバーは rhds11.example.com にあります。

注記

/opt/pki_rsa/ca-chain.pem ファイルに完全な CA 証明書チェーン (SubCA および RootCA 証明書) が含まれていることを確認します。

Copy to Clipboard Toggle word wrap
# ls -l /opt/pki_rsa/ca-chain.pem

# cat /opt/pki_rsa/ca-chain.pem

7.9.1. 一時 DS 証明書を置き換える (KRA)

KRA をインストールする前に、KRA の Directory Server の公式 SSL サーバー証明書を発行します。これは一時的なブートストラップ証明書を置き換えるためのものです。そのためには、まず Directory Server 証明書の証明書署名要求 (CSR) を作成し、次にこの要求を CA に送信します。

注記

必ず DS サーバーの FQDN (例: cn=rhds11.example.com / host=rhds11.example.com) を使用してください。

実際の DS 証明書の CSR を生成する

rhds11.example.com で、実際の DS 証明書の PKCS10 証明書署名要求を生成します。

  1. DS を停止します。

    Copy to Clipboard Toggle word wrap
    # dsctl slapd-CC-RSA-KRA-LDAP stop
  2. certutil ツールを使用して CSR を生成します。

    Copy to Clipboard Toggle word wrap
    # certutil -R -d /etc/dirsrv/slapd-CC-RSA-KRA-LDAP -s "CN=rhds11.example.com" -g 2048 -f /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/pwdfile.txt -a -o /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/Server-Cert-kra.csr -z /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/noise.txt
    重要

    上記で取得した Server-Cert-kra.csr 出力ファイルを編集して、"Begin Certificate Request" の前の数行を削除します。以下に例を示します。

    Copy to Clipboard Toggle word wrap
    # vi /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/Server-Cert-kra.csr

    CSR ファイルは、"-----BEGIN CERTIFICATE REQUEST-----" の行で始まり、"-----END CERTIFICATE REQUEST-----" の行で終わる必要があります。

  3. Server-Cert-kra.csr ファイルを CA が存在するシステムにリモートコピーします。以下に例を示します。

    Copy to Clipboard Toggle word wrap
    # scp /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/Server-Cert-kra.csr root@rhcs10.example.com:/root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-kra.csr

実際の DS 証明書を発行する

rhcs10.example.com で、実際の SSL サーバー証明書を発行します。

  1. CMC 要求を生成します。

    1. CMCRequest 設定ファイルを作成します。以下に例を示します。

      Copy to Clipboard Toggle word wrap
      # vim /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-kra_pkcs10.cfg
      Copy to Clipboard Toggle word wrap
      ### 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.
      ### For input on a different host, specify where to find the CSR.
      input=/root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-kra.csr
      
      ### output: full path for the CMC request in binary format
      ### For output on a different host, specify the destination.
      output=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-kra_pkcs10.req
      
      ### tokenname: name of the token where the agent signing cert can be found (default is internal)
      tokenname=internal
      
      ### nickname: nickname for the agent certificate that will be used to sign the CMC full request.
      nickname=PKI Bootstrap Administrator for RSA-SubCA
      
      ### dbdir: directory for cert8.db, key3.db and secmod.db
      dbdir=/root/.dogtag/pki_rsa_bootstrap/certs_db
      
      ### password: password for cert8.db that stores the agent certificate
      password=SECret.123
      
      ### format: request format, either pkcs10 or crmf
      format=pkcs10
    2. CMCRequest コマンドを使用してリクエストを生成します。

      Copy to Clipboard Toggle word wrap
      # CMCRequest /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-kra_pkcs10.cfg
      
      cert/key prefix =
      path = /root/.dogtag/pki_rsa_bootstrap/certs_db
      CryptoManger initialized
      token internal logged in...
      got signerCert: PKI Bootstrap Administrator for RSA-SubCA
      createPKIData: begins
      k=0
      createPKIData:  format: pkcs10
      useSharedSecret is false...
      signData: begins:
      getPrivateKey: got signing cert
      signData:  got signer privKey
      createSignedData: begins
      getSigningAlgFromPrivate: begins.
      getSigningAlgFromPrivate: found signingKeyType=RSA
      getSigningAlgFromPrivate: using SignatureAlgorithm: RSASignatureWithSHA256Digest
      createSignedData: digest created for pkidata
      createSignedData: digest algorithm =RSASignatureWithSHA256Digest
      createSignedData: building cert chain
      signData: signed request generated.
      getCMCBlob: begins
      getCMCBlob: generating signed data
      
      The CMC enrollment request in base-64 encoded format:
      
      . . . Output omitted . . .
      
      The CMC enrollment request in binary format is stored in
      /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-kra_pkcs10.req
  2. CMC 要求を送信します。

    1. HttpClient 設定ファイルを作成します。以下に例を示します。

      Copy to Clipboard Toggle word wrap
      # vim /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_dirsrv-kra.cfg
      Copy to Clipboard Toggle word wrap
      ### host: host name for the http server
      host=rhcs10.example.com
      
      ### port: port number
      port=31443
      
      ### 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=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-kra_pkcs10.req
      
      ### output: full path for the response in binary format
      output=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-kra_pkcs10.resp
      
      ### tokenname: name of the token where the 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=/root/.dogtag/pki_rsa_bootstrap/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 cert8.db
      ### This parameter will be ignored if secure=false and clientauth=false
      password=SECret.123
      
      ### nickname: nickname for client certificate
      ### This parameter will be ignored if clientmode=false
      nickname=PKI Bootstrap Administrator for RSA-SubCA
      
      ### servlet: servlet name
      servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCserverCert
    2. HttpClient コマンドを使用して要求を送信します。

      Copy to Clipboard Toggle word wrap
      # HttpClient /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_dirsrv-kra.cfg
      
      Total number of bytes read = 3096
      after SSLSocket created, thread token is NSS FIPS 140-2 User Private Key
      client cert is not null
      handshake happened
      writing to socket
      
      ##Response Headers begin##
      HTTP/1.1 200
      Content-Type: application/pkcs7-mime
      Content-Length: 2492
      Date: Tue, 29 Sep 2020 15:20:21 GMT
      Connection: close
      ##end##
      
      . . . Output omitted . . .
      
      The response in binary format is stored in
      /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-kra_pkcs10.resp
  3. CMC 応答を処理します。

    1. CMCResponse を使用して応答を処理し、チェーン内のすべての証明書を PEM 形式で個別に表示します。

      重要

      "-v" オプションを指定して CMCResponse を実行すると、チェーン内の各証明書の PEM が Cert:0、Cert:1 などとして返されます。この出力では、すべての PEM の下に、チェーン内の各証明書も整った出力形式で表示されます。証明書は決まった順序で表示されないため、チェーン内での位置を確認するには、各 "Certificate" の下にある "Subject:" を確認する必要があります。対応する PEM が上と同じ位置に表示されます。

      Copy to Clipboard Toggle word wrap
      # CMCResponse -d /root/.dogtag/pki_rsa_bootstrap/certs_db -i /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-kra_pkcs10.resp -v
      
      Cert:0
      ...
      ===
      Cert:1
      ...
      ===
      Cert:2
      ...
      ===
      Certificates:
      
        Certificate:
            Data:
                Version:  v3
                Serial Number: 0x34F6548
                Signature Algorithm: SHA256withRSA - 1.2.840.113549.1.1.11
                Issuer: CN=CA Signing Certificate,OU=rhcs10-RSA-SubCA,O=Example-rhcs10-RSA-RootCA
                Validity:
                    Not Before: Monday, September 25, 2023 8:28:24 PM EDT America/New_York
                    Not  After: Sunday, September 14, 2025 8:28:24 PM EDT America/New_York
                Subject: CN=rhds11.example.com
      
      . . . Output omitted . . .
      
          Certificate:
              Data:
                  Version:  v3
                  Serial Number: 0x66AA3D5
                  Signature Algorithm: SHA256withRSA - 1.2.840.113549.1.1.11
                  Issuer: CN=CA Signing Certificate,OU=rhcs10-RSA-RootCA,O=Example-rhcs10-RSA-RootCA
                  Validity:
                      Not Before: Friday, September 15, 2023 3:22:33 PM EDT America/New_York
                      Not  After: Tuesday, September 15, 2043 3:22:33 PM EDT America/New_York
                  Subject: CN=CA Signing Certificate,OU=rhcs10-RSA-RootCA,O=Example-rhcs10-RSA-RootCA
      
      
      . . . Output omitted . . .
      
          Certificate:
              Data:
                  Version:  v3
                  Serial Number: 0xABA9C22
                  Signature Algorithm: SHA256withRSA - 1.2.840.113549.1.1.11
                  Issuer: CN=CA Signing Certificate,OU=rhcs10-RSA-RootCA,O=Example-rhcs10-RSA-RootCA
                  Validity:
                      Not Before: Tuesday, September 19, 2023 3:55:59 PM EDT America/New_York
                      Not  After: Friday, September 19, 2042 3:55:59 PM EDT America/New_York
                  Subject: CN=CA Signing Certificate,OU=rhcs10-RSA-SubCA,O=Example-rhcs10-RSA-RootCA
      
      
      . . . Output omitted . . .
      
      Number of controls is 1
      Control #0: CMCStatusInfoV2
      OID: {1 3 6 1 5 5 7 7 25}
      BodyList: 1
      Status: SUCCESS
      CMC Full Response.
    2. 新しい Server-Cert DS 証明書を、適切な名前でブートストラップ証明書ディレクトリー (例: /root/.dogtag/pki_rsa_bootstrap/certs_db/) 内のファイルに保存します。.pem ファイルは、ヘッダー -----BEGIN CERTIFICATE----- で開始し、フッター -----END CERTIFICATE----- で終了する必要があります。以下に例を示します。

      Copy to Clipboard Toggle word wrap
      # vi /root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-kra.pem

      この場合の Server-Cert-kra.pem は、KRA の内部データベースとして機能する Directory Server インスタンスの新しい Server-Cert 証明書です。

      注記

      RootCA の署名証明書は、次のコマンドからの出力と一致する必要があります。

      Copy to Clipboard Toggle word wrap
      # certutil -L -d /var/lib/pki/rhcs10-RSA-RootCA/alias/ -n "CA Signing Cert - rhcs10-RSA-RootCA" -a
  4. 新しい Server-Cert 証明書を rhds11.example.com にリモートコピーします。以下に例を示します。

    Copy to Clipboard Toggle word wrap
    # scp /root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-kra.pem root@rhds11.example.com:/etc/dirsrv/slapd-CC-RSA-KRA-LDAP/

一時 DS 証明書を置き換える

rhds11.example.com で、一時的な DS 証明書を実際の DS 証明書に置き換えます。

  1. dirsrv ディレクトリーの内容をバックアップディレクトリーに保存します。

    Copy to Clipboard Toggle word wrap
    # cp -r /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/ /etc/dirsrv/save-rsa/slapd-CC-RSA-KRA-LDAP/
  2. 古い DS 証明書を削除します。

    Copy to Clipboard Toggle word wrap
    # certutil -D -d /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/pwdfile.txt -n "Server-Cert"
    Copy to Clipboard Toggle word wrap
    # certutil -D -d /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/pwdfile.txt -n "Self-Signed-CA"
  3. 新しく作成した DS 証明書とそのチェーン内の CA 証明書を 1 つずつインポートします。以下に例を示します。

    Copy to Clipboard Toggle word wrap
    # certutil -d /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/pwdfile.txt -A -t "CT,C,C" -n "CA Signing Cert - rhcs10-RSA-RootCA" -i /opt/pki_rsa/rootCA.pem
    Copy to Clipboard Toggle word wrap
    # certutil -d /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/pwdfile.txt -A -t "CT,C,C" -n "CA Signing Cert - rhcs10-RSA-SubCA" -i /opt/pki_rsa/subCA.pem
    Copy to Clipboard Toggle word wrap
    # certutil -d /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/pwdfile.txt -A -t "u,u,u" -n "Server-Cert" -i /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/Server-Cert-kra.pem
  4. 証明書をリスト表示します。

    Copy to Clipboard Toggle word wrap
    # certutil -L -d /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/
    
    Certificate Nickname                           Trust Attributes
                                                   SSL,S/MIME,JAR/XPI
    CA Signing Cert - rhcs10-RSA-RootCA            CT,C,C
    CA Signing Cert - rhcs10-RSA-SubCA             CT,C,C
    Server-Cert                                    u,u,u
  5. DS を起動します。

    Copy to Clipboard Toggle word wrap
    # dsctl slapd-CC-RSA-KRA-LDAP start
  6. LDAP サーバーが稼働していることをテストして確認します (別のシステムの場合は、CA ホストでもテストします)。

    Copy to Clipboard Toggle word wrap
    # ldapsearch -x -D "cn=Directory Manager" -H ldaps://rhds11.example.com:22636 -b "dc=example,dc=com" -w SECret.123

    別のシステムでテストする場合は、次のように CA 証明書チェーンを ldapsearch コマンドの前に追加します。

    Copy to Clipboard Toggle word wrap
    # LDAPTLS_CACERT=/opt/pki_rsa/ca-chain.pem ldapsearch -x -D "cn=Directory Manager" -H ldaps://rhds11.example.com:22636 -b "dc=example,dc=com" -w SECret.123

7.9.2. KRA インスタンスのインストール

KRA をインストールするには、シングルステップメソッドまたはツーステップメソッドの いずれか 1 つ を使用します。次の手順では、シングルステップ方式を説明します。ツーステップ方式を使用してインストールする場合は、] および xref:_rootca_two_step[ を参照してください。

重要

AIA 拡張が CA の内部 OCSP ではなく外部 OCSP インスタンスを指すようにする場合は、KRA をインストールする前に 「この OCSP を指すようにデフォルトの AIA 拡張機能を設定します」 の手順に従ってください。

前提条件

手順

  1. 選択した場所 (例: /root/pki_rsa) に KRA インストールファイルを作成します。

    Copy to Clipboard Toggle word wrap
    # cd /root/pki_rsa
    Copy to Clipboard Toggle word wrap
    # vi kra_inst.cfg
    注記

    明示的に指定されていない限り、システム証明書のニックネームは、pki_instance_name に指定された値を使用して自動的に名前が付けられます。共有 HSM での証明書のニックネームの競合を回避するには、インスタンスを作成するたびに一意のインスタンス名を使用します。

    以下のインストールファイルでは、例となる値を指定しています。HSM パスワードの変更に加えて、たとえばポート、ディレクトリー、ニックネーム、ドメインなどの値を適宜変更します。

    Copy to Clipboard Toggle word wrap
    [DEFAULT]
    pki_instance_name=rhcs10-RSA-KRA
    pki_https_port=28443
    pki_http_port=28080
    
    ### Crypto Token
    pki_hsm_enable=True
    pki_hsm_libfile=/opt/nfast/toolkits/pkcs11/libcknfast.so
    pki_hsm_modulename=nfast
    pki_token_name=NHSM-CONN-XC
    pki_token_password=<YourHSMpassword>
    
    pki_audit_signing_token=NHSM-CONN-XC
    pki_audit_signing_key_algorithm=SHA256withRSA
    pki_audit_signing_key_size=2048
    pki_audit_signing_key_type=rsa
    pki_audit_signing_signing_algorithm=SHA256withRSA
    
    pki_subsystem_token=NHSM-CONN-XC
    pki_subsystem_key_algorithm=SHA256withRSA
    pki_subsystem_signing_algorithm=SHA256withRSA
    pki_subsystem_key_size=2048
    pki_subsystem_key_type=rsa
    
    pki_sslserver_token=NHSM-CONN-XC
    pki_sslserver_key_algorithm=SHA256withRSA
    pki_sslserver_signing_algorithm=SHA256withRSA
    pki_sslserver_key_size=2048
    pki_sslserver_key_type=rsa
    
    ### CA cert chain concatenated in PEM format
    pki_cert_chain_path=/opt/pki_rsa/ca-chain.pem
    
    ### Bootstrap Admin
    pki_admin_password=SECret.123
    pki_admin_key_type=rsa
    pki_admin_key_size=2048
    pki_admin_key_algorithm=SHA256withRSA
    
    ### Bootstrap Admin client dir
    pki_client_admin_cert_p12=/opt/pki_rsa/rhcs10-RSA-KRA/kra_admin_cert.p12
    pki_client_database_dir=/opt/pki_rsa/rhcs10-RSA-KRA/certs_db
    pki_client_database_password=SECret.123
    pki_client_database_purge=False
    pki_client_dir=/opt/pki_rsa/rhcs10-RSA-KRA
    pki_client_pkcs12_password=SECret.123
    
    ### Internal LDAP
    pki_ds_bind_dn=cn=Directory Manager
    pki_ds_ldap_port=22389
    pki_ds_ldaps_port=22636
    pki_ds_password=SECret.123
    pki_ds_remove_data=True
    pki_ds_secure_connection=True
    pki_ds_secure_connection_ca_pem_file=/opt/pki_rsa/ca-chain.pem
    pki_ds_secure_connection_ca_nickname=CA Signing Cert - rhcs10-RSA-SubCA
    
    ### Security Domain
    pki_security_domain_hostname=rhcs10.example.com
    pki_security_domain_https_port=31443
    pki_security_domain_password=SECret.123
    pki_security_domain_user=caadmin
    
    
    [Tomcat]
    pki_ajp_port=28009
    pki_tomcat_server_port=28005
    
    [KRA]
    pki_import_admin_cert=False
    
    pki_storage_token=NHSM-CONN-XC
    pki_storage_key_algorithm=SHA256withRSA
    pki_storage_key_size=2048
    pki_storage_key_type=rsa
    pki_storage_signing_algorithm=SHA256withRSA
    
    pki_transport_token=NHSM-CONN-XC
    pki_transport_key_algorithm=SHA256withRSA
    pki_transport_key_size=2048
    pki_transport_key_type=rsa
    pki_transport_signing_algorithm=SHA256withRSA
    
    pki_admin_nickname=PKI Bootstrap Administrator for RSA-KRA
    pki_admin_name=kraadmin
    pki_admin_uid=kraadmin
    pki_admin_email=kraadmin@example.com
    
    pki_ds_hostname=rhds11.example.com
    pki_ds_base_dn=dc=RSA-KRA
    pki_ds_database=CC-RSA-KRA-LDAP
    pki_share_db=False
  2. pkispawn ツールを実行して、KRA サブシステムをインストールします。

    Copy to Clipboard Toggle word wrap
    # pkispawn -s KRA -f kra_inst.cfg --debug

    これにより、KRA インスタンスが /var/lib/pki/rhcs10-RSA-KRA に作成されます。

注記

この KRA をツーステップ方法を使用してインストールする場合は、以下を実行します。

  1. まず、--skip-configuration オプションを指定して pkispawn ツールを実行し、RHCS KRA インスタンスをインストールします。

    Copy to Clipboard Toggle word wrap
    # pkispawn -s KRA -f kra_inst.cfg --skip-configuration --debug
  2. 2 つのインストールステップの間に設定ファイルをカスタマイズします。
  3. KRA を設定するには、pkispawn ツールを実行します。

    Copy to Clipboard Toggle word wrap
    # pkispawn -s KRA -f kra_inst.cfg --skip-installation --debug

検証

  1. インストールされている KRA インスタンスのステータスを表示します。

    Copy to Clipboard Toggle word wrap
    # pki-server status rhcs10-RSA-KRA

    Secure Agent、Admin、および pkiconsole の URL を書き留めます。

  2. KRA エージェントの Web ページにアクセスできることを確認します。
  3. KRA ブートストラップ管理者証明書を nssdb にインポートします。

    Copy to Clipboard Toggle word wrap
    # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db client-cert-import --pkcs12 /opt/pki_rsa/rhcs10-RSA-KRA/kra_admin_cert.p12 --pkcs12-password SECret.123
  4. kra-key-request-find コマンドを実行して、KRA の健全性を確認します。証明書が表示されるはずです。

    Copy to Clipboard Toggle word wrap
    # pki -p 28443 -d /root/.dogtag/pki_rsa_bootstrap/certs_db -n “PKI Bootstrap Administrator for RSA-KRA” kra-key-request-find
注記

実際のキーのアーカイブおよび回復テストは、次のサブセクションで説明するセットアップ手順を完了した後にのみ実行できます。

7.9.3. KRA の OAEP サポートを設定する

OAEP (Optimal Asymmetric Encryption Padding) キー転送アルゴリズムを使用するように KRA を設定するには、KRA の CS.cfg 設定ファイルを編集します。

注記

このセクションは、ファームウェア v12.72.1 を備えた Entrust nShield Connect XC ユニットなど、AES キーのラッピング/アンラッピングをサポートする HSM を対象としています。

前提条件

  • root ユーザーとして rhcs10.example.com にログインしている。

手順

  1. KRA を停止します。

    Copy to Clipboard Toggle word wrap
    # pki-server stop rhcs10-RSA-KRA
  2. /var/lib/pki/rhcs10-RSA-KRA/kra/conf/CS.cfg 設定ファイルを編集し、次の 3 行を追加します。

keyWrap.useOAEP=true
kra.legacyPKCS12=false
kra.nonLegacyAlg=AES/None/PKCS5Padding/Kwp/256

  1. KRA を起動します。

    Copy to Clipboard Toggle word wrap
    # pki-server start rhcs10-RSA-KRA
  2. SubCA を再起動します。

    Copy to Clipboard Toggle word wrap
    # pki-server restart rhcs10-RSA-SubCA

7.9.4. KRA ロールユーザーの作成

7.9.5. キーアーカイブのテスト

この例は、KRA で秘密鍵をアーカイブして、pki ロール特権のない通常のユーザーが、証明書登録要求を作成して自動的に発行 (= 自己署名 CMC 登録) する方法を示しています。

重要

] および xref:_install_add-issuance-protection-certificate[ の手順に従い、SubCA が自己署名付き CMC 登録を処理するように設定されていることを確認してください。

必要な設定

まだ行っていない場合は、「CMC 共有トークンをテストする」 の手順に従ってテストユーザー (この例では FooUser123) の共有シークレットを設定します。

手順

この手順では、通常の (pki-role 以外の) ユーザー ( FooUser123 など) が自己署名 CMC 証明書を登録するための実行手順を説明します。これは、FooUser123 のホームディレクトリーのいずれか ( /home/FooUser123/certs_db など) で実行できます。

  1. クライアント nssdb がまだ存在しない場合は、作成します。

    Copy to Clipboard Toggle word wrap
    $ pki -d /home/FooUser123/certs_db -c SECret.123 client-init
  2. KRA トランスポート証明書を使用して CRMF 要求を作成します。

    1. SubCA の EE ページ (この例では 0x555251b) で KRA トランスポート証明書のシリアル番号を見つけます。
      または、証明書の共通名がわかっている場合は、そのシリアル番号を見つけることもできます。次に例を示します。

      Copy to Clipboard Toggle word wrap
      # pki -p 31443 ca-cert-find --name "DRM Transport Certificate"
      ---------------
      1 entries found
      ---------------
       Serial Number: 0x555251b
       Subject DN: CN=DRM Transport Certificate,OU=rhcs10-RSA-KRA,O=Example-rhcs10-RSA-KRA
       Status: VALID
      ...
      ----------------------------
      Number of entries returned 1
      ----------------------------
    2. このシリアル番号を使用して KRA トランスポート証明書をエクスポートします。

      Copy to Clipboard Toggle word wrap
      # pki -d /home/FooUser123/certs_db -c SECret.123 -p 31443 ca-cert-export 0x555251b --output-file /home/FooUser123/certs_db/kra_transport.txt
    3. トランスポート証明書を使用して CRMF 要求を作成します。

      Copy to Clipboard Toggle word wrap
      # CRMFPopClient -d /home/FooUser123/certs_db -p SECret.123 -n "cn=FooUser123, uid=FooUser123" -q POP_SUCCESS -b /home/FooUser123/certs_db/kra_transport.txt -w "AES KeyWrap/Wrapped" -y -o /home/FooUser123/certs_db/crmf.req -oaep
      
      CryptoUtil: generateRSAKeyPair: calling kg.setKeyPairUsages
      Keypair private key id: 56906e65ef43a2e756908726758e9061d8d7ee9c
      CRMFPopClient: use_shared_secret true. Generating SubjectKeyIdentifier extension.
      Storing CRMF request into /home/FooUser123/certs_db/crmf.req
      Storing CRMF request key id into /home/FooUser123/certs_db/crmf.req.keyId
  3. CMC 要求を生成します。

    1. 前のステップで取得した CRMF 要求と秘密鍵 ID を使用して、CMCRequest 設定ファイルを作成します。以下に例を示します。

      Copy to Clipboard Toggle word wrap
      # vi /home/FooUser123/certs_db/cmc-crmf-self.cfg
      Copy to Clipboard Toggle word wrap
      ### 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=/home/FooUser123/certs_db/crmf.req
      
      ### output: full path for the CMC request in binary format
      output=/home/FooUser123/certs_db/cmc.self.req
      
      ### tokenname: name of the token where agent signing cert can be found (default is internal)
      tokenname=internal
      request.useSharedSecret=true
      
      ### nickname: nickname for the agent certificate which will be used to sign the CMC full request.
      #nickname=
      
      ### dbdir: directory for cert8.db, key3.db and secmod.db
      dbdir=/home/FooUser123/certs_db
      
      ### password: password for cert8.db which stores the agent certificate
      password=SECret.123
      
      ### format: request format, either pkcs10 or crmf
      format=crmf
      
      ### identityProofV2.enable: if true, then the request will contain this control. Otherwise, false.
      ### Note that if both identityProof and identityProofV2 are enabled,
      ### identityProofV2 takes precedence; Only one of them can be active at a time
      ### Supported hashAlg are:
      ### SHA-256, SHA-384, and SHA-512
      ### Supported macAlg are:
      ### SHA-256-HMAC, SHA-384-HMAC, and SHA-512-HMAC
      identityProofV2.enable=true
      identityProofV2.hashAlg=SHA-512
      identityProofV2.macAlg=SHA-256-HMAC
      
      ### identityProofV2.sharedSecret: Shared Secret
      witness.sharedSecret=secretShrTokFooUser123
      
      popLinkWitnessV2.enable=true
      popLinkWitnessV2.keyGenAlg=SHA-256
      popLinkWitnessV2.macAlg=SHA-256-HMAC
      
      request.privKeyId=<output from PKCS10Client|CRMFPopClient xxx.priv>
      
      ### identification works with identityProofV2
      identification.enable=true
      identification=FooUser123
    2. CMCRequest コマンドを使用してリクエストを生成します。

      Copy to Clipboard Toggle word wrap
      # CMCRequest /home/FooUser123/certs_db/cmc-crmf-self.cfg
      
      cert/key prefix =
      path = /home/FooUser123/certs_db
      CryptoManger initialized
      token internal logged in...
      got request privKeyId: 56906e65ef43a2e756908726758e9061d8d7ee9c
      got private key
      createPKIData: begins
      createPopLinkWitnessV2Attr: begins
      createPopLinkWitnessV2Attr: keyGenAlg=SHA-256; macAlg=SHA-256-HMAC
      createPopLinkWitnessV2Attr: Successfully created id_cmc_idPOPLinkRandom control. bpid = 1
      createPopLinkWitnessV2Attr: Successfully created PopLinkWitnessV2 control.
      createPopLinkWitnessV2Attr: returning...
      
      k=0
      createPKIData:  format: crmf
      CryptoUtil: getSKIExtensionFromCertTemplate: SKIoid == jssOID
      createPKIData:  SubjectKeyIdentifier extension found in use_shared_secret request
      createPKIData: popLinkWitnessV2 enabled. reconstructing crmf
      createNewPOP: begins
      createNewPOP: about to create POPOSigningKey
      createNewPOP: creating and returning newPopOfSigningKey
      createPKIData: new CRMF b64encode completes.
      -----BEGIN CERTIFICATE REQUEST-----
      MIIIsDCCCKwwggeQAgEBMIIBfYABAqUzMDExGjAYBgoJkiaJk/IsZAEBEwpGb29Vc2VyMTIzMRMw
      
      . . . Output omitted . . .
      
      -----END CERTIFICATE REQUEST-----
      
      identification control: identification =FooUser123
      Successfully create identification control. bpid = 1
      
      CMCRequest: addIdentityProofV2Attr: hashAlg=SHA-512; macAlg=SHA-256-HMAC
      Identity Proof V2 control:
         Value: -50 -36 103 -38 70 85 70 91 -71 96 -121 100 -127 50 -63 -57 123 -30 115 58 -55 -34 -22 104 90 -20 48 46 80 -85 64 68
      Successfully create identityProofV2 control. bpid = 2
      
      useSharedSecret is true...
      signData for useSharedSecret begins: begins:
      createSignedData: begins
      getSigningAlgFromPrivate: begins.
      getSigningAlgFromPrivate: found signingKeyType=RSA
      getSigningAlgFromPrivate: using SignatureAlgorithm: RSASignatureWithSHA256Digest
      createSignedData: digest created for pkidata
      createSignedData: digest algorithm =RSASignatureWithSHA256Digest
      getCMCBlob: begins
      getCMCBlob: generating signed data
      
      The CMC enrollment request in base-64 encoded format:
      MIILlAYJKoZIhvcNAQcCoIILhTCCC4ECAQMxDzANBglghkgBZQMEAgEFADCCCdgGCCsGAQUFBwwC
      
      . . . Output omitted . . .
      
      The CMC enrollment request in binary format is stored in /home/FooUser123/certs_db/cmc.self.req
  4. CMC 要求を送信します。

    1. HttpClient 設定ファイルを作成します。以下に例を示します。

      Copy to Clipboard Toggle word wrap
      # vim /home/FooUser123/certs_db/HttpClient-cmc-crmf.self.cfg
      Copy to Clipboard Toggle word wrap
      ### host: host name for the http server
      host=rhcs10.example.com
      
      ### port: port number
      port=31443
      
      ### 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/FooUser123/certs_db/cmc.self.req
      
      ### output: full path for the response in binary format
      output=/home/FooUser123/certs_db/cmc.self.Resp
      
      ### tokenname: name of the token where the 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=/home/FooUser123/certs_db
      
      ### clientmode: true for client authentication, false for no client authentication
      ### This parameter will be ignored if secure=false
      clientmode=false
      
      ### password: password for cert8.db
      ### This parameter will be ignored if secure=false and clientauth=false
      password=SECret.123
      
      ### nickname: nickname for client certificate
      ### This parameter will be ignored if clientmode=false
      nickname=
      
      ### servlet: servlet name
      servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caFullCMCSharedTokenCert
    2. HttpClient コマンドを使用して要求を送信します。

      Copy to Clipboard Toggle word wrap
      # HttpClient /home/FooUser123/certs_db/HttpClient-cmc-crmf.self.cfg
      
      Total number of bytes read = 2968
      after SSLSocket created, thread token is NSS FIPS 140-2 User Private Key
      handshake happened
      writing to socket
      
      #Response Headers begin
      HTTP/1.1 200
      Content-Type: application/pkcs7-mime
      Content-Length: 4348
      Date: Thu, 08 Sep 2022 20:51:44 GMT
      Connection: close
      #end
      
      Total number of bytes read = 4348
      MIIQ+AYJKoZIhvcNAQcCoIIQ6TCCEOUCAQMxDzANBglghkgBZQMEAgEFADAxBggrBgEFBQcMA6Al
      
      . . . Output omitted . . .
      
      The response in binary format is stored in /home/FooUser123/certs_db/cmc.self.Resp
  5. CMCResponse コマンドを使用して応答を処理します。

    Copy to Clipboard Toggle word wrap
    # CMCResponse -d /home/FooUser123/certs_db -i /home/FooUser123/certs_db/cmc.self.Resp
    
    Certificates:
        Certificate:
            Data:
                Version:  v3
                Serial Number: 0x98D0212
                Signature Algorithm: SHA256withRSA - 1.2.840.113549.1.1.11
                Issuer: CN=CA Signing Certificate,OU=rhcs10-RSA-SubCA,O=Example-rhcs10-RSA-RootCA
                Validity:
                    Not Before: Thursday, September 8, 2022 4:51:44 PM EDT America/New_York
                    Not  After: Tuesday, March 7, 2023 4:51:44 PM EST America/New_York
                Subject: UID=FooUser123,DC=example,DC=com
                Subject Public Key Info:
                    Algorithm: RSA - 1.2.840.113549.1.1.1
                    Public Key:
                        Exponent: 65537
                        Public Key Modulus: (2048 bits) :
                            BB:F3:C6:66:AC:9E:39:02:59:B8:E7:5A:6D:9E:29:8C:
    
    . . . Output omitted . . .
    
    Number of controls is 1
    Control #0: CMCStatusInfoV2
       OID: {1 3 6 1 5 5 7 7 25}
       BodyList: 1
       Status: SUCCESS
    CMC Full Response.

検証:

  • KRA UI の正常性を確認するには、KRA エージェントページにアクセスして、要求タイプとして Show key archival requests を、ステータスとして Show completed requests を選択して、要求を表示します。これにより、CN = FooUser123、UID=FooUser123 のアーカイブされたキー情報が表示されます。

7.9.6. キーの復元をテストします

次の手順でキーの復元プロセスをテストします。

  1. KRA エージェントとして、ブラウザーの KRA のエージェントサービスページに移動し、キーの復元 リンクをクリックします。
  2. 証明書でキーを検索するには、証明書 チェックボックスをオンにします。

    1. 以前の応答ファイルを解析して、リーフ証明書を base64 形式で表示します。次に例を示します。

      Copy to Clipboard Toggle word wrap
      # CMCResponse -d /home/FooUser123/certs_db -i /home/FooUser123/certs_db/cmc.self.Resp -v
    2. base64 でエンコードされたリーフ証明書をコピーしてテキストフィールドに貼り付け (例: cert0 : 証明書の "Subject" が UID=FooUser123,DC=example,DC=com であることを確認)、Show Key で検証します。
  3. Recover をクリックします。リカバリーの実行中にブラウザーセッションが閉じられるように Async Recovery チェックボックスが選択されていることを確認してください。

    注記

    非同期リカバリーは、デフォルトのキーを復元する方法です。同期キーリカバリーはサポートされなくなりました。

  4. Recover をクリックします。エージェントスキームに応じて、指定された数のエージェントがこの鍵のリカバリーを承認する必要があります。エージェントに、リカバリーキーを検索してもらい、開始された回復を承認してもらいます。
  5. すべてのエージェントが回復を承認したら、エージェントページの左側で List Requests を選択し、Request type show key recovery requests および Request status show all requests を選択します。
  6. 承認された回復要求に対応する要求番号をクリックし、要求されるとおり PKCS #12 パスワードを 2 回入力して、Retrieve PKCS#12 をクリックします。
  7. ダイアログがポップアップします。Save File をクリックして、秘密鍵証明書の所有者の PKCS#12 ファイルをダウンロードします。
  8. PKCS#12 ファイルを受け取った後に証明書/キーの所有者は、Firefox nssdb にキーを復元できます。以下に例を示します。

    Copy to Clipboard Toggle word wrap
    # pk12util -d ~/.mozilla/firefox/’1234gggg.Default User’ -n "FooUser123 cert" -i getAsyncPk12
  9. これで、証明書を再び使用できます。

7.9.7. KRA pkiconsole タイムアウトを増やします

  1. KRA を停止します。

    Copy to Clipboard Toggle word wrap
    # pki-server stop rhcs10-RSA-KRA
  2. /var/lib/pki/rhcs10-RSA-KRA/conf/server.xml ファイルを編集して、タイムアウト期間を増やします。

    Copy to Clipboard Toggle word wrap
    <Connector name="Secure" port="28443" …
    connectionTimeout="3000000"
  3. 次に、KRA を再起動します。

    Copy to Clipboard Toggle word wrap
    # pki-server start rhcs10-RSA-KRA

7.9.8. クライアント認証を使用して KRA pkiconsole にログインします

  1. KRA を authType=sslclientauth で設定し、「クライアント認証を使用した pkiconsole ログイン設定」 に記載された手順でロールユーザー証明書をインポートします。
  2. ロールユーザーのクライアント認証証明書を使用して pkiconsole にログインします。

    Copy to Clipboard Toggle word wrap
    # pkiconsole -d <home .redhat-idm-console dir> -n <client cert> https://rhcs10.example.com:28443/kra

    そして、リストからロールユーザー証明書のニックネームを選択します (例: KRA adminV)。コンソールへのログインは成功するはずです。

7.9.9. インストール後の設定

追加の RHCS インスタンスをインストールする場合は、次のセクションに進んでください。必要なすべての RHCS インスタンスのインストールが完了したら、「インストール後の設定」 にアクセスして追加セットアップを完了します。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat, Inc.