49
3.3.2 Building an OpenSSL Configuration File
One more file still needs to be created, but it is significantly more complex than the first two files that weve already created. It is a configuration file that will be used by the OpenSSL command-
line tool to obtain information about how to issue certificates. We could conceivably skip creating this file and use the OpenSSL defaults, which are actually quite sane, but by using a configuration
file, we save ourselves some work in issuing commands to OpenSSL. We briefly discussed configuration files and their use with the command-line tool in the
Chapter 2 . Now its time to
actually create a configuration file of our own and put it to use. The OpenSSL command for the CA functions is aptly named
ca
, and so the first section that were interested in is named
ca
. For our purposes, this section is quite simple, containing only a single key:
default_ca
. The value is the name of a section containing the configuration for the default CA. OpenSSL allows for multiple CA configurations in the same configuration file. If the name of
a configuration to use is not specified, OpenSSL uses the name paired with the
default_ca
key. The default can be overridden on the command line with the
name
option. Example 3-2
shows the configuration file for our CA. Weve already explained what the files and directories weve created are for, so the first set of keys in the example should be clear; were
simply telling OpenSSL where weve decided to place the files and directories that it needs to use. The three keys,
default_crl_days
,
default_days
, and
default_md
, correspond to the command-line
crldays
,
days
, and
md
options, and may be overridden by using them. The
default_crl_days
key specifies the number of days between CRLs. You may wish to use
default_crl_hours
instead if you plan to publish CRLs more than once a day. This setting computes the
nextUpdate
field of the CRL when it is generated. The
default_days
key specifies the number of days an issued certificate will be valid. The
default_md
specifies the message digest algorithm that will be used to sign issued certificates and CRLs. Possible legal
values for this key include
md5
,
sha1
, and
mdc2
. The
policy
key specifies the name of a section that will be used for the default policy. It may be overridden on the command line with the
policy
option. A policy definition is a set of keys with the same name as the fields in a certificates distinguished name. For each key or field, there are
three legal values:
match
,
supplied
, or
optional
. A value of
match
means that the field by that name in a certificate request must match the same field in the CAs certificate. A value of
supplied
means that the certificate request must contain the field. A value of
optional
means that the field is not required in the certificate request.
By default, when a certificate is issued, OpenSSL orders the DN distinguished name fields in the same order as they appear in the policy definition being used. Any fields that are present in the
certificate request but not present in the policy definition are omitted from the issued certificate. This behavior can be changed by using the
preserveDN
option or by setting the
preserve
key to
yes
in the CA definition section. When this option is set, all of the fields in the certificate request are included in the issued certificate, and they remain in the same order as they were in the
certificate request. Ordinarily, you should not need to enable this option unless youre dealing with older versions of Microsoft Internet Explorer, which require the fields in the issued certificate to
match the certificate request. If youre dealing with very old versions of Microsoft Internet Explorer, you may also need to enable the MSIE hack either by using the
msie_hack
option or by setting the
msie_hack
key to
yes
in the CA definition section. The
x509_extensions
key specifies the name of a section that will contain the extensions to be added to each certificate issued by our CA. If this key is absent, OpenSSL creates an X.509v1
certificate, but if it is present, even if it is empty, an X.509v3 certificate is created. The only extension that weve included in our example is the
basicConstraints
extension, and weve set its
cA
component to false so that the certificates issued by our CA, in turn, may not be used as
TE AM
FL Y
Team-Fly
®
50
CA certificates. The certificate chain stops with certificates that we issue. Example 3-2
shows the configuration file.
Example 3-2. A simple CA configuration definition
[ ca ] default_ca = exampleca
[ exampleca ] dir = optexampleca
certificate = dircacert.pem database = dirindex.txt
new_certs_dir = dircerts private_key = dirprivatecakey.pem
serial = dirserial default_crl_days = 7
default_days = 365 default_md = md5
policy = exampleca_policy x509_extensions = certificate_extensions
[ exampleca_policy ] commonName = supplied
stateOrProvinceName = supplied countryName = supplied
emailAddress = supplied organizationName = supplied
organizationalUnitName = optional [ certificate_extensions ]
basicConstraints = CA:false
Now that weve created a configuration file, we need to tell OpenSSL where to find it. By default, OpenSSL uses a system-wide configuration file. Its location is determined by your particular
installation, but common locations are usrlocalssllibopenssl.cnf or usrsharesslopenssl.cnf. Since weve created our own configuration file solely for the use of our CA, we do not want to use
the system-wide configuration file. There are two ways to tell OpenSSL where to find our configuration file: using the environment variable
OPENSSL_CONF
, or specifying the filename with the
config
option on the command line. Since we will issue a sizable number of commands that should make use of our configuration file, the easiest way for us to tell OpenSSL about it is
through the environment see Example 3-3
.
Example 3-3. Telling OpenSSL where to find our configuration file
OPENSSL_CONF=optexamplecaopenssl.cnf export OPENSSL_CONF
3.3.3 Creating a Self-Signed Root Certificate