☰

openssl.cnfでpolicy_anyを使用すると、どのような欠点がありますか？

tag-icon • tag-icon security openssl ssl key-authentication certificates
openssl.cnfでpolicy_anyを使用すると、どのような欠点がありますか？

与えられたように本書では、inのほとんどのフィールドを無視するために使用できますpolicy_any。これらのフィールドを省略すると、確かにいくつかの欠点があります。subjectcertificate requestセキュリティ関連の問題は発生しますか？

以下に与えられますpolicy_any：

[ policy_any ]
 countryName            = supplied
 stateOrProvinceName    = optional
 organizationName       = optional
 organizationalUnitName = optional
 commonName             = supplied
 emailAddress           = optional

私も設定するとcommonName = optionalどうなりますかcountryName = optional？それを使用するのは良い考えですかpolicy_any？

時間をいただきありがとうございます！

ベストアンサー1

このポリシーは、着信証明書署名要求が会社のポリシー（またはより正確には組織の証明書ポリシー（CP）および/または認証業務規則（CPS））に準拠しているかどうかを分類および検証するための基本的なサポートです。

コマンドラインで証明書に署名する場合、セキュリティ上の利点は無視できます。結局、あなた（または他のユーザー）はopensslの-config <filename>オプションを使用して代替プロファイルを使用し、上記のポリシーを迂回することができます。この例では、スペルエラーを見つけると便利です。

一方、ユーザーがWebポータルを介して要求を送信するなど、より大きな認証局の一部として使用している場合、このポリシーセクションは、会社によって必要なフィールドがすべて含まれていない署名要求を見つけるのに役立ちます。ポリシー。

つまり、suppliedあなたの例のように設定すると、アイテムが有効であるか会社のポリシーに準拠しているかどうかを確認しないため、確認はあまりありません。たとえば、commonName組織名が acme.com の場合、www.google.com を確認しません。

match代わりに、組織の証明書全体に一貫性をsupplied適用するなど、特定のフィールドに役立ちます。organizationalUnitただし、証明書ごとにフィールドが変更されるため、matchこのフィールドには使用できません。commonName

一部の証明書プロファイルでは、名前制約が役立つ場合があります。

あなたの例では変更し、commonName必須になるのを防ぎますcountryName。optional

このリストにないフィールドは、署名証明書から自動的に削除されます。つまり、要求がフィールドをgenerationQualifier設定すると、IIIそのオプションを使用しない限り、証明書からそのフィールドが削除されますpreserveDN。

あなたの質問のリストは、最も一般的に使用されるフィールドのマニュアルページの一例です。initialsなどgivenNameの可能なフィールドを使用することもできますgenerationQualifier。 RFC 5280にはいくつか記載されており、要件に十分でない場合は直接定義することもできます。 OpenSSLに必要なのは、1つ以上のフィールドが必要です。

おすすめ記事