openssl: generate certificate request with non-DNS subject alternative names

Question

To create a certificate request containing subject alternative names (SANs) for a host, with openssl, I can use a config file like this (snipped):

[req]
req_extensions = v3_req
[ v3_req ]
subjectAltName = @alt_names
[alt_names]
DNS = xyz.example.com

If I need to provide a distinguished name or a user principal name, how should I configure the alt_names section for a user certificate request?
For example, I tried

[alt_names]
UPN = xyz@example.com

But I got this error:

Error Loading request extension section v3_req
5356:error:22075075:X509 V3 routines:v2i_GENERAL_NAME_ex:unsupported option:.\crypto\x509v3\v3_alt.c:557:name=userPrincipalName
5356:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in extension:.\crypto\x509v3\v3_conf.c:93:name=subjectAltName, value=@alt_names

Answer 1

After trying some options (thanks Jenny) I just checked the source code, and discovered that the configuration file expects one of these values:

• email
• URI
• DNS
• RID
• IP
• dirName
• otherName

So in my case I wrote

[alt_names]
email = xyz@example.com

And openssl generated the request file.

Answer 2

You can specify pretty much anything that your CA allows.

The relevant RFC is RFC5280. It says in section 4.2.1.6. "Subject Alternative Name"

The subject alternative name extension allows identities to be bound to the subject of the certificate. These identities may be included in addition to or in place of the identity in the subject field of the certificate. Defined options include an Internet electronic mail address, a DNS name, an IP address, and a Uniform Resource Identifier (URI). Other options exist, including completely local definitions. Multiple name forms, and multiple instances of each name form, MAY be included. Whenever such identities are to be bound into a certificate, the subject alternative name (or issuer alternative name) extension MUST be used; however, a DNS name MAY also be represented in the subject field using the domainComponent attribute as described in Section 4.1.2.4. Note that where such names are represented in the subject field implementations are not required to convert them into DNS names.

You should read the rest of that section, and then check with your CA what they support. It's worth noting that your CA must verify that all subject alternative names are correct.

To use an email address, the RFC says in section 4.1.2.6

Conforming implementations generating new certificates with electronic mail addresses MUST use the rfc822Name in the subject alternative name extension (Section 4.2.1.6) to describe such identities. Simultaneous inclusion of the emailAddress attribute in the subject distinguished name to support legacy implementations is deprecated but permitted.

So instead of UPI, you should use rfc822Name.

Answer 3

Make sure when using @alt_names that the section is [alt_names] and not [alt _names].