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

13.8. EE のサーバー側キー生成

13.8.1. 概要

Firefox v69 以降や Chrome など、多くの新しいバージョンのブラウザーでは、PKI キーを生成する機能と、キーアーカイブ用の CRMF のサポートが削除されています。CRMFPopClient ("CRMFPopClient --help" を参照) や pki ("pki client-cert-request --help" を参照) などの CLI は、Fedora または RHEL プラットフォームでの回避策として使用できますが、他のプラットフォーム上のクライアントはほとんど使用されていません。

サーバー側の Keygen の登録は、トークンキー管理システム (TMS) の導入以来、長い間行われてきました。このシステムでは、キーをスマートカードでローカルに生成するのではなく、KRA で生成できます。PKI v.10.5 以降では、ブラウザーのキー生成の問題を解決するための同様のメカニズムが導入されています。鍵はサーバー (具体的には KRA) で生成され、PKCS#12 のクライアントに安全に転送されます。

注記

暗号化証明書にのみサーバー側 Keygen メカニズムを使用することが強く推奨されます。

13.8.2. 主な機能

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

13.8.3. インストール設定

注記

サーバー側 Keygen を設定するには、CA に加えて KRA インスタンスが必要です。

注記

CA と KRA が Tomcat インスタンスを共有している場合は、トランスポート証明書をインポートするために以下の手順を実行する必要はありません。

CA インスタンスおよび KRA インスタンスをインストールした後に、スタンドアロンの Tomcat Web サーバーインスタンスの場合には、CA の nssdb に KRA トランスポート証明書を追加する必要があります。

まず CA をシャットダウンします。

Copy to Clipboard Toggle word wrap 
Systemctl stop pki-tomcatd@<ca_instance_name>.service
e.g.
# Systemctl stop pki-tomcatd@pki-ca.service

KRA の輸送証明書をファイルにエクスポートします。

  • KRA トランスポート証明書を検索してエクスポートします。
Copy to Clipboard Toggle word wrap 
grep "kra.transport.cert=" /var/lib/pki/<kra_instance_name>/kra/conf/CS.cfg | sed 's/kra.transport.cert=//' > <kra transport cert file>
e.g.
# grep "kra.transport.cert=" /var/lib/pki/pki-kra/kra/conf/CS.cfg | sed 's/kra.transport.cert=//' > /tmp/kraTransport.cert

CA の CS.cfg で指定されたニックネームを使用して、KRA のトランスポート証明書を CA の nssdb にインポートします。

  • トランスポート証明書のニックネームをリスト表示します。
Copy to Clipboard Toggle word wrap 
grep "ca.connector.KRA.transportCertNickname" /var/lib/pki/<ca_instance_name>/ca/conf/CS.cfg
e.g.
# grep "ca.connector.KRA.transportCertNickname" /var/lib/pki/pki-ca/ca/conf/CS.cfg
ca.connector.KRA.transportCertNickname=KRA transport cert
  • 上記のステップでリストしたニックネームを使用してインポートします。
Copy to Clipboard Toggle word wrap 
certutil -d /var/lib/pki/<ca_instance_name>/alias -A -t “,,” -n <transportNickName> -i <kra transport cert file>
e.g.
# certutil -d /var/lib/pki/pki-ca/alias -A -t “,,” -n "KRA transport cert" -i /tmp/kraTransport.cert

CA を開始します。

Copy to Clipboard Toggle word wrap 
systemctl start pki-tomcatd@<ca_instance_name>.service
e.g.
# Systemctl start pki-tomcatd@pki-ca.service

13.8.4. プロファイル設定

サーバー側で鍵が生成される証明書の登録を許可するために、caServerKeygen_UserCert および caServerKeygen_DirUserCert の 2 つのデフォルトプロファイルがデフォルトで提供されます。ただし、正しい入力、出力、およびポリシー設定を持つプロファイルは、サーバー側の keygen プロファイルに切り替えることができます。

Server-Side Keygen プロファイルには、以下のコンポーネントが含まれている必要があります。

13.8.4.1. 入力

Copy to Clipboard Toggle word wrap 
input.i1.class_id=serverKeygenInputImpl

13.8.4.2. 出力

Copy to Clipboard Toggle word wrap 
output.o1.class_id=pkcs12OutputImpl

13.8.4.3. Policyset

生成された PKCS12 のパスワードは、次のポリシーで適用できます。

Copy to Clipboard Toggle word wrap 
policyset.userCertSet.11.constraint.class_id=p12ExportPasswordConstraintImpl
policyset.userCertSet.11.constraint.name=PKCS12 Password Constraint
policyset.userCertSet.11.constraint.params.password.minSize=20
policyset.userCertSet.11.constraint.params.password.minUpperLetter=2
policyset.userCertSet.11.constraint.params.password.minLowerLetter=2
policyset.userCertSet.11.constraint.params.password.minNumber=2
policyset.userCertSet.11.constraint.params.password.minSpecialChar=2
policyset.userCertSet.11.constraint.params.password.seqLength=6
policyset.userCertSet.11.constraint.params.password.maxRepeatedChar=3
policyset.userCertSet.11.default.class_id=noDefaultImpl
policyset.userCertSet.11.default.name=No Default

