Building an OpenSSL Configuration File

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