#include
void OPENSSL_config(const char *config_name); void OPENSSL_no_config(void);
_O_P_E_N_S_S_L___n_o___c_o_n_f_i_g_(_) disables configuration. If called before _O_P_E_N_S_S_L___c_o_n_f_i_g_(_) no configuration takes place.
It is also possible to automatically call _O_P_E_N_S_S_L___c_o_n_f_i_g_(_) when an application calls _O_P_E_N_S_S_L___a_d_d___a_l_l___a_l_g_o_r_i_t_h_m_s_(_) by compiling an application with the preprocessor symbol OOPPEENNSSSSLL__LLOOAADD__CCOONNFF #define'd. In this way configuration can be added without source changes.
The environment variable OOPPEENNSSSSLL__CCOONNFF can be set to specify the location of the configuration file.
Currently ASN1 OBJECTs and ENGINE configuration can be performed future versions of OpenSSL will add new configuration options.
There are several reasons why calling the OpenSSL configuration routines is advisable. For example new ENGINE functionality was added to OpenSSL 0.9.7. In OpenSSL 0.9.7 control functions can be supported by ENGINEs, this can be used (among other things) to load dynamic ENGINEs from shared libraries (DSOs). However very few applications currently support the control interface and so very few can load and use dynamic ENGINEs. Equally in future more sophisticated ENGINEs will require certain control operations to customize them. If an application calls _O_P_E_N_S_S_L___c_o_n_f_i_g_(_) it doesn't need to know or care about ENGINE control operations because they can be performed by editing a configuration file.
Applications should free up configuration at application closedown by calling _C_O_N_F___m_o_d_u_l_e_s___f_r_e_e_(_).
It is however mmuucchh better than nothing. Applications which need finer control over their configuration functionality should use the configuration functions such as _C_O_N_F___l_o_a_d___m_o_d_u_l_e_s_(_) directly.