検索
サポートコンソール開発者トライアルの開始お問い合わせ

5.2. 証明書署名リクエストの作成

download PDF
従来は、証明書要求 (CSR) の生成には以下の方法が使用されます。
  • コマンドラインユーティリティーを使用した CSR の生成
  • 補助ブラウザー内での CSR の生成
  • サーバーのインストーラーなど、アプリケーション内での CSR の生成
これらの方法の一部は CSR の直接送信をサポートしますが、含まれない場合があります。
RHCS 9.7 以降、サーバー側のキー生成がサポートされ、Firefox v69 以降や Chrome などの新しいバージョンのブラウザー内でのキー生成サポートの削除によってもたらされる不便を克服します。このため、本セクションでは、キー生成のブラウザーサポートについて説明しません。これらのブラウザーの古いバージョンが古い RHCS ドキュメントで指定されているように機能し続けるべきではないと信じる理由はありませんが。
通常、アプリケーションから生成された CSR は PKCS#10 の形式を取ります。それらが正しく生成されると、RHCS によりサポートされるはずです。
次のサブセクションでは、RHCS でサポートされている次の方法を説明します。
  • コマンドラインユーティリティー
  • サーバー側の鍵生成

5.2.1. コマンドラインユーティリティーを使用した CSR の生成

Red Hat Certificate System は、以下のユーティリティーを使用した CSR の作成をサポートします。
  • certutil: PKCS #10 リクエストの作成に対応します。
  • PKCS10Client: PKCS #10 リクエストの作成に対応します。
  • CRMFPopClient: CRMF 要求の作成をサポートします。
  • pki client-cert-request: PKCS#10 および CRMF リクエストの両方をサポートします。
次のセクションでは、これらのユーティリティーを機能豊富な登録プロファイルフレームワークで使用する方法の例をいくつか示します。

5.2.1.1. certutil を使用した CSR の作成

本セクションでは、certutil ユーティリティーを使用して CSR を作成する方法を説明します。
certutil の使用の詳細は、以下を参照してください。
  • certutil(1) の man ページを参照してください。
  • certutil --help コマンドの出力
5.2.1.1.1. certutil を使用した EC キーで CSR の作成
以下の手順は、certutil ユーティリティーを使用して Elliptic Curve(EC) キーペアと CSR を作成する方法を示しています。
  1. 証明書が要求されるユーザーまたはエンティティーの証明書データベースディレクトリーに移動します。以下に例を示します。 
    $ cd /user_or_entity_database_directory/
  2. バイナリー CSR を作成し、これを /user_or_entity_database_directory/request.csr ファイルに保存します。 
    $ certutil -d . -R -k ec -q nistp256 -s "CN=subject_name" -o /user_or_entity_database_directory/request-bin.csr
    プロンプトが表示されたら、必要な NSS データベースのパスワードを入力します。
    パラメーターの詳細は、certutil(1) の man ページを参照してください。
  3. 作成したバイナリー形式の CSR を PEM 形式に変換します。 
    $ BtoA /user_or_entity_database_directory/request-bin.csr /user_or_entity_database_directory/request.csr
  4. 必要に応じて、CSR ファイルが正しいことを確認します。 
    $ cat /user_or_entity_database_directory/request.csr

		MIICbTCCAVUCAQAwKDEQMA4GA1UEChMHRXhhbXBsZTEUMBIGA1UEAxMLZXhhbXBs
		...
    これは、PKCS#10 PEM 証明書要求です。
5.2.1.1.2. certutil を使用したユーザー定義拡張による CSR の作成
以下の手順は、certutil ユーティリティーを使用してユーザー定義の拡張で CSR を作成する方法を示しています。
登録要求は、CA で定義された登録プロファイルにより制限されることに注意してください。???を参照してください。
  1. 証明書が要求されるユーザーまたはエンティティーの証明書データベースディレクトリーに移動します。以下に例を示します。 
    $ cd /user_or_entity_database_directory/
  2. ユーザー定義の Extended Key Usage 拡張とユーザー定義の Key Usage 拡張で CSR を作成し、これを /user_or_entity_database_directory/request.csr ファイルに保存します。 
    $ certutil -d . -R -k rsa -g 1024 -s "CN=subject_name" --keyUsage keyEncipherment,dataEncipherment,critical --extKeyUsage timeStamp,msTrustListSign,critical -a -o /user_or_entity_database_directory/request.csr
    プロンプトが表示されたら、必要な NSS データベースのパスワードを入力します。
    パラメーターの詳細は、certutil(1) の man ページを参照してください。
  3. 必要に応じて、CSR ファイルが正しいことを確認します。 
    $ cat /user_or_entity_database_directory/request.csr
		Certificate request generated by NSS certutil
		Phone: (not specified)

		Common Name: user 4-2-1-2
		Email: (not specified)
		Organization: (not specified)
		State: (not specified)
		Country: (not specified)
    これは、PKCS#10 PEM 証明書要求です。

