Information Security
tls certificates openssl certificate-authority digital-signature
Updated Fri, 20 May 2022 02:50:39 GMT

Regarding Openssl.config file: What is the importance of policy matching when creating a self-signed certificate with the aid of this file?


When trying to go through some material for self-signing a certificate, one of the steps required me to set policy conditions in this config file. See: https://www.phildev.net/ssl/opensslconf.html

The idea is that when you select policy_match=match, certain fields in the CA's certificate "must match with the corresponding fields in the client certificate to be signed". Why would a CA's certificate have to have matching fields with a client's certificate?

It all doesn't make sense to me since the client could be an arbitrary entity that has nothing in common with the CA. Can someone explain the scenario in which these would have to match?

Solution

It is an arbitrary, administrative decision for the creator of CA what client certificates they want to enable to be signed by the CA.

The policy_match in the following configuration line:

policy          = policy_match

is a chosen name that corresponds to a particular section in the configuration file. That section defines in details each of the

[ policy_match ]
countryName             = match
stateOrProvinceName     = match
localityName            = supplied
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

Each of the DN fields for the client certificate can be assigned to have the same value as the CA (match), be required to be specified (supplied), or be optional (optional).

The same guide suggests another policy that matches your criteria of "the client could be an arbitrary entity that has nothing in common with the CA":

[ policy_anything ]
countryName             = optional
stateOrProvinceName     = optional
localityName            = optional
organizationName        = optional
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

Yet if you wanted to create a CA for your organisation, that would allow issuing only certificates for that part of your organisation you can freely set for example:

policy          = policy_branch_1
[ policy_branch_1 ]
countryName             = match
stateOrProvinceName     = match
localityName            = match
organizationName        = optional
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = supplied

Which would required the issued certificates to have first three DN fields matching the CA's certificate.

Comments (3)

  • +0 – I want to make sure I understand your answer. Are you saying that a MATCH value for a policy field stipulates that when a CA certificate is used to either create a Certificate Signing Request ("CSR") or sign an existing CSR, that the value of the CA certificate's Subject Name Relative Distinguished Name ("RDN") fields that are specified in the policy with a MATCH value must MUST appear IDENTICALLY as the corresponding Subject Name RDNs in the CSR that is created or signed by the CA certificate? — Jul 07, 2020 at 17:17  
  • +0 – @Bill: a CSR is never created with any certificate. People describe issuing a cert as 'signing the CSR' but this is wrong; look at a CSR and the resulting cert and you can see they are different, although partly related. Yes, a policy setting of 'match' requires a particular field in the (Subject) name in CSR (or -subj if used), and thus the new cert, to match the field in the CA cert/name -- but it does not check order: the RDNs in the CSR can be in any order but the cert uses the order of the policy settings, unless you use -preserveDN as stated on the man page. — Jul 08, 2020 at 18:33  
  • +0 – Thanks for answering my comment, Dave. Now that I have re-read my comment I should have written the words "when a CA certificate is used to either create a Certificate Signing Request ("CSR") or sign an existing CSR" as "when the ca command is used ..." Most importantly, thanks for confirming that my understanding about the MATCH value for policy RDNs is correct. That's the critical piece of information I was trying to confirm. — Jul 08, 2020 at 22:48  

External Links

External links referenced by this document:

References