このポリシーでは以下を設定できます。

  • password.minSize - パスワードの最小サイズ。
  • password.minUpperLetter - 大文字の最小数。
  • password.minLowerLetter - 小文字の最小数。
  • password.minNumber - 最小桁数。
  • password.minSpecialChar - 句読点の最小数。
  • password.seqLength - 繰り返すことのできない部分文字列シーケンスのサイズ。
  • password.maxRepeatedChar - 各文字の最大繰り返し回数。

制約に特定の設定が含まれていない場合は、CS.cfg からオプションを読み取ります。名前が異なる場合は、接頭辞 password. が passwordChecker. に置き換えられます。CS.cfg 内の設定はすべてのパスワードに使用されますが、各プロファイルを上書きして、より強力なパスワードまたは脆弱なパスワードを許可できます。

キータイプとキーサイズのパラメーターは、以下に例示するように設定できます。

Copy to Clipboard Toggle word wrap 
policyset.userCertSet.3.constraint.class_id=keyConstraintImpl
policyset.userCertSet.3.constraint.name=Key Constraint
policyset.userCertSet.3.constraint.params.keyType=-
policyset.userCertSet.3.constraint.params.keyParameters=1024,2048,3072,4096,nistp256,nistp384,nistp521
policyset.userCertSet.3.default.class_id=serverKeygenUserKeyDefaultImpl
policyset.userCertSet.3.default.name=Server-Side Keygen Default
policyset.userCertSet.3.default.params.keyType=RSA
policyset.userCertSet.3.default.params.keySize=2048
policyset.userCertSet.3.default.params.enableArchival=true

13.8.4.4. 認証

デフォルトのサーバー側の keygen 登録プロファイルは認証メカニズムによって異なります。ここでは、以下のようになります。

caServerKeygen_UserCert.cfg
"auth.class_id=" への空の値が含まれます。つまり、このプロファイルを介した登録要求には CA エージェントからの承認が必要になります。
caServerKeygen_DirUserCert.cfg
これには、"auth.instance_id=UserDirEnrollment" が含まれます。これは、ユーザーが LDAP uid/password 認証を渡すのに必要なことを意味します。このような認証は、CA エージェントからの要求ごとの承認を必要としないため、自動証明書として見なされます。

caServerKeygen_DirUserCert.cfg プロファイルで説明されるように、auth.instance_id ディレクティブを互換性のある認証プラグインクラスに設定すると、自動承認を設定できます。CS.cfg での設定例を次に示します。

Copy to Clipboard Toggle word wrap 
auths.instance.UserDirEnrollment.dnpattern=
auths.instance.UserDirEnrollment.ldap.basedn=ou=People,dc=example,dc=com
auths.instance.UserDirEnrollment.ldap.ldapconn.host=host.example.com
auths.instance.UserDirEnrollment.ldap.ldapconn.port=389
auths.instance.UserDirEnrollment.ldap.ldapconn.secureConn=false
auths.instance.UserDirEnrollment.ldap.maxConns=
auths.instance.UserDirEnrollment.ldap.minConns=
auths.instance.UserDirEnrollment.ldapByteAttributes=
auths.instance.UserDirEnrollment.ldapStringAttributes=mail
auths.instance.UserDirEnrollment.pluginName=UidPwdDirAuth

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

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

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

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

サーバー側キー生成登録マニュアル

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

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

サーバー側キー生成 LDAP 認証

リクエストの承認方法に関係なく、Server-Side Keygen Enrollment メカニズムでは、エンドエンティティーユーザーが PKCS#12 パッケージのパスワードを入力する必要があります。このパスワードには、発行された証明書と、発行後にサーバーによって生成された暗号化された秘密鍵が含まれます。

重要

パスワードは共有しないでください。CA や KRA のエージェントでさえありません。

登録要求が承認されると、PKCS#12 パッケージが生成され、以下が行われます。

  • 手動承認の場合、PKCS#12 ファイルは要求を承認する CA エージェントに返されます。その後、エージェントは PKCS#12 ファイルをユーザーに転送することが期待されます。
  • 自動承認の場合、PKCS#12 ファイルはリクエストを送信したユーザーに返されます。

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

サーバー側キー生成登録承認

PKCS#12 を受信すると、ユーザーは pkcs12util などの CLI を使用して、各アプリケーションの PKCS#12 ファイルをアプリケーションごとのユーザー内部の証明書/キーデータベースにインポートできます。たとえば、ユーザーの Firefox nss データベースです。

13.8.6. キーリカバリー

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

13.8.7. 追加情報

13.8.7.1. KRA 要求レコード

注記

このメカニズムの性質上、プロファイルで enableArchival パラメーターが true に設定されている場合、Server-Side keygen 要求ごとに 2 つの KRA 要求レコードがあります。

  • 要求タイプ “asymkeyGenRequest” 用

    • この要求タイプは、KRA エージェントページの “List Requests” でフィルタリングすることはできません。“Show All Requests” を選択して、リストを表示できます。
  • 要求タイプの “recovery” 用

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

Theme

© 2025 Red Hat, Inc.