I tested on Ubuntu 12.04 (apache 2.2.22-1ubuntu1.4 and openssl 1.0.1-4ubuntu5.10) and Ubuntu 13.04 (apache 2.2.22-6ubuntu5.1 and openssl 1.0.1c-4ubuntu8.1).

here explain how to do so, but I have the following problems:

When try to use:

SSLProtocol all -SSLv2 -SSLv3 -TLSv1

I got the following error:

[error] No SSL protocols available [hint: SSLProtocol]

when try to use:

SSLProtocol TLSv1.1 TLSv1.2

I got the following error:

[error] No SSL protocols available [hint: SSLProtocol]

Th funny thing is that when I use:

SSLProtocol all -SSLv2 -TLSv1

apache don't complain and this test reported that my server not support SSLv2 and TLSv1.0, but yes SSLv3, TLSv1.1 and TLSv1.2.

Any explanation to that odd behavior? maybe the test tool is broken?

How can I enable just TLSv1.1 and TLSv1.2?

  • What are your SSLCipherSuite settings? – Rod MacPherson Oct 3 '13 at 20:27
  • Thanks for your reply @RodMacPherson SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 \ EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 \ EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS" as recommended here. – gsi-frank Oct 3 '13 at 20:38

(This is a software configuration issue, I sense a relocation to superuser.se coming up...)

There are two pre-requisites for this configuration to work:

  • Openssl-1.0.1 (yes)
  • httpd-2.2.23 (no!)

Sadly, the SSLProtocol documentation doesn't state the require httpd version (though it is noted in the comments section, right at the bottom of the page).

The code is a little convoluted: it iterates over the list of protocols it's aware of, and eliminates those that you didn't enable. This explains the behaviour you see.

The code up to and including httpd-2.2.22 does not parse "TLSv1.1" or later (see modules/ssl/ssl_engine_init.c and modules/ssl/ssl_private.h).

  • 1
    Thanks for your reply @mr.spuratic I think I found a way to disable TLSv1.0 and TLSv1.1: Setting SSLCipherSuite with just ciphers that are supported in TLSv1.2. – gsi-frank Oct 4 '13 at 15:27
  • Could you share your solution? – krinker Jun 28 '16 at 15:00
  • You could list the TLSv1.2 ciphers one by one (start with openssl ciphers -v | grep v1.2) or start with something like AESGCM:SHA384:SHA256:!aNULL:!eNULL:!DSS and tweak it as required. This effectively rejects <TLSv1.2 clients by requiring the newest ciphers/MACs. The downsides are that clients using an older protocol will fail with a misleading error ("no shared cipher" or handshake failure, instead of "wrong TLS version"), and you cannot support older multi-version ciphers at all, like AES128-SHA. So just upgrade already ;-) – mr.spuratic Jun 28 '16 at 16:50

Setting SSLCipherSuite with just ciphers that are JUST supported in TLSv1.2 bypass the Apache 2.2 limitation of parse TLSv1.1 string that @mr.spuratic talk about.


The openssl in ubuntu does not support TLSv1.2, They have disabled it. It is documented in bug 1256576

  • No, they only disabled TLS1.2 on the client side, not on the server side. And this is probably done because it broke things with older F5 devices. 1.0.1g now has a workaround for this which then breaks IronPort. Having fun with TLS today? – Steffen Ullrich Apr 16 '14 at 20:27
  • Yep, You are right. They at that time enabled TLS1.2 on server side only. Had a hard time figuring out a break in a lib which share some code for both server and client. – dlmeetei Mar 6 '15 at 6:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.