検索

3.7. サブジェクト名およびサブジェクト代替名の管理

download PDF
証明書の サブジェクト名 は、証明書を発行するエンティティーの ID 情報が含まれる識別名 (DN) です。このサブジェクト名は、共通名や組織単位などの標準の LDAP ディレクトリーコンポーネントから構築できます。これらのコンポーネントは X.500 に定義されます。サブジェクト名の他に、証明書には サブジェクト代替名 があります。これは、X.500 に定義されていない追加情報が含まれる証明書の拡張機能セットです。
サブジェクト名とサブジェクトの代替名の命名コンポーネントはカスタマイズできます。
重要
サブジェクト名が空の場合は、Subject Alternative Name 拡張が存在し、critical のマークが付けられている必要があります。

3.7.1. サブジェクト名でのリクエスター CN または UID の使用

証明書要求の cn 値または uid 値は、発行した証明書のサブジェクト名をビルドするために使用できます。このセクションでは、サブジェクト名制約に naming 属性 (CN または UID) が証明書要求に存在する必要があるプロファイルを示しています。naming 属性がないと、リクエストは拒否されます。
この設定には、以下の 2 つの部分があります。
  • CN または UID 形式は、Subject Name Constraint の pattern 設定に設定されます。
  • CN または UID トークン、および証明書の特定の接尾辞を含むサブジェクト DN の形式は、Subject Name Default に設定されます。
たとえば、サブジェクト DN で CN を使用するには、次のコマンドを実行します。
policyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl
policyset.serverCertSet.1.constraint.name=Subject Name Constraint
policyset.serverCertSet.1.constraint.params.pattern=CN=[^,]+,.+
policyset.serverCertSet.1.constraint.params.accept=true
policyset.serverCertSet.1.default.class_id=subjectNameDefaultImpl
policyset.serverCertSet.1.default.name=Subject Name Default
policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$,DC=example, DC=com
この例では、リクエストに cn=John Smith の CN が含まれる場合、証明書は、cn=John Smith,DC=example, DC=com のサブジェクト DN で発行されます。要求が完了しても、uid=jsmith の UID があり CN がない場合、要求は拒否されます。
同じ設定を使用して、要求側の UID をサブジェクト DN にプルします。
policyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl
policyset.serverCertSet.1.constraint.name=Subject Name Constraint
policyset.serverCertSet.1.constraint.params.pattern=UID=[^,]+,.+
policyset.serverCertSet.1.constraint.params.accept=true
policyset.serverCertSet.1.default.class_id=subjectNameDefaultImpl
policyset.serverCertSet.1.default.name=Subject Name Default
policyset.serverCertSet.1.default.params.name=UID=$request.req_subject_name.uid$,DC=example, DC=com
pattern パラメーターの形式は、「Subject Name 制約」 および 「サブジェクト名のデフォルト」 で説明されています。

3.7.2. サブジェクト代替名への LDAP ディレクトリー属性値およびその他の情報の挿入

