Technical Background

About X.509 CSRs in general:

• The makeup of X.509 certificates (including signing request for them) is specified in RFC 5280.
• Some specific properties of requests and certificates are influenced by practical implementations (i.e. real-life requirements and conventions of PKI systems and client/server software).
• Values that can be controlled in the request are:
  • A subject name,
  • a list of subject alternative names (SANs),
  • the key usage (in our case „Server Authentication“) and
  • an optional freetext comment providing further information about purpose or subject of server or service.
• Not under control of the request is the validity period of the certificate: The CA decides the point in time when the validity of the signed certificate starts and ends. However, in many cases there exist sidechannel means to specify a desired validity period:
  • If requesting from a commercial entity, a desired validity period can usually be specified as part of the certificate order process.
  • If requesting from a noncommerical, organizational or self-signed entity, the CAs often apply a sort of „certificate template“, stating (amongst other default properties) a validity period (in days).

Notes about the subject name:

• The subject name is a list of components in the form $KEY=$VALUE, spearated by commas, for example:

Subject: organization = tk-sls, organizationalUnit = Public Services, commonName = tk-sls.de

• The subject name in a signing request „uniquely identifes“ an „entity“ (terminology taken from the RFC) that is to be certfied by a CA this request is commited to.
• If it is not empty, then the subject name must be an ITU X.500 distinguished name (DN) following the definition of „Name“ given by ITU X.501, using selected attributes as defined by ITU X.520. In practise, component keys that can be used are specified by RFC 5280 section 4.1.2.4 („Issuer“):
  • The following name attributes must be supported by every CA: countryName, organizationName, organizationalUnitName, dnQualifier, stateOrProvinceName, commonName (in our case, this would be the FQDN of the server) and serialNumber.
  • The following name attributes should be supported (i.e. their support by CAs is not mandatory): localityName, title, surname, givenName, initials, pseudonym and generationQualifier.

Notes about subject alternative names, SANs:

• SANs are a set of names that a certificate is valid for.
• For a server authentication certificate, the SANs should be the DNS names that the server can be contacted via a TLS-secured protocol in a manner verifying the servers authenticity.
• When generating the request for a server authentication certificate, each of the server’s DNS names must be denoted in the form DNS:..., and they will form a comma-separated list. The order of the SANs in this list is not relevant.
• Certificates for DNS names must specify every DNS name in their list of subject alternative names. Only SANs allow for the DNS:... notation that explicitly states that the name is a DNS name, while the commonName component of the subject name can be ambiguous (it could be a personal or a company name or something else unrelated to the technical authentication function).

Notes about extensions being marked as „critical“:

• RFC 5280 Section 4.2 states:
  „Each extension in a certificate is designated as either critical or non-critical.“
  It also states:
  „A certificate-using system MUST reject the certificate if it encounters a critical extension it does not recognize or a critical extension that contains information that it cannot process.“
  and:
  „A non-critical extension MAY be ignored if it is not recognized, but MUST be processed if it is recognized.“
• Furthermore, according to RFC 5280 Section 4.2.1.6: If naming information as part of the request is only to be given as one or more subject alternative names, then the subject name must be empty and subjectAltName must be marked as „critical“ (see the request configuration file below for an example).