Would not work correctly on a RedHat 6.x system?įor the record the customer has tried with OpenSSL 1.1.1g and 1.1.1k with What I'm wondering is, would there be a technical reason why OpenSSL 1.1.1 To run side-by-side the system installation. However it is still possible to install later OpenSSL versions I know that RedHat certainly doesn't ship recent versions of OpenSSL for We have successfully tested our product on CentOS 7.x servers.

Initial testing by the customer is showing segmentation faults in OpenSSL Our product uses OpenSSL 1.1.1 to handle secure connections. Also, this approach may provide a more stable OpenSSL code base compared to maintaining a separate fork of OpenSSL.We have a customer who is running our product on a RedHat 6.x server. Such an approach may require much less development effort than maintaining a fork of an older OpenSSL code base. When switching to one of these distributions' OpenSSL code, the user also benefits from an active maintenance of the code base including addressing of any security-relevant or non-security-relevant bugs. When using an OpenSSL version from these distributions, applications may hardly need any changes when they already link to the standard OpenSSL version 1.1.1.

The resulting OpenSSL 1.1.1 versions provided by the mentioned distributions attempt to be API (Application Program Interface) and ABI (Application Binary Interface) compatible to the standard OpenSSL 1.1.1 library and yet utlize FIPS 140-2 compliant cipher implementations. These distributions took the OpenSSL 1.1.1 standard code base and forward-ported all FIPS 140-2 patches. A more practical solution could be to switch to the OpenSSL versions made available by the Linux distributions Red Hat Enterprise Linux (RHEL) 8, SUSE Linux Enterprise Server (SLES) 15 or Ubuntu 18.04.

Openssl latest version for rhel 7