Quels sont les inconvénients de l'utilisation de policy_any dans openssl.cnf?

Comme indiqué dans ce document , nous pouvons utiliser policy_any pour ignorer la plupart des champs du subject dans la certificatee request . Il doit y avoir certains inconvénients à ignorer ces domaines, cela pourrait-il entraîner des problèmes de security?

Le policy_any est donné comme:

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

Que faire si je commonName = optional et countryName = optional aussi? Est-ce une bonne idée d'utiliser policy_any ?

Merci pour votre time!

La politique est simplement une aide de base pour le nettoyage et la vérification des requests de signature de certificate entrantes, conformément à la politique d'entreprise (ou plus précisément à la politique de certificateion (CP) et / ou à la Certification Certification Statement (CPS) de votre organisation).

Si vous signez vos certificates sur la command line, les avantages en termes de security sont négligeables – après tout, vous (ou un autre user) pouvez utiliser l' -config <filename> openssl pour utiliser un autre file de configuration et contourner la politique ci-dessus. Dans cet exemple, il peut être utile d'intercepter des fautes de frappe.

En revanche, si vous utilisez cette fonction dans le cadre d'une autorité de certificateion plus importante, par exemple lorsque les users soumettent une request via un portail Web, cette section de règles peut vous aider à intercepter les requests de signature qui n'ont pas tous les champs requirejs par votre politique d'entreprise.

Ceci étant dit, s'il est défini comme supplied dans votre exemple, il ne s'agit pas d'une vérification car il ne vérifie pas si les inputs sont valides ou suivent la politique de l'entreprise. Par exemple, il ne vérifie pas un nom commonName de http://www.google.com lorsque votre organisation s'appelle acme.com!

L'utilisation de la match au lieu de supplied aiderait avec certains des champs comme vous pourriez, par exemple, faire en sorte organizationalUnit soit cohérent à travers les certificates de votre organisation. Cependant, vous ne pouviez pas utiliser la match sur le champ commonName comme cela devrait changer dans chaque certificate.

Les contraintes de nom peuvent vous aider là pour certains profils de certificate.

Dans votre exemple, changer commonName et countryName en optional empêcherait d'être obligatoires.

Notez que les champs qui ne figurent pas dans cette list sont supprimés en silence du certificate signé. Autrement dit, si votre request avait le champ generationQualifier défini sur III il serait supprimé du certificate (sauf si vous utilisez l'option preserveDN ).

La list que vous avez dans votre question est simplement un exemple à partir des pages de documentation des champs les plus couramment utilisés. Il y a beaucoup plus de champs possibles que vous pourriez utiliser, tels que les initials , givenName et generationQualifier . Certains sont répertoriés dans la RFC 5280 et s'ils ne sont pas assez exigeants pour vos besoins, vous pouvez même définir le vôtre. Tout ce que nécessite OpenSSL est au less un champ à être présent.