5.2.1.2. PKCS10Client を使用した CSR の作成

本セクションでは、PKCS10Client ユーティリティーを使用して CSR を作成する方法を説明します。
PKCS10Client の使用に関する詳細は、以下を参照してください。
  • PKCS10Client(1) の man ページを参照してください。
  • PKCS10Client --help コマンドの出力
5.2.1.2.1. PKCS10Client を使用した CSR の作成
以下の手順では、PKCS10Client ユーティリティーを使用して Elliptic Curve (EC) キーペアと CSR を作成する方法を説明します。
  1. 証明書が要求されるユーザーまたはエンティティーの証明書データベースディレクトリーに移動します。以下に例を示します。 
    $ cd /user_or_entity_database_directory/
  2. CSR を作成し、これを /user_or_entity_database_directory/request.csr ファイルに保存します。 
    $ PKCS10Client -d . -p NSS_password -a ec -c nistp256 -o /user_or_entity_database_directory/example.csr -n "CN=subject_name"
    パラメーターの詳細は、PKCS10Client(1) の man ページを参照してください。
  3. 必要に応じて、CSR ファイルが正しいことを確認します。 
    $ cat /user_or_entity_database_directory/example.csr
		-----BEGIN CERTIFICATE REQUEST-----
		MIICzzCCAbcCAQAwgYkx
		...
		-----END CERTIFICATE REQUEST-----
5.2.1.2.2. PKCS10Client を使用した SharedSecret ベースの CMC の CSR の作成
以下の手順では、PKCS10Client ユーティリティーを使用して、SharedSecret ベースの CMC 用の RSA 鍵ペアと CSR を作成する方法を説明します。これは、デフォルトでは caFullCMCSharedTokenCert プロファイルおよび caECFullCMCSharedTokenCert プロファイルによって処理される CMC 共有 Secret 認証方法にのみ使用します。
  1. 証明書が要求されるユーザーまたはエンティティーの証明書データベースディレクトリーに移動します。以下に例を示します。 
    $ cd /user_or_entity_database_directory/
  2. CSR を作成し、これを /user_or_entity_database_directory/request.csr ファイルに保存します。 
    $ PKCS10Client -d . -p NSS_password -o /user_or_entity_database_directory/example.csr -y true -n "CN=subject_name"
    パラメーターの詳細は、PKCS10Client(1) の man ページを参照してください。
  3. 必要に応じて、CSR ファイルが正しいことを確認します。 
    $ cat /user_or_entity_database_directory/example.csr
		-----BEGIN CERTIFICATE REQUEST-----
		MIICzzCCAbcCAQAwgYkx
		...
		-----END CERTIFICATE REQUEST-----

5.2.1.3. CRMFPopClient を使用した CSR の作成

Certificate Request Message Format (CRMF) は、CMC で受け入れられている CSR 形式であり、主要なアーカイブ情報を要求に安全に埋め込むことができます。
本セクションでは、CRMFPopClient ユーティリティーを使用して CSR を作成する方法を説明します。
CRMFPopClient の詳細な使用方法は、CRMFPopClient(1) の man ページを参照してください。
5.2.1.3.1. CRMFPopClient を使用したキー Archival を持つ CSR の作成
以下の手順では、CRMFPopClient ユーティリティーを使用して RSA キーペアと、鍵アーカイブオプションで CSR を作成する方法を説明します。
  1. 証明書が要求されるユーザーまたはエンティティーの証明書データベースディレクトリーに移動します。以下に例を示します。 
    $ cd /user_or_entity_database_directory/
  2. KRA トランスポート証明書を取得します。 
    $ pki ca-cert-find --name "DRM Transport Certificate"
		---------------
		1 entries found
		---------------
			Serial Number: 0x7
			Subject DN: CN=DRM Transport Certificate,O=EXAMPLE
			Status: VALID
			Type: X.509 version 3
			Key A    lgorithm: PKCS #1 RSA with 2048-bit key
			Not Valid Before: Thu Oct 22 18:26:11 CEST 2015
			Not Valid After: Wed Oct 11 18:26:11 CEST 2017
			Issued On: Thu Oct 22 18:26:11 CEST 2015
			Issued By: caadmin
		----------------------------
		Number of entries returned 1
  3. KRA トランスポート証明書をエクスポートします。 
    $ pki ca-cert-show 0x7 --output kra.transport
  4. CSR を作成し、これを /user_or_entity_database_directory/request.csr ファイルに保存します。 
    $ CRMFPopClient -d . -p password -n "cn=subject_name" -q POP_SUCCESS -b kra.transport -w "AES/CBC/PKCS5Padding" -v -o /user_or_entity_database_directory/example.csr
    Elliptic Curve (EC) キーペアと CSR を作成するには、-a ec -t false オプションをコマンドに渡します。
    パラメーターの詳細は、CRMFPopClient(1) の man ページを参照してください。
  5. 必要に応じて、CSR ファイルが正しいことを確認します。 
    $ cat /user_or_entity_database_directory/example.csr
		-----BEGIN CERTIFICATE REQUEST-----
		MIICzzCCAbcCAQAwgYkx
		...
		-----END CERTIFICATE REQUEST-----