LDAP ディレクトリーからの情報、または要求元によって送信された情報は、Subject Alt Name Extension Default 設定で一致する変数を使用して、証明書のサブジェクト代替名に挿入できます。デフォルトでは、情報のタイプ (形式) と、情報の取得に使用する一致するパターン (変数) を設定します。以下に例を示します。
policyset.userCertSet.8.default.class_id=subjectAltNameExtDefaultImpl
policyset.userCertSet.8.default.name=Subject Alt Name Constraint
policyset.userCertSet.8.default.params.subjAltNameExtCritical=false
policyset.userCertSet.8.default.params.subjAltExtType_0=RFC822Name
policyset.userCertSet.8.default.params.subjAltExtPattern_0=$request.requestor_email$
policyset.userCertSet.8.default.params.subjAltExtGNEnable_0=true
これにより、要求側の電子メールがサブジェクト名の最初の CN コンポーネントとして挿入されます。追加のコンポーネントを使用するには、Type_Pattern_、および Enable_ 値を、Type_1 などの数値にインクリメントします。
サブジェクトの alt 名の設定については、「サブジェクト代替名の拡張機能のデフォルト」 を参照してください。
LDAP コンポーネントを証明書のサブジェクト代替名に挿入するには、以下を実行します。
  1. LDAP 属性値を挿入するには、ユーザーディレクトリーの認証プラグイン SharedSecret を有効にする必要があります。
    1. CA コンソールを開きます。
      pkiconsole https://server.example.com:8443/ca
    2. 左側のナビゲーションツリーで 認証 を選択します。
    3. Authentication Instance タブで、Add をクリックして、SharedSecret 認証プラグインのインスタンスを追加します。
    4. 以下の情報を入力します。
      Authentication InstanceID=SharedToken
      shrTokAttr=shrTok
      ldap.ldapconn.host=server.example.com
      ldap.ldapconn.port=636
      ldap.ldapconn.secureConn=true
      ldap.ldapauth.bindDN=cn=Directory Manager
      password=password
      ldap.ldapauth.authtype=BasicAuth
      ldap.basedn=ou=People,dc=example,dc=org
    5. 新規プラグインインスタンスを保存します。
    注記
    pkiconsole が非推奨になりました。
    JOIN 共有トークンの設定に関する詳細は、「CMC 共有シークレットの設定」 を参照してください。
  2. ldapStringAttributes パラメーターは、ユーザーの LDAP エントリーから mail 属性の値を読み込み、その値を証明書要求に追加するように、認証プラグインに指示します。値が要求に設定されている場合、証明書プロファイルポリシーは、拡張値のその値を挿入するように設定できます。
    dnpattern パラメーターの形式は、「Subject Name 制約」 および 「サブジェクト名のデフォルト」 で説明されています。
  3. CA が証明書拡張機能に LDAP 属性の値を挿入できるようにするには、プロファイルの設定ファイルを編集し、拡張機能のポリシーセットパラメーターを挿入します。たとえば、caFullCMCSharedTokenCert プロファイルの Subject Alternative Name 拡張に mail 属性値を挿入するには、以下のコードを変更します。
    policyset.setID.8.default.params.subjAltExtPattern_0=$request.auth_token.mail[0]$
    プロファイルの編集に関する詳細は、「RAW 形式での証明書プロファイルの編集」 を参照してください。
  4. CA を再起動します。
    systemctl restart pki-tomcatd-nuxwdog@instance_name.service
この例では、caFullCMCSharedTokenCert プロファイル登録フォームを介して送信される証明書では、要求側の mail LDAP 属性の値で Subject Alternative Name 拡張機能が追加されます。以下に例を示します。
Identifier: Subject Alternative Name - 2.5.29.17
    Critical: no
    Value:
    RFC822Name: jsmith@example.com
このポリシーセットのいずれかの Pattern_ パラメーターにトークン ($X$) として設定することにより、証明書に自動的に挿入できる属性が多数あります。一般的なトークンを 表3.1「証明書の設定に使用する変数」 に記載します。デフォルトのプロファイルに、これらのトークンの使用方法の例が含まれています。
表3.1 証明書の設定に使用する変数
ポリシーセットトークン 説明
$request.auth_token.cn[0]$ 証明書を要求したユーザーの LDAP 共通名 (cn) 属性。
$request.auth_token.mail[0]$ 証明書を更新したユーザーの LDAP メール (mail) 属性の値。
$request.auth_token.tokencertsubject$ 証明書サブジェクト名。
$request.auth_token.uid$ 証明書を要求したユーザーの LDAP ユーザー ID (uid) 属性。
$request.auth_token.userdn$ 証明書を要求したユーザーのユーザー DN。
$request.auth_token.userid$ 証明書を要求したユーザーのユーザー ID 属性の値。
$request.uid$ 証明書を要求したユーザーのユーザー ID 属性の値。
$request.requestor_email$ 要求を送信したユーザーのメールアドレス。
$request.requestor_name$ 要求を送信した人。
$request.upn$ Microsoft UPN。これには (UTF8String)1.3.6.1.4.1.311.20.2.3,$request.upn$ の形式があります。
$server.source$ サーバーに対し、サブジェクト名のバージョン 4 の UUID (乱数) コンポーネントを生成するように指示します。この値は常に (IA5String)1.2.3.4,$server.source$ 形式になります。
$request.auth_token.user$ 要求が TPS によって送信された場合に使用します。証明書をリクエストした TPS サブシステム信頼マネージャー。
$request.subject$ 要求が TPS によって送信された場合に使用します。TP S が解決して要求したエンティティーのサブジェクト名 DN。例: cn=John.Smith.123456789,o=TMS Org

