Configuring ssl requests with SubjectAltName with openssl

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 “,,” 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 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


And in [ v3_req ] I added:


So if you run openssl like this:

SAN="," \
  openssl req -new -key -out

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=

7 thoughts on “Configuring ssl requests with SubjectAltName with openssl

  1. Jason

    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.

  2. Pingback: — Somewhere out there!

  3. Chris J.

    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
    emailAddress =

    This works for our single name case and it doesn’t have a x509_extensions section.

    What exactly goes where please?

  4. Josh

    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 =


  5. Casper


    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

    openssl csr … -config $cnf

    This is part of a bunch of scripts I use to run my internal CA….

  6. Maddes

    @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.

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload the CAPTCHA.