### 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()`.