3.7.3. SAN 拡張での CN 属性の使用

RFC 2818 で非推奨となったドメイン名の検証に、サブジェクト DN の Common Name (CN) 属性の使用に対応しなくなりました。代わりに、これらのアプリケーションやライブラリーは、証明書要求で dNSName Subject Alternative Name (SAN) の値を使用します。
Certificate System は、RFC 1034 セクション 3.5 に従って優先名前構文と一致し、複数のコンポーネントを持つ場合にのみ CN をコピーします。また、既存の SAN 値が保持されます。たとえば、CN をベースとする dNSName 値は、既存の SAN に追加されます。
SAN 拡張の CN 属性を使用するように Certificate System を設定するには、証明書を発行するために使用する証明書プロファイルを編集します。以下に例を示します。
  1. プロファイルを無効にします。
    # pki -c password -p 8080 \
         -n "PKI Administrator for example.com" ca-profile-disable profile_name
  2. プロファイルを編集します。
    # pki -c password -p 8080 \
         -n "PKI Administrator for example.com" ca-profile-edit profile_name
    1. プロファイルに固有のセット番号を使用して、以下の設定を追加します。以下に例を示します。
      policyset.serverCertSet.12.constraint.class_id=noConstraintImpl
      policyset.serverCertSet.12.constraint.name=No Constraint
      policyset.serverCertSet.12.default.class_id=commonNameToSANDefaultImpl
      policyset.serverCertSet.12.default.name=Copy Common Name to Subject
      前述の例では、12 をセット番号として使用しています。
    2. policyset.userCertSet.list パラメーターに新しいポリシーセット番号を追加します。以下に例を示します。
      policyset.userCertSet.list=1,10,2,3,4,5,6,7,8,9,12
    3. プロファイルを保存します。
  3. プロファイルを有効にします。
    # pki -c password -p 8080 \
         -n "PKI Administrator for example.com" ca-profile-enable profile_name
注記
すべてのデフォルトサーバーグループに、commonNameToSANDefaultImpl のデフォルトが含まれます。

3.7.4. CSR からの SAN 拡張の許可

特定の環境では、管理者は Certificate Signing Request (CSR) で Subject Alternative Name (SAN) 拡張機能を指定できるようにします。

3.7.4.1. CSR から SAN を取得するプロファイルの設定

CSR からの SAN の取得を許可するには、ユーザー拡張機能のデフォルトを使用します。詳細は、「User Supplied Extension Default」 を参照してください。
注記
SAN 拡張には、1 つ以上の SAN を含めることができます。
CSR から SAN を受け入れるには、caCMCECserverCert のように、以下のデフォルトおよび制約をプロファイルに追加します。
prefix.constraint.class_id=noConstraintImpl
prefix.constraint.name=No Constraint

prefix.default.class_id=userExtensionDefaultImpl
prefix.default.name=User supplied extension in CSR
prefix.default.params.userExtOID=2.5.29.17

3.7.4.2. SAN を使用した CSR の生成

たとえば、certutil ユーティリティーを使用して、2 つの SAN を持つ CSR を生成するには、以下を実行します。
# certutil -R -k ec -q nistp256 -d . -s "cn=Example Multiple SANs" --extSAN dns:www.example.com,dns:www.example.org -a -o /root/request.csr.p10
CSR の生成後に、「CMC 登録プロセス」 で説明されている手順に従って、CMC の登録を完了します。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.