5.2.1.3.2. CRMFPopClient を使用した SharedSecret ベースの CMC の CSR の作成
以下の手順では、CRMFPopClient ユーティリティーを使用して、SharedSecret ベースの CMC 用の RSA 鍵ペアと CSR を作成する方法を説明します。これは、デフォルトでは caFullCMCSharedTokenCert プロファイルおよび caECFullCMCSharedTokenCert プロファイルによって処理される CMC 共有 Secret 認証方法にのみ使用します。
  1. 証明書が要求されるユーザーまたはエンティティーの証明書データベースディレクトリーに移動します。以下に例を示します。 
    $ cd /user_or_entity_database_directory/
  2. KRA トランスポート証明書を取得します。 
    $ pki ca-cert-find --name "DRM Transport Certificate"
		---------------
		1 entries found
		---------------
			Serial Number: 0x7
			Subject DN: CN=DRM Transport Certificate,O=EXAMPLE
			Status: VALID
			Type: X.509 version 3
			Key A    lgorithm: PKCS #1 RSA with 2048-bit key
			Not Valid Before: Thu Oct 22 18:26:11 CEST 2015
			Not Valid After: Wed Oct 11 18:26:11 CEST 2017
			Issued On: Thu Oct 22 18:26:11 CEST 2015
			Issued By: caadmin
		----------------------------
		Number of entries returned 1
  3. KRA トランスポート証明書をエクスポートします。 
    $ pki ca-cert-show 0x7 --output kra.transport
  4. CSR を作成し、これを /user_or_entity_database_directory/request.csr ファイルに保存します。 
    $ CRMFPopClient -d . -p password -n "cn=subject_name" -q POP_SUCCESS -b kra.transport -w "AES/CBC/PKCS5Padding" -y -v -o /user_or_entity_database_directory/example.csr
    EC キーペアと CSR を作成するには、コマンドに -a ec -t false オプションを渡します。
    パラメーターの詳細は、CRMFPopClient --help コマンドの出力を参照してください。
  5. 必要に応じて、CSR ファイルが正しいことを確認します。 
    $ cat /user_or_entity_database_directory/example.csr
		-----BEGIN CERTIFICATE REQUEST-----
		MIICzzCCAbcCAQAwgYkx
		...
		-----END CERTIFICATE REQUEST-----

5.2.1.4. PKI CLI での client-cert-request を使用した CSR の作成

pkiコマンドラインツールは、client-cert-request コマンドで使用して CSR を生成することもできます。ただし、前述のツールとは異なり、pki で 生成された CSR は CA に直接送信されます。PKCS#10 または CRMF 要求の両方を生成できます。
PKCS#10 要求の生成例: 
pki -d user token db directory -P https -p 8443 -h host.test.com -c user token db passwd client-cert-request "uid=test2" --length 4096 --type pkcs10
CRMF リクエストの生成例: 
pki -d user token db directory -P https -p 8443 -h host.test.com -c user token db passwd client-cert-request "uid=test2" --length 4096 --type crmf
成功するとリクエスト ID が返されます。
要求が送信されると、エージェントは pki ca-cert-request-approve コマンドを使用して承認できます。
以下に例を示します。 
pki -d agent token db directory -P https -p 8443 -h host.test.com -c agent token db passwd -n <CA agent cert nickname> ca-cert-request-approve request id
詳細は、pki client-cert-request --help コマンドを実行して man ページを参照してください。

5.2.2. サーバー側の鍵生成を使用した CSR の生成

