Are The ca Policy Values In the OpenSSL Configuration File Applied When Both Creating AND Signing Certificates?

Question

Are the 'ca' policy values that are present in the OpenSSL configuration file applied when the 'ca' command is used to create a certificate AND when the 'ca' command is used to sign an existing certificate? For example, suppose the following policy section is present in an OpenSSL configuration file:

[ policy_basic ]
commonName                  = supplied
organizationName            = match
organizationalUnitName      = supplied
streetAddress               = optional
localityName                = match
stateOrProvinceName         = match
countryName                 = match
postalCode                  = optional
emailAddress                = optional

If I used the 'ca' command to generate a Certificate Signing Request ("CSR"), and no values were supplied for the "optional" policy fields, would the CSR's Subject Name Relative Distinguished Names ("RDN") contain the following:

commonName                  = Whatever I entered at the prompt or was stipulated as the default
organizationName            = The issuing CA certificate's Subject Name organizationName RDN
organizationalUnitName      = Whatever I entered at the prompt or was stipulated as the default
streetAddress               = Doesn't appear in CSR
localityName                = The issuing CA certificate's Subject Name localityName RDN
stateOrProvinceName         = The issuing CA certificate's Subject Name stateOrProvinceName RDN
countryName                 = The issuing CA certificate's Subject Name countryName RDN
postalCode                  = Doesn't appear in CSR
emailAddress                = Doesn't appear in CSR

Now let's use the 'ca' command to sign an existing CSR. Using the values contained in the same [ policy_basic ] policy section, are the following CSR Subject Name RDN values required to be present in the CSR before the CA certificate will be allowed to sign the CSR:

commonName                  = 
organizationName            = The issuing CA certificate's Subject Name organizationName RDN
organizationalUnitName      = 
streetAddress               = 
localityName                = The issuing CA certificate's Subject Name localityName RDN
stateOrProvinceName         = The issuing CA certificate's Subject Name stateOrProvincenName RDN
countryName                 = The issuing CA certificate's Subject Name countryName RDN
postalCode                  = 
emailAddress                = 

I purposely only showed values for the CSR's Subject Name RDNs whose corresponding policy field value is "match" in order to focus attention on how the MATCH policy value works.

Are my examples correct? If so, is it correct that the ca policy values that are present in the OpenSSL configuration file are applied when the 'ca' command in used to BOTH create AND sign certificates?

Answer 1

If I used the 'ca' command to generate a Certificate Signing Request ("CSR"), and no values were supplied for the "optional" policy fields, ...

Mu. THIS IS IMPOSSIBLE. The openssl ca command cannot generate a CSR, and never does. It does do several things, resulting in a quite long man page describing all the things it does, none of which is generating a CSR. Since it doesn't generate any CSR ever, it is meaningless to talk about the contents of something that doesn't exist.

The command that normally does generate a CSR is openssl req with the -new option (or -newkey which implies -new). The req command also uses configuration, but it uses different configuration than the ca command. In particular it does not, ever, use any policy section in the config file, so the contents of any policy section in any config file never matter to req. However, the attributes that req can (or does) put in the Subject DN are configured using a config section designated by the distinguished_name item, and in the 'standard' (upstream) config this section is [req_distinguished_name]. This is described on the man page for req, which is a different man page than for ca because it is a different command.

(For completeness, openssl can also generate a basic/trivial CSR from an existing certificate with openssl x509 -x509toreq. This is rarely useful.)

Now let's use the 'ca' command to sign an existing CSR. Using the values contained in the same [ policy_basic ] policy section, are the following CSR Subject Name RDN values required to be present in the CSR before the CA certificate will be allowed to sign the CSR: ...

Almost. Issuing a certificate is NOT signing the (or any) CSR. As I said on at least one of your previous Qs, if you look at a CSR and the resulting cert you can see the cert is different from the CSR. The openssl ca command, like any other ('real') CA, creates a cert partly using data from the CSR, and signs that new cert NOT the CSR.

With that corrected, yes fields (technically attributes but Eric wasn't strict about terminology) designated 'match' in the policy section in the config file must be in the CSR with the same value as the CA's (parent) cert, and as result the value in the new cert will be the same as both the CSR and the parent cert.

The order may be different: as described on the man page, openssl ca in the absence of -preserveDN or config preserve will construct the new cert Subject DN in the order specified by the policy config, regardless of the order in either the CSR or the parent cert. It is conventional to order the RDNs in X.509 DNs from 'large' to 'small' (Country, STate, Locality, Org, OrgUnit, CommonName) so commonly the order in policy and CSR will already be the same, but OpenSSL doesn't require this. Also you should be aware that while actual, encoded DNs are as I said usually 'large' to 'small', some programs and libraries follow the LDAP convention of displaying (and if applicable entering) them from 'small' to 'large' i.e. in reverse order; if you aren't aware of the convention this can be confusing.