OpenSSL: how to generate a CSR with interactively solicited Subject Alternative Names (SANs)?

Question

I wish to configure OpenSSL such that when running openssl req -new to generate a new certificate signing request, I am prompted for any alternative subject names to include on the CSR.

I have added this line to the [req_attributes] section of my openssl.cnf:

subjectAltName                  = Alternative subject names

This has the desired effect that I am now prompted for SANs when generating a CSR:

$ openssl req -new -out test.csr -key ./test.key                            <<<
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [US]:
State or Province Name (full name) [New York]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Example Co]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:test.example.com
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Alternative subject names []:DNS:alt1.example.com

In the above example, I have entered DNS:alt1.example.com when prompted for the SANs.

The problem is that the resulting CSR does not appear to be well formatted:

$ openssl req -text -in ./test.csr
Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=US, ST=New York, O=The Banes, CN=test.thebanes.org
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    [...]
                Exponent: 65537 (0x10001)
        Attributes:
            X509v3 Subject Alternative Name:unable to print attribute

OpenSSL complains that it is unable to print the value of the Subject Alternative Name attribute. From examples online (where people hard-code the SANs into their openssl.cnf, rather than prompting for them interactively as I want), I expect to see this instead:

        Attributes:
            X509v3 Subject Alternative Name:
                DNS:alt1.example.com

So, how can I generate a well-formed CSR with interactively prompted SANs?

Unfortunately I think there is no solution to do that with "pure" `openssl` - you would need a script that will mangle its config file for that. :( PS A proven solution to do that in a non-interactive manner is here: http://stackoverflow.com/a/9158662/2693875 — Greg Dubicki, Jan 31 '16 at 13:26
Subsequently asked with better answers https://serverfault.com/questions/845766/ and https://security.stackexchange.com/questions/74345/ — dave_thompson_085, Apr 06 '21 at 03:49

score 4 · Answer 1 · answered Dec 06 '12 at 05:52

I've battled with this little nugget myself ... what a PITA!

My solution: I moved the all of openssl.cnf file into a Template Toolkit file leaving only the sans piece as the replacement piece, then wrapped a perl script around it.

The perl script prompts for the SANs entries, then inserts them into the template, saves the template to a temp file and then I call openssl req with the -config option pointed at the temp file. discard the temp file after the CSR is generated.

You also might want to look at: http://www.openssl.org/docs/apps/config.html

There are others who override $ENV just prior to execution and wrap the call to openssl req in perl or shell and accomplish the same thing in a slightly more efficient manner: http://blog.loftninjas.org/2008/11/11/configuring-ssl-requests-with-subjectaltname-with-openssl/

The $ENV solution didn't work for me. :( – Greg Dubicki Jan 31 '16 at 13:21 — Greg Dubicki, Jan 31 '16 at 13:21

raiserle · Answer 2 · 2017-11-30T20:34:06.767

I'm also looking for a solution. And this is, what you want:

[req]
default_bits      = 2048
default_key_file  = private.key.pem
...
...
attributes        = req_attributes

[req_attributes]
subjectAltName = Alternative DNS names, Email adresses or IPs (comma seperated list)
#optional default value
subjectAltName_default = DNS:myhost.com.au,IP:127.0.0.1,EMAIL:my@here.org

And you can get this by prompt for alternative subject name(s) :)

#openssl req -in mytest1/temp.csr.pem -noout -text
    Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=DE, ST=Sachsen, L=Heidenau, O=IT Rab\xC3\xB6se, OU=ssl
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:d8:cd:14:ca:d0:06:6c:8c:11:e9:52:bc:46:39:
                    c1:cf:5a:6e:dd:3b:a8:85:15:6b:13:82:82:4a:48:
                    cb:53:ea:70:ea:f4:02:b2:ef:b1:41:b2:d7:11:c7:
                    11:ba:07:1b:be:8c:30:bc:60:d2:82:83:a1:e1:19:
                    75:3b:69:03:01:3c:2b:7b:85:f4:2e:a9:58:68:8f:
                    0e:f4:5e:50:e1:3f:9e:cf:46:a0:eb:69:aa:1e:cb:
                    3a:99:cb:1d:93:60:d0:3b:38:96:87:45:19:51:f4:
                    40:72:e5:a7:5e:62:37:41:44:48:64:47:95:14:97:
                    4f:27:d0:0c:e7:6f:c1:e1:37
                Exponent: 65537 (0x10001)
        Attributes:
            X509v3 Subject Alternative Name:DNS:www.google.de,EMAIL:im@you.org
    Signature Algorithm: sha1WithRSAEncryption
        9d:2b:e4:eb:1b:c0:b6:0b:b4:62:a7:4d:01:68:98:68:36:98:
        1e:e9:bc:59:24:0f:1b:32:7b:da:9d:39:a4:0f:2c:70:3e:aa:
        f7:07:e7:6b:9b:3b:00:b3:71:e0:54:07:78:c7:6e:57:e3:89:
        07:e1:93:f1:77:e7:cc:0e:d0:ed:c5:d0:a3:5d:1a:cd:bb:d8:
        5f:64:25:81:1b:a8:2f:ef:c7:84:7a:f6:b8:52:4e:4c:1c:8d:
        83:b7:9b:02:8e:b2:39:68:a1:fe:f1:59:8b:e0:c4:91:f1:a9:
        c7:b3:82:a3:d2:92:2b:e5:79:9f:29:b6:63:e7:cf:9d:17:98:
        fe:70

