### Description When using HSM keys (via OpenSSL engine) the engine and private keys are loaded in the child processes since PKCS#11 modules rarely survive `fork()`. With OpenSSL 1.1.1 and the call to `OPENSSL_init_ssl()` in `tls_init.c` the engine linked-list is now initialized in the master process. Subsequently the technique used in `tls_init.c:660 CONF_modules_load_file()` will fail as each child process manipulates the linked-list. Even if the engine linked-list manipulation itself is protected by global locks; traversing the linked-list will encounter invalid memory locations as the nodes are insert by other child processes. This issue is filed as a marker; I will be providing patches to change the way HSM private keys are loaded in the child process to avoid linked-list corruption. ### Troubleshooting - use soft (PEM) keys — no issue as OpenSSL engine is not relevant in this context #### Reproduction - configure TLS with OpenSSL engine key(e.g pkcs11 engine with SoftHSM keys) ### Additional Information Root cause: the function `CONF_modules_load_file()` will configure OpenSSL engines from a OpenSSL configuration file but it also adds each engine to the global linked list. Unfortunately there is no OpenSSL function to reset the linked-list in the child process. It seems to be initialized once at start-up: the linked-list head/tail pointers are static variables and their initialization is protected by OpenSSL's `RUN_ONCE` mechanism, so it doesn't seem it supported mechanism to have them reinitialized after `fork()`. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2839