5

On my pc with Windows 10 installed, I have to use OpenSSL. I have downloaded the version 1.0.2n and following this guide: Creating an SSL Certificate with Multiple Hostnames I modified the openssl.cfg configuration file (located in C:\OpenSSL-Win64\bin).

After some testing, I can generate with no problem both keys and certificates.

My problem is the following: my indications for the certificates generation are such that the Subject Alternative Name must have only 1 value and must match with the Common Name field. So, if (filling out certificate) I fill the commonName field with example.com, also the Subject Alternative Name must be example.com. I know that I can change every time the cfg file and set manually the value for the SAN in the v3-req section, but I want avoid this; I'm searching for a way to copy the value I prompt for the common name in the SAN field.

So, I tried this: in the openss.cfg file I went to v3 req section and I changed it in this way:

[ v3_req ]

# Extensions to add to a certificate request

basicConstraints = CA:FALSE 
keyUsage = nonRepudiation, digitalSignature, keyEncipherment 
subjectAltName = @alt_names

[alt_names] 
DNS.1 = commonName:copy

that is, I tried to exploit the :copy function but, unfortunately, this action does not work. If, after certificate generation, I launch the command

req -text -noout -in <filename.csr>

to verify my certificate, in the specific section I get this:

X509v3 Subject Alternative Name:
    DNS:commonName.copy 

As you can see, the output is the right side of my declaration under the [alt_names] section.

So, the questions are: Is there a method to to inherit the commonName to the subject alternative name? And if yes, how?

Andrew Schulman
  • 8,811
  • 21
  • 32
  • 47
Luca Sepe
  • 153
  • 1
  • 4

1 Answers1

8

Use ${section::name} to read previously defined variables.

Here's an example that works:

[ req ]

prompt             = no
string_mask        = default

# The size of the keys in bits:
default_bits       = 2048
distinguished_name = req_dn
req_extensions     = req_ext

[ req_dn ]

# Or traditional org style:
countryName = gb
organizationName = example
commonName = acme.example.test

[ req_ext ]

subjectAltName = @alt_names

[alt_names]
DNS.1 = ${req_dn::commonName}
DNS.2 = alt.example.test

Followed by:

openssl req -nodes -new -keyout test.key -out test.csr -config ./openssl.cnf

This results in:

openssl req -noout -text -in test.csr 

giving:

 ...
    Attributes:
    Requested Extensions:
        X509v3 Subject Alternative Name:
            DNS:acme.example.test, DNS:alt.example.test
Signature Algorithm: sha256WithRSAEncryption
     92:1c:e0:0e:6d:7d:2e:b4:64:c5:ab:ff:6a:37:dd:35:98:58:
 ...
garethTheRed
  • 4,539
  • 14
  • 22
  • Thanks, it works! Can I ask you another question? This option works if I want to inherit the default value with which I set the commonName variable in the cfg file. If I wanted to compile everything dynamically, how could I do it? That is, when I run the command to generate the certificate (req -new -out .csr -key .key) I am queried about the values I want to use for the variables: Country name, State, Locality, etc. Among these variables, I was asked to set the Common Name; if I wanted this value to be used for SAN, is there a way? – Luca Sepe Mar 01 '18 at 09:41
  • It works there too. Personally, I wouldn't use that method as you're leaving yourself open to smelling pisstakes when you enter the details. Create a config similar to the above and copy to each scenario/server in turn. Edit once, check it, then you can re-use when it's time to renew a certificate. Much safer. – garethTheRed Mar 01 '18 at 11:09
  • I just tried this, in my [ req_dn ], I have commonName = supplied (it's in the CSR). And in the [alt_names], I added ${req_dn::commonName}... and in my resulting certificate, I'm getting "supplied" in subject alt name. So basically, it doesn't work as I expected. – pHeoz Sep 24 '21 at 17:25
  • @pHeoz - The above creates the CSR, so I'm not sure what you mean by _it's in the CSR_. If you define the `commonName` variable as `supplied` then it's no surprise that the value of that variable is applied to the SAN. – garethTheRed Sep 24 '21 at 18:50