This works when looking at the CSR, but when I create a certificate, it doesn't keep the SAN. — Jess, Dec 08 '17 at 18:53
If the format correct for SAN? Comma separated list. Check with SAN-prefix DNS only, if not not supported IP, EMAIL. Example: INPUT >> ``DNS:my.dns.com, DNS:my.otherdns.org`` — raiserle, Dec 10 '17 at 13:59
Ok. This is normal function of ``openssl`` **wtf**! You must also provide the SAN to the ``CA``-command as ``-extensions ``, or ``-extfile ``. https://mta.openssl.org/pipermail/openssl-users/2016-January/002764.html — raiserle, Dec 10 '17 at 22:55

MXW · Answer 3 · 2015-05-08T18:02:05.067

1

This "subjectAltName" should not be in this section: attributes = req_attributes. But in a section for req_extensions = (call it whatever you want).

And no need for all the BS like

subjectAltName           = Alternative subject names
subjectAltName_default   = DNS:www.g00gle.com

Just type in what you want, how many you want:

subjectAltName = DNS:*.g00gle.com, DNS:g00gle.com, DNS:192.168.1.2

(The last one makes internal access like "https://192.168.1.2" without warning)

So something like:

[ req ]
req_extensions     = my_extensions

[my_extensions]
subjectAltName     = DNS:*.g00gle.com, DNS:g00gle.com, DNS:192.168.1.2

Cheers!

edited May 08 '15 at 18:02

answered May 08 '15 at 17:21

MXW

19
2

2

This is NOT what OP asked for - he wanted an *interactive* solution. – Greg Dubicki Jan 31 '16 at 13:22
1

Shouldn't IPs be recorded using "IP:192.168.1.2", not a DNS-format record? I noted this discussion from 2013 about bugs between browsers when using DNS or IP to store IP addresses as SANs -- http://www.michaelm.info/blog/?p=1281 -- but this bug should be nixed by now. – Chris Woods Dec 08 '17 at 11:21

score 0 · Answer 4 · answered Apr 05 '21 at 23:16

0

I don't believe what you are asking for is possible. I've also been looking for how to do the same and looking at the documentation in the BUGS section we see:

The current prompting is not very friendly. It doesn't allow you to confirm what you've just entered. Other things like extensions in certificate requests are statically defined in the configuration file. Some of these: like an email address in subjectAltName should be input by the user.

This implies, to me at least, that this is only specifiable via hard coding in the configuration file unfortunately.

answered Apr 05 '21 at 23:16

johnsoga

1

That text was once true but is now obsolete; 1.1.1 (in 2018, well after this Q) added a commandline option `-addext` and the page you link actually shows an example of `-addext subjectAltName`. Even in lower versions, 'static' is arguable; _on Unix_ (which OP here didn't indicate) with some shells you can create a named temporary file on the commandline using `<(...)` which OpenSSL accepts; see https://serverfault.com/questions/845766/ or https://security.stackexchange.com/questions/74345/ – dave_thompson_085 Apr 06 '21 at 03:43
Definitely not obsolete as it links the current man page. Given the OP's example they are looking to have the SAN entries prompted for like the other DN values from the `req` command which is not possible per the docs admission as I provided. Your example is based on passing CLI arguments which is not interactive OP requested and your links reference the same behavior. Redirecting shell input from a file as you showed does not meaningfully help. If you want to write a wrapper script then sure its possible that way but otherwise OP's request is not possible per provided docs admission – johnsoga Apr 07 '21 at 14:32

OpenSSL: how to generate a CSR with interactively solicited Subject Alternative Names (SANs)?

4 Answers4

Linked