What is the purpose of "certificatePolicies" in a CSR? How should an OID be used?

Question

While looking for the best way to add multiple Subject Alternative Names (SAN) to a Certificate Signing Request (CSR), this namecheap article provided the following command:

openssl req -new -addext "subjectAltName = \
DNS:additionaldomain1.com,DNS:www.additionaldomain2.com,DNS:www.additionaldomain3.com" \
-addext "certificatePolicies = 1.2.3.4" -newkey rsa:2048 -keyout -keyout server.key \
-nodes -out server.csr

This command makes sense, however there's no mention of why the -addext "certificatePolicies = 1.2.3.4" options was added. Further investigation of certificate policies leads to providing a required OID, which is explained in another Security StackExchange post.

However, I'm still unclear what the purpose of this value is, and how it should be used. The server which I'm creating this CSR will require several more in the future, so to quote some text from the answer above:

The developer can choose one arbitrarily as long as it doesn't conflict with other OIDs. Some applications/organisations apply a hierarchical structure to OID.

This implies I should use a new/different OID for each CSR I create. What is the best practice here, and how should I implement the certificatePolicies field?

Answer 1

However, I'm still unclear what the purpose of this value is, and how it should be used.

There is no purpose for this specific value, i.e. it is just a made up value used as example. And it does not actually make sense for the specific task of setting SAN. This looks more like an example copied from the openssl req documentation, where some parts were adjusted to fit the domain names and the other part was left maybe because the author of the referenced post did not understand what they were for. To cite from the original source, i.e. openssl req:

Example of giving the most common attributes (subject and extensions) on the command line:

openssl req -new -subj "/C=GB/CN=foo" \
             -addext "subjectAltName = DNS:foo.co.uk" \
             -addext "certificatePolicies = 1.2.3.4" \
             -newkey rsa:2048 -keyout key.pem -out req.pem

For the second part of the question:

This implies I should use a new/different OID for each CSR I create. What is the best practice here, and how should I implement the certificatePolicies field?

A single OID refers to a single certificate policy, like "this domain was domain-validated". Many certificates can have the same certificate policy. The OID should be registered, as is true with OIDs outside of the certificate policy too.

As far as I am aware, there is no requirement to have the certificatePolicies field in a certificate.

Answer 2

I would start with RFC 5280 section 4.2.1.4, Explaining what certificate policies are and why they're added to the certificate. TLDR:

In an end entity certificate, these policy information terms indicate the policy under which the certificate has been issued and the purposes for which the certificate may be used.

and

Applications with specific policy requirements are expected to have a list of those policies that they will accept and to compare the
policy OIDs in the certificate to that list.

It is best practice to have that policy OID added at the CA level. Most if not all public CA's will strip all the certificate policy OID's which are not conforming with their CPS (certificate practice statement) when signing the certificate, while some will refuse to issue a certificate and throw an error. In the case of the private CA, you would still opt for all the OID's being added by the CA and being defined in the certificate template. There are many reasons for that, including:

1. It is simple to make a typo in the OID in the manual process of the CSR generation
2. The role of OID's is to define the use of certificates, so you do not want requesters to have much freedom there
3. Ease of management, it is easier to implement changes at the template level
4. Uniformity, you want to limit yourself to the set of the predefined set's of OID's instead of allowing requesters for mixing and matching
5. Ease of auditing the issued certs
6. Application requirements and restrictions can be coordinated at the CA level

Your issuing CA should implement the certificate policy field. The policy should be registered under a specific OID which you can then use for verifying the policy at a trusted source. The short answer to your last remaining question is, no you most likely don't need to add the policy OID while generating the certificate signing request. It is also worth noting that object identifiers are not limited to the policy, but used to identify each attribute of the certificate.