Both subjects and subject alternative names can be built up from fields in submitted certificate sign requests, fields from the submitted form, or Apache httpd expressions, or any combination thereof.

The order of the directives controls the order that the components of the subjects or subject alternative names appear in the resulting certificate.

It is possible to pass through all fields in a submitted certificate sign request using a wildcard, or to explicitly set each component individually as needed.

The components of subjects can be specified as OID values, or their well known aliases.

The components of subject alternative names are limited to the following:

The trivial case: pass all fields of a certificate sign request through unmodified.

<IfModule mod_scep.c>
    # pass all elements of the subject through unmodified
    ScepSubjectRequest *
</IfModule>

The simple case: set the fields of a subject to fixed expressions.

All fields in the submitted certificate sign request or form parameters will be ignored.

<IfModule mod_csr.c>
    # set the common name to an expression
    # resolving to the current logged in user
    CsrSubjectSet CN %{REMOTE_USER}
    CsrSubjectSet OU People
    CsrSubjectSet DC example
    CsrSubjectSet DC com
</IfModule>

Embed fields from the client: Allow the client to choose values for given fields.

In this example it is possible for two callers to choose the same common name value. It is assumed here that the intended application would be capable of disambiguating the certificates using the serial number of the certificate. Alternatively the Request Authorization hook could be used to issue certificates for subjects that were arranged in advance, or to enforce a first come first served scenario.

<IfModule mod_pkcs12.c>
    # allow the client to set their common name
    Pkcs12SubjectRequest CN
    Pkcs12SubjectSet OU Devices
    Pkcs12SubjectSet DC example
    Pkcs12SubjectSet DC com
</IfModule>