When working with OpenSSL certificate requests, most documentation focuses on DNS-based Subject Alternative Names (SANs). However, enterprise environments often require User Principal Names (UPNs) or Distinguished Names (DNs) for user certificates. The default OpenSSL configuration doesn't handle these out of the box.

The error message reveals the core issue:

Error Loading request extension section v3_req
5356:error:22075075:X509 V3 routines:v2i_GENERAL_NAME_ex:unsupported option
5356:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in extension

OpenSSL's standard configuration doesn't recognize UPN entries in the alt_names section because it's not part of the default GENERAL_NAME types.

To properly include UPNs in your certificate request, you need to:

[ req ]
default_bits = 2048
prompt = no
req_extensions = v3_req
distinguished_name = req_distinguished_name

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
subjectAltName = otherName:1.3.6.1.4.1.311.20.2.3;UTF8:xyz@example.com

[ req_distinguished_name ]
CN = User Common Name
O = Organization

For complex scenarios with mixed SAN types:

[ v3_req ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = server.example.com
otherName.1 = 1.3.6.1.4.1.311.20.2.3;UTF8:user1@example.com
otherName.2 = 1.3.6.1.4.1.311.20.2.3;UTF8:user2@example.com
email.1 = user@domain.com

Execute the following command after creating your config file:

openssl req -new -key private.key -out request.csr -config san_config.cnf

To confirm your UPN was properly included:

openssl req -in request.csr -noout -text | grep -A1 "Subject Alternative Name"

When working with OpenSSL to generate certificate signing requests (CSRs) that include non-DNS Subject Alternative Names (SANs), particularly for user certificates with User Principal Names (UPN) or Distinguished Names, developers often encounter limitations in the default configuration. The standard approach works well for DNS SANs, but requires special handling for other name types.

The error you encountered occurs because OpenSSL's default configuration doesn't automatically recognize UPN entries in the SAN section. Here's the correct way to configure this:

[req]
req_extensions = v3_req
distinguished_name = req_distinguished_name

[v3_req]
subjectAltName = @alt_names

[alt_names]
otherName.1 = 1.3.6.1.4.1.311.20.2.3;UTF8:xyz@example.com
email.1 = copy

With the proper configuration file (let's name it req.cnf), generate the CSR using:

openssl req -new -key private.key -out request.csr -config req.cnf

For more complex scenarios involving multiple non-DNS SANs, you might use:

[alt_names]
otherName.1 = 1.3.6.1.4.1.311.20.2.3;UTF8:xyz@example.com
otherName.2 = 1.3.6.1.4.1.311.20.2.3;UTF8:admin@example.com
email.1 = user@domain.com
email.2 = admin@domain.com

Always verify your generated CSR contains the expected SANs:

openssl req -in request.csr -noout -text

Windows Active Directory environments often require specific OIDs for UPNs:

• UPN OID: 1.3.6.1.4.1.311.20.2.3
• Microsoft SAN OID: 1.3.6.1.4.1.311.25.1