Subject Alternative Names are a X509 Version 3 (RFC 2459) extension to allow an SSL certificate to specify multiple names that the certificate should match. SubjectAltName can contain email addresses, IP addresses, regular DNS host names, etc. There’s a clean enough list of browser compatibility here.
Changing /etc/ssl/openssl.cnf isn’t too hard. Although most the documentation is hard to grasp, especially if you’re only trying to make requests. From this, I developed these changes to a standard config provided by debian/ubuntu. Edit openssl.cnf and uncomment “x509_extensions = v3_ca” in the [ req ] section.
Annoyingly, nobody appears to have figured out how to get openssl to ask you for this value.
I thought I was clever putting ‘subjectAltName=email:move’ in the v3_req section, which would put the email address you type in the subjectAltName field. I’d put in “foo@example.org, DNS:www1.example.org, DNS:www2.example.org” in the email field when ‘openssl req’ asked for it. Visually it worked, but the browsers didn’t like it. This appears to be functionality to deal with part 4.1.2.6 of the RFC, moving email address into subjectAltName.
I thought about writing a script that would copy openssl.cnf, ask me for the value of SubjectAltName, run sed against it, then start openssl. It would appear seamless, but of course be a hack.
A better answer lies here, you can configure openssl to use environment variables. At the top of openssl.cnf under where it set’s HOME=”…” I added
SAN="email:noc@example.com"
And in [ v3_req ] I added:
subjectAltName=${ENV::SAN}
So if you run openssl like this:
SAN="DNS:www.1example.org, DNS:www2.example.org" \ openssl req -new -key www.example.org.key -out www.example.org.csr
It will fill in subjectAltName with the contents of the SAN variable, otherwise will fill it with the contents specified at the top of the file. There’s no way to use conditionals (I assume).If you just leave it blank, or leave it out altogether, you get these errors:
Unable to load config info from /usr/lib/ssl/openssl.cnf
and respectively,
Error Loading request extension section v3_req 27687:error:2206D06C:X509 V3 routines:X509V3_PARSE_LIST:invalid null name:v3_utl.c:327: 27687:error:22097069:X509 V3 routines:DO_EXT_NCONF:invalid extension string:v3_conf.c:139:name=subjectAltName,section= 27687:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in extension:v3_conf.c:93:name=subjectAltName, value=
Good info. I’ve got alternative subjects on my list of things to do to handle the load-balancing of some LDAP services, and this is good info to have. Thanks for sharing.
Pingback: — Somewhere out there!
New at this. Not quite clear yet. Trying to add some subjectAltName. Here is my openssl config
[ req ]
default_bits = 1024
distinguished_name = req_DN
prompt = no
[ req_DN ]
countryName = US
stateOrProvinceName = Massachusetts
localityName = Charlestown
0.organizationName = MGH NMR Center
organizationalUnitName = Computing
commonName = NODENAME.DOMAINNAME
emailAddress = systems@nmr.mgh.harvard.edu
This works for our single name case and it doesn’t have a x509_extensions section.
What exactly goes where please?
Howdi,
FYI I have managed to get openssl to prompt for DNS alt names but including subjectAltName in the req_attributes section of openssl.cnf:
[ req_attributes ]
challengePassword = A challenge password
challengePassword_min = 4
challengePassword_max = 20
unstructuredName = An optional company name
# include a prompt for alternative names…
subjectAltName = Alternative DNS names (comma seperated list)
subjectAltName_default = DNS:myhost.com.au
Cheers
Josh
Thanks!!
That was what I was looking at, and I solve the removal by doing something like this:
…
if ! $SAN then
cat openssl.cnf | sed ‘/^subjectAltName/d’ > openssl-noalt.cnf
cnf=openssl-noalt.cnf
openssl csr … -config $cnf
…
This is part of a bunch of scripts I use to run my internal CA….
@ Josh
Genius, that worked on it’s own. Nothing else has worked until adding those entries under “req_attributes” section. Thanks very much.
@Josh, Chris:
“subjectAltName” belongs to the v3_req extension as mentioned in the article, therefore…
a) v3_req has to be enabled, either hard-coded by enabling it in the config file via “req_extensions = v3_req” inside the [ req ] or on-demand via the command line parameter “-reqexts v3_req”
b) its configuration values must to be specified in the [ v3_req ]section
Unfortunately there’s no real interactive prompt for it (just checked 1.0.1), that’s why the workaround was described in this article.