Configuration Example

The following example results in subject names like this:

Subject: C = DE, O = tk-sls, OU = Public Services, CN = tk-sls.de

The subject alternative names will be:

X509v3 Subject Alternative Name:
    DNS:tk-sls.de,DNS:www.tk-sls.de

First, we create a text file server.conf:

[req]
# Set the signature algorithm to "sha512WithRSAEncryption"
default_md = sha512

# Suppress interactive prompts during CSR generation
prompt = no

# Use section "[req_name]" for subject name information
distinguished_name = req_dn

# Use section "[req_ext]" for extended request information
req_extensions = req_ext

[req_dn]

# The static part of the subject name is the same for every request.
countryName = "DE"
organizationName = "tk-sls"
organizationalUnitName = "Public Services"

# The commonName component of the subject name is taken from an
# environment variable.
commonName = $ENV::FQDN

[req_ext]
# Note: Every line in this section is called an "extension" of the request.
 
# The SANs are derived from the value of commonName in section "[req_dn]".
subjectAltName = DNS:$req_dn::commonName,DNS:www.$req_dn::commonName

# Note: If the subject name was empty (which is allowed), the subjectAltName
# extension had to be marked "critical":
# subjectAltName = critical,DNS:$req_dn::commonName,DNS:www.$req_dn::commonName

# The following extensions configure the usage of the certificate for
# the purpose of "server authentication". Other possible uses such as
# "client authentication", "code signing" or "mail encryption" would
# require different settings.

# This is not a request for a CA certificate.
basicConstraints = critical,CA:FALSE 

# A legacy way of specifying the certificate usage; it is included here
# for compatibility with old CAs and client/server software; it is not
# mentioned by RFC 5280. 
nsCertType = server

# Crypographic operations that can be performed with this certificate;
# a TLS-verified and -secured server needs to sign and encipher keys
# (data encryption is performed by TLS using symmetrical keys, not using
# the private/public keys of the client- or server-certificates).
# Note RFC 5280 section 4.2 on consequences of marking this as critical. 
keyUsage = critical, digitalSignature, keyEncipherment

# The way of specifying the certificate usage mandated by RFC 5280.
# Note RFC 5280 section 4.2 on consequences of marking this as critical.
extendedKeyUsage = critical, serverAuth

# Some freetext comment taken from an environment variable
nsComment = "$ENV::COMMENT"

# When generating the request, a subject key identifer (SKI) should be
# computed as a hash of the public key. According to RFC 5280, this
# extension is only mandatory for CA certificates, but it is recommended
# for client/server-certificates as well; it can assist applications in
# identifying an entity's certificate. Note that specifying an SKI in a
# certificate signing request implies that the same SKI must be used
# when submitting a request for renewal of the certificate later on.
subjectKeyIdentifier = hash

This is a shorter version of server.conf without explanations:

[req]
default_md = sha512
prompt = no
distinguished_name = req_dn
req_extensions = req_ext

[req_dn]
countryName = "DE"
organizationName = "tk-sls"
organizationalUnitName = "Public Services"
commonName = $ENV::FQDN

[req_ext]
subjectAltName = DNS:$req_dn::commonName,DNS:www.$req_dn::commonName
basicConstraints = critical,CA:FALSE  
nsCertType = server
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = critical, serverAuth
nsComment = "$ENV::COMMENT"
subjectKeyIdentifier = hash