Firefox v69 以降や Chrome など、多くの新しいバージョンのブラウザーでは、PKI キーを生成する機能と、キーアーカイブ用の CRMF のサポートが削除されています。RHEL では、CRMFPopClient (CR MFPopClient--help を参照) または pki (pki client-cert-request --help を参照) などの CLI を回避策として使用することができます。
サーバー側の Keygen の登録は、トークンキー管理システム (TMS) の導入以来、長い間行われてきました。このシステムでは、キーをスマートカードでローカルに生成するのではなく、KRA で生成できます。Red Hat Certificate System 9 では、ブラウザーのキー生成の問題を解決するための同様のメカニズムが導入されました。鍵はサーバーで生成され (特に KRA で)、PKCS#12 のクライアントに安全に転送されます。
注記
暗号化証明書にのみサーバー側 Keygen メカニズムを使用することが強く推奨されます。

5.2.2.1. 主な機能

  • 証明書要求キーは KRA で生成されます (注: CA と連携するには、KRA をインストールする必要があります)。
  • プロファイルのデフォルトプラグイン serverKeygenUserKeyDefaultImpl は、キーアーカイブ (つまり enableArchival パラメーター) を有効または無効にするための選択を提供します。
  • RSA 鍵と EC 鍵の両方のサポート
  • 手動 (エージェント) 承認と自動承認 (ディレクトリーパスワードベースなど) の両方のサポート

5.2.2.2. Server-Side Keygen を使用した証明書の登録

デフォルトの Sever-Side Keygen 登録プロファイルは、EE ページの List Certificate Profiles タブにあります。

サーバー側の鍵の生成を使用した手動ユーザーのデュアル使用証明書登録

図5.1 エージェントの手動による承認を必要とするサーバー側のキータイプの登録

エージェントの手動による承認を必要とするサーバー側のキータイプの登録

サーバー側の鍵生成を使用したディレクトリー認証ユーザーのデュアル使用証明書の登録

図5.2 LDAP の uid/pwd 認証が正常に実行されると自動的に承認される サーバー側のキータイプの登録

LDAP の uid/pwd 認証が正常に実行されると自動的に承認される サーバー側のキータイプの登録
リクエストの承認方法に関係なく、Server-Side Keygen Enrollment メカニズムでは、エンドエンティティーユーザーが PKCS#12 パッケージのパスワードを入力する必要があります。このパスワードには、発行された証明書と、発行後にサーバーによって生成された暗号化された秘密鍵が含まれます。
重要
パスワードは共有しないでください。CA や KRA のエージェントでさえありません。
登録要求が承認されると、PKCS#12 パッケージが生成され、以下が行われます。
  • 手動承認の場合、PKCS#12 ファイルは要求を承認する CA エージェントに返されます。その後、エージェントは PKCS#12 ファイルをユーザーに転送することが期待されます。
  • 自動承認の場合、PKCS#12 ファイルはリクエストを送信したユーザーに返されます。

図5.3 エージェントによる手動による登録

エージェントによる手動による登録
PKCS#12 ファイルを受け取ったら、アプリケーションごとにこのファイルをユーザーの内部証明書/キーデータベースに pkcs12util インポートするなどの CLI を使用できます。たとえば、ユーザーの Firefox nss データベースです。

5.2.2.3. キーリカバリー

証明書登録プロファイルで enableArchival パラメーターが true に設定されている場合、Server-Side Keygen 登録時に秘密鍵がアーカイブされます。その後、アーカイブされた秘密鍵は、認定 KRA エージェントにより復元できます。

5.2.2.4. 追加情報

5.2.2.4.1. KRA 要求レコード
注記
このメカニズムの性質上、プロファイルで enableArchival パラメーターが true に設定されている場合、Server-Side keygen 要求ごとに 2 つの KRA 要求レコードがあります。
  • 要求タイプ asymkeyGenRequest の 1 つ
    この要求タイプは、KRA エージェントページの List Requests を使用してフィルターすることはできません。Show All Requests を選択して、一覧を表示できます。
  • 要求タイプの リカバリー の場合
5.2.2.4.2. 監査レコード
有効にした場合には、以下の監査レコードを確認することができます。
CA
  • SERVER_SIDE_KEYGEN_ENROLL_KEYGEN_REQUEST
  • SERVER_SIDE_KEYGEN_ENROLL_KEY_RETRIEVAL_REQUEST
KRA
  • SERVER_SIDE_KEYGEN_ENROLL_KEYGEN_REQUEST_PROCESSED
  • SERVER_SIDE_KEYGEN_ENROLL_KEY_RETRIEVAL_REQUEST_PROCESSED (まだ実装されていません)
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.