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

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:

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?

  • From the documentation, :copy applies only to issuer or email. Feb 28, 2018 at 18:46

1 Answer 1


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

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 


    Requested Extensions:
        X509v3 Subject Alternative Name:
            DNS:acme.example.test, DNS:alt.example.test
Signature Algorithm: sha256WithRSAEncryption
  • 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 <file_name> .csr -key <file_name> .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 1, 2018 at 9: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. Mar 1, 2018 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, 2021 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. Sep 24, 2021 at 18:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.