Mbed TLS is not thread-aware when built with the default configuration. Please see here for more info:
https://tls.mbed.org/kb/development/thread-safety-and-multi-threading

Please note that by not sharing contexts between threads the authors not only mean explicit context sharing between threads, but also implicit context sharing which happens when contexts refer to each other internally. The latter is the source of the following problem.

The current EPEL mbedtls package is built without defining MBEDTLS_THREADING_C and MBEDTS_THREADING_PTHREAD in config.h (default configuration). When being run, such a library does not have internal synchronization when accessing linked contexts internally from multiple threads even though a keen user has taken measures to protect their explicitly created contexts with mutexes or avoided sharing contexts altogether. This, in turn, leads to undefined behaviour, hard-to-debug TLS-related errors and possible state corruption which also means it can be exploited. Please see here for more info: https://github.com/ARMmbed/mbedtls/issues/3544

We believe that since Centos and Fedora are not embedded systems by default and since Mbed TLS is widely used as a server TLS library, it MUST be compiled with thread awareness.

The proposed solution would be to add the following lines to the RPM spec as it is done in Archlinux for example:
https://github.com/archlinux/svntogit-community/blob/packages/mbedtls/trunk/PKGBUILD

> # enable flags for non-embedded systems
> sed -i 's|//\(#define MBEDTLS_THREADING_C\)|\1|' include/mbedtls/config.h
> sed -i 's|//\(#define MBEDTLS_THREADING_PTHREAD\)|\1|' include/mbedtls/config.h

Another solution would be to have two distinct packages - with and without thread awareness - explicitly documented as such.