Subject Alternative Name in Certificate Signing Request apparently does not survive signing

Question

So I have been able to create a Certificate Signing Request with a Subject Alternative Name of the form subjectAltName=IP:1.2.3.4 by following the recipe in a previous (splendid) answer.

When I inspect that CSR with openssl req -in key.csr -text I can see a corresponding section:

Requested Extensions:
  X509v3 Subject Alternative Name: 
    IP Address:1.2.3.4

I then proceed to signing the CSR with a self-signed key like so:

openssl x509 -req -days 365 -CA ca.crt -CAkey ca.key -CAcreateserial \
  -in key.csr -out key.crt

The resulting certificate (when inspected with openssl x509 -in key.crt -text) does not identify that section any more.

Is this just an artifact of display parameters or need I also instruct openssl x509 that it should include the extension when doing its signing (and if so, how)?

I am using OpenSSL on macOS High Sierra (openssl version reports LibreSSL 2.2.7) and have not changed its configuration from the defaults. The keys will ultimately be used between Debian (Stretch) servers, so I could perform key generation there, if it helps in this context.

Answer 1

The following command apparently resolves the issue:

openssl x509 -req -days 365 -CA ca.crt -CAkey ca.key -CAcreateserial \
  -extensions SAN \
  -extfile <(cat /etc/ssl/openssl.cnf \
    <(printf "\n[SAN]\nsubjectAltName=IP:1.2.3.4")) \
  -in key.csr -out key.crt

It is the same recipe as for openssl req, but with the two parameters extensions and extfile instead of reqexts and config.

This command was helpful for quickly confirming the desired outcome by printing the relevant section:

openssl x509 -in key.crt -text | grep "Subject Alternative Name" -C 1

Answer 2

Another option that works well is to use the -copy_extensions option and the -extensions san option.

Typically, the certificate generation can look like:

openssl x509 -req -days 365 -in ./certs/server.csr \
  -CA ./ca/server-ca.crt -CAkey ca/server-ca.key -CAcreateserial \
  -copy_extensions copy \
  -extensions san \
  -out ./certs/server.pem

It basically performs the same operations as the accepted answer, but has a couple of advantages:

• it is easier to read and understand than using subshells and multiple redirections
• It does not require you to know the contents of the SAN in order to construct the printf statement

Answer 3

I managed to put the SAN in CSR and then sign it without losing them, by doing the following.

Find the openssl.cnf

In Ubuntu

/etc/ssl/openssl.cnf

CentOS

/etc/pki/tls/openssl.cnf

And uncomment the following under the [ CA_default ] section

copy_extensions = copy

Then you have to create some files (if you don't know where, try issuing the first cert, the error message will tell you where)

sudo mkdir /your/dedicated-ca/dir/newcerts
sudo touch /your/dedicated-ca/dir/serial
sudo echo 1000 > /etc/pki/CA/serial

If you want to have duplicate certs by subject sudo echo unique_subject = no >> /etc/pki/CA/index.txt.attr

Now try to issue a cert, but not using openssl x509, but openssl ca

   sudo openssl ca -cert /your/ca/certfile.crt -keyfile /your/ca/certfile.key -in yourweb.csr -out yourweb.crt

Worked like a charm for me.