OPENSSL_CONFIG(3ossl)
π OPENSSL_config, OPENSSL_no_config β the O.G. "just call it and forget it" config girls
okay so bestie, welcome to the 3ossl corner of the OpenSSL manual β¨ this one's about the two simplest little config functions OpenSSL ever made, and yes they're deprecated, and yes we're still gonna learn them because HISTORY matters π
πΈ NAME πΈ
OPENSSL_config, OPENSSL_no_config β simple OpenSSL configuration functions. That's the whole vibe. lowkey does what it says on the tin π
β¨ SYNOPSIS β¨
First, the include, obviously:
#include <openssl/conf.h>
now the part where I hold your hand: these functions have been deprecated since OpenSSL 1.1.0, and you can hide them entirely by defining OPENSSL_API_COMPAT with a suitable version value β check openssl_user_macros(7) for the deets π
void OPENSSL_config(const char *appname);
void OPENSSL_no_config(void);
π DESCRIPTION π
OPENSSL_config() configures OpenSSL using the standard openssl.cnf and reads from the application section appname. If appname is NULL, then the default section, openssl_conf, gets used instead. Errors? Silently ignored π and multiple calls have no effect β it's giving "one and done."
OPENSSL_no_config() disables configuration. If you call it before OPENSSL_config(), then no configuration takes place. periodt.
Also, important lil detail: if the application is built with OPENSSL_LOAD_CONF defined, then a call to OpenSSL_add_all_algorithms() will implicitly call OPENSSL_config() first. sneaky but true π§
π₯ NOTES π₯
so OPENSSL_config() is designed to be a very simple "call it and forget it" function. It is however much better than nothing β like, a solid participation trophy π
Applications which need finer control over their configuration functionality should use the configuration functions such as CONF_modules_load() directly. This function is deprecated and its use should be avoided. Applications should instead call CONF_modules_load() during initialization (that is before starting any threads). no cap, do it before the threads start π
There are several reasons why calling the OpenSSL configuration routines is advisable. For example, 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 OPENSSL_config() it doesn't need to know or care about ENGINE control operations because they can be performed by editing a configuration file. it's giving "let the config file handle it, bestie" π
π ENVIRONMENT π
OPENSSL_CONFβ the path to the config file. Ignored in set-user-ID and set-group-ID programs. nosy programs don't get to pick their own config π ββοΈ
π¦ RETURN VALUES π¦
Neither OPENSSL_config() nor OPENSSL_no_config() return a value. Literally nothing. void. the silence is the answer π
β SEE ALSO β
config(5), CONF_modules_load_file(3) β go read those next, iykyk π«Ά
π HISTORY π
The OPENSSL_no_config() and OPENSSL_config() functions were deprecated in OpenSSL 1.1.0 by OPENSSL_init_crypto(). and that's the tea π
π COPYRIGHT π
Copyright 2004-2020 The OpenSSL Project Authors. All Rights Reserved.
Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.
π okay that's the whole page! no secrets, no skipped flags, we kept everything.
and that's a wrap, bestie β this lil writeup is from the OpenSSL 3.5.0 manual, dated 2026-09-25 π¦ mwah π
π¦ where this page comes from
- opensuse-leap 16.0: openssl-3-doc 3.5.0-160000.11.1 Β· Apache-2.0
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms