packer_dj
asked on
Is it possible to support TLS 1.1 on Centos 5.1?
I'm trying to connect to SalesForce on a Centos 5.1 box. The connection fails, due cURL attempting to connect over TLS 1.0. The current version of openSSL is 0.9.8; as I understand it, we need to update to at least openSSL 1.0.
Is that even possible?
Thanks,
_Dan
Is that even possible?
Thanks,
_Dan
ASKER CERTIFIED SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
I agree with David. It's WAY past time to get off CentOS 5. That version hasn't had any maintenance updates in over 3 years, so the only way to update it is by manually building from source, which would only solve one of your likely-many security problems at this point. You would still be on an ancient kernel unless you rebuilt that too. At a certain point, you're trying to save the Titanic by rebuilding every piece of it one at a time and then continually doing it for the rest of its "life."
If you rebuild on the latest version (8), you will automatically end up getting a version of OpenSSL that will support all the latest ciphers and protocols, including TLS 1.1 and later, although you shouldn't use anything less than TLS 1.2 at this point.
Plus, you'll be back at a point where you can use a simple yum update command to update the majority of the packages on the system.
If you rebuild on the latest version (8), you will automatically end up getting a version of OpenSSL that will support all the latest ciphers and protocols, including TLS 1.1 and later, although you shouldn't use anything less than TLS 1.2 at this point.
Plus, you'll be back at a point where you can use a simple yum update command to update the majority of the packages on the system.
To expand on my comment + Dr. Klahn + gr8gonzo.
Anything's possible, given infinite time + budget + will.
The real question revolves around your time + budget + will availability.
For example, you can build latest OpenSSL on CentOS 5.1 + likely OpenSSL will build.
The problem is, the latest OpenSSL API calls have likely had many changes since older versions, so this will trigger rebuilding...
PHP, curl, wget, Apache, MySQL... basically any code that uses OpenSSL.
So in essence, you'd be trying to rebuild RHEL 8.X software packages on top of the CentOS 5.1 Kernel (which is buggy + likely hackable).
Then each time any package updates, you'll have to go through this entire rebuild step again.
So the answer to "Is that even possible?"
Yes! And this will be a long + expensive + winding road.
Whereas installing RHEL 8.X or Ubuntu Focal (LTS) will be must faster, producing a stable end result.
Anything's possible, given infinite time + budget + will.
The real question revolves around your time + budget + will availability.
For example, you can build latest OpenSSL on CentOS 5.1 + likely OpenSSL will build.
The problem is, the latest OpenSSL API calls have likely had many changes since older versions, so this will trigger rebuilding...
PHP, curl, wget, Apache, MySQL... basically any code that uses OpenSSL.
So in essence, you'd be trying to rebuild RHEL 8.X software packages on top of the CentOS 5.1 Kernel (which is buggy + likely hackable).
Then each time any package updates, you'll have to go through this entire rebuild step again.
So the answer to "Is that even possible?"
Yes! And this will be a long + expensive + winding road.
Whereas installing RHEL 8.X or Ubuntu Focal (LTS) will be must faster, producing a stable end result.
The configuration is opaque and even after a successful build -- unless you know how the default OpenSSL was supplied in terms of directories -- you end up with two copies of OpenSSL, because the default configuration is never good enough for the operating system distro people and they put it into "their" directories. So you get the original version which was not replaced by the new version and lives where the system expects it, and the other version is the new one which lives in other directories where the system does not expect it.
Then you must (a) chase down and destroy the old version and move the new version into the expected directories, or (b) rebuild it into the correct directories, or (c) change the system PATH to add the new directories, or (d) for the remaining lifetime of the system do custom configures and builds of every software product that uses OpenSSL, pointing them at where the built OpenSSL resides.
Far easier to upgrade the operating system to a newer version which supports a later release of OpenSSL, and I'm not joking. Upgrading is a one-time pain that will go away. The fallout from building OpenSSL on an obsolescent system will haunt that system for the remainder of its operational life.