How Is The OpenSSL Configuration File Parsed?

Question

I'm trying to understand how OpenSSL parses its configuration file. In the sample configuration file that is installed with OpenSSL v1.1.1g, its seems to be divided into three main sections - the [ ca ] section, the [ req ] section, and the [ tsa ] section (because of the lines that contain ############# ... that separate these sections). Inside the [ ca ] and [ req ] sections there are key/value pairs whose name is a command option and whose value "links" to another section in the configuration file. A good example is the x509_extensions = usr_cert key/value pair in the [ ca ] section.

I am under the impression that the OpenSSL config file is processed by the OpenSSL parser starting at the first line of the file and processing the next line in turn (please correct me if that's not the case). Therefore, I would expect the [ ca ] section's x509_extensions = usr_cert to be linked to a section of the config file that occurrs inside the [ ca ] section. But it doesn't - it links to the [ usr_cert ] section that occurs inside the [ req ] section, which is outside the [ ca ] section.

So, what's happening when the OpenSSL parser processes the configuration file? Is my visual perception of inside and outside wrong when I read the configuration file? Does the parser "call" the linked section, process its key/value pairs, then return parsing of the config file to the next line in the config file? If this is the case, wouldn't it make it much easier to understand the structure of the config file if "links" to sections that pertained to the command whose section is being parsed were actually present within the command's section?

Answer 1

See man 5 config on your system or at https://www.openssl.org/docs/man1.1.1/man5/config.html .

I think you are being confused by your perception there is some nesting or hierarchy. There is not. ALL sections are at the same level, and are delimited solely by the [ name ] line. Lines consisting of ### are comments and ignored, and used only for visual clarity to the human reader. There is a [req] section and a [ca] section and a [usr_cert] section and more; none of these is 'within' any other, although an item in one section may refer to another section -- any other section -- if the code uses it as a section name. In fact the [ca] section is a stub that contains one item that points to another section, which in the upstream config is [CA_default]; this allows for keeping configurations of multiple CAs (perhaps a root and intermediate(s)) in one file if desired. If we look at the code for ca.c relevant to your example:

https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/apps/ca.c#L441:

    /* Lets get the config section we are using */
    if (section == NULL
        && (section = lookup_conf(conf, BASE_SECTION, ENV_DEFAULT_CA)) == NULL)
        goto end;

where BASE_SECTION is #define'd as "ca" and ENV_DEFAULT_CA as "default_ca", and conf is a variable pointing to the data structure set up by app_load_config() when it parsed the config file.

The variable section can be set by a command line option before this code is reached; if it wasn't we look in the [ca] section for the item default_ca = something and use that as the default.

https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/apps/ca.c#L781:

        if (extconf == NULL) {
            /*
             * no '-extfile' option, so we look for extensions in the main
             * configuration file
             */
            if (extensions == NULL) {
                extensions = NCONF_get_string(conf, section, ENV_EXTENSIONS);
                if (extensions == NULL)
                    ERR_clear_error();
            }
            if (extensions != NULL) {
                /* Check syntax of file */

where section and conf are the variables from above and ENV_EXTENSIONS is "extensions". Again the variable extensions can be set (independently) from the commandline, otherwise we look in the selected (as above) section of the config for the item "extensions = something" and use that value.

Later in the code it passes variable extensions as an argument to parameter ext_sect of certify() which in turn passes it to do_body() which uses it as the section name in which to find information about the extensions to add. There may be many such sections, which we can select among either using the configuration or commandline options. And many of the items in an extension section, like subjectAltName, can refer to yet another config section, usually with @name syntax; those are (at least mostly) documented in man 5 x509v3_config.