RHEL5 won't support TLSv1.1 or higher

We found the version of curl provided for RHEL5 does not include the flags "--tlsv1.1" or "--tlsv1.2" provided by later versions of curl.

This means CentOS5 curl does not include/support the flags "--tlsv1.1" or "--tlsv1.2".

RHEL7 and RHEL6 versions do support TLSv1.1 and TLSv1.2 and work when using them. One might need to run yum update for curl and/or openssl to have the versions with the support. On my RHEL6 systems I had to update curl.

I went through an exercise on a CentOS5 test system yesterday to install latest upstream (i.e. not RedHat provided) curl version 7.47. This required a fair amount of effort owing to other libraries that also had to be installed and/or updated (which in itself is good reason not to try this). The result was I did get a curl binary that had the flags but it immediately failed to access a site when using the flags giving error:

curl: (35) Unsupported SSL protocol version

The cause of this error is that curl relies on the version of openssl installed. It isn't really feasible to update openssl on RHEL5 (or CentOS5) due to the number of other things that depend on it. (Some people will tell you to try a alternate path openssl installation but I didn't because it's not really a good idea for various reasons.)

I opened a case to RedHat after my research and they confirmed that they do not intend to add TLSv1.1 and higher support to RHEL5 (so it won't be in CentOS5 or other derivations either). RedHat regards it as a feature change rather than a bug and RHEL5 being over 10 years old is now in Phase 3 support. Also they state that it isn't really possible to update openssl for the same reasons I'd found in my research.

RedHat's discussion is at:
https://access.redhat.com/solutions/1609823

One work around might be try doing "ssh <rhel6_or_rhel7_server> 'curl --tlsv1.1 <site>' from your RHEL5 server. (Or centos# etc...).

A better plan is to start moving off of RHEL5/CentOS5 if you haven't already.

Edit 05-Sep-2016:
Just wanted to note after I wrote this original blog post we had another vendor move to TLSv1.2. Initially even though we tested access via a RHEL6 system it didn't work. I found that the curl version there hadn't been updated to provide the --tlsv1.2 flag so a simple "yum update curl" worked.

However, I still had errors reaching the new site from RHEL6 after that and found the issue was the ciphers rather than the tls version. The cipers were updated on the RHEL6 box using "yum update nss".

Edit 23-May-2017:
I recently ran into an issue on RHEL6 where lftp going to an ftps site (ftps uses SSL certificates like https does) was having an issue due to TLSv1.1 or TLSv1.2 not working. It turned out lftp is built using gnutls instead of openssl so I had to update the gnultls package to get the support for TLSv1.1 and higher even though I'd previously done the other updates mentioned above.

Edit 03-Jul-2018:
We just ran into an issue where one of our few remaining RHEL5 servers suddenly quit relaying through our MS Exchange Hybrid servers. In /var/log/maillog we were seeing:
stat=Deferred: 403 4.7.0 TLS handshake failed

The RHEL5 server is running Sendmail. It turns out that by default Sendmail is attempting secure connection based on TLS which of course is TLSv1.0 as noted in original blog post.
The MS Admins have just disabled TLSv1.0 on the Hybrid servers.

Reading this morning confirmed if it fails TLS Handshake it does NOT fall back to simple text for SMTP relaying as one might think.

The solution was to modify /etc/mail/access and add a line:
Run "make -C /etc/mail" to recompile the files in /etc/mail including access into access.db. (There is a command to just do access but I usually do the entire directory.)
Run "service sendmail restart"

That not only made it work but it delivered the emails it had deferred due to the handshake issue since 28-Jun-2018 today 03-Jul-2018.