在 openssl.cnf 中使用 policy_any 有什麼缺點？

正如本文件中所給出的，我們可以使用忽略inpolicy_any的大部分欄位。忽略這些欄位肯定有一些弊端，會不會導致一些安全相關的問題？subject``certificate request

policy_any給出為：

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

如果我也設置commonName = optional了countryName = optional怎麼辦？使用它是個好主意policy_any嗎？

謝謝你的時間！

該政策只是整理和檢查傳入的證書籤名請求是否符合公司政策（或更準確地說，是您組織的證書政策 (CP) 和/或認證實踐聲明 (CPS)）的基本幫助。

如果您在命令行上簽署您的證書，則安全優勢可以忽略不計 - 畢竟，您（或其他使用者）可以使用 openssl 的-config <filename>選項來使用替代配置文件並繞過上述策略。在這個例子中，捕捉錯別字可能很有用。

另一方面，如果您將其用作更大的證書頒發機構的一部分，例如，使用者通過 Web 門戶送出請求，那麼此策略部分可能會幫助您擷取沒有獲得所有必需欄位的簽名請求根據您的公司政策。

也就是說，如果設置為supplied如您的範例中那樣，則檢查並不多，因為它不會檢查條目是否有效或是否遵循公司政策。例如，commonName當您的組織名為 acme.com 時，它不會檢查 www.google.com 的 a！

使用match而不是supplied可以幫助您處理某些欄位，例如，organizationalUnit在您的組織的證書中強制執行一致。但是，您不能match在commonName現場使用，因為預計每個證書都會更改。

名稱約束可能會幫助您獲得某些證書配置文件。

在您的範例中，更改commonNameand countryNametooptional只會阻止它們成為強制性的。

請注意，不在該列表中的欄位將從簽名證書中靜默刪除。也就是說，如果您的請求將generationQualifier欄位設置為該欄位，III則將從證書中刪除（除非您使用該preserveDN選項）。

您在問題中的列表只是最常用欄位的文件頁面中的一個範例。您可以使用更多可能的欄位，initials例如givenName和generationQualifier。有些列在 RFC 5280 中，如果它們不能滿足您的需求，您甚至可以定義自己的。OpenSSL 所要求的只是至少存在一個欄位。

引用自：https://unix.stackexchange.com/questions/255993