Apache ignores disable TLSv1.0

[David Favor]

None of these settings correctly disable TLSv1.0 as stated in Apache docs.
_______

# SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
# SSLProtocol -All TLSv1.2
# SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1

# SSLProtocol all -SSLv2 -SSLv3 -TLSv1
# SSLProtocol -all +TLSv1.2
# SSLProtocol TLSv1.2 -TLSv1
# SSLProtocol TLSv1.2
# SSLProtocol -All +TLSv1.1 +TLSv1.2

Likely the best setting is this, which will eventually pickup TLSv1.3+ when these protocols become available.

This also fails...

SSLProtocol all -SSLv2 -SSLv3 -TLSv1

[David Favor (davidfavor)]

Changes in SSLProtocol seem to be ignored.

This can be observed in all SSL testers I've used.

The testssl script provides an easy way to check this, without having to wait for minutes (like SSLLabs) for output.

Problem can be shown via...

testssl --protocols https://davidfavor.com/

Environment - Apache-4.2.5 + OpenSSL 1.0.2k + Ubuntu Yakkety.

My goal == disable TLS 1.0 for some of my hosting clients who have PCI requirements for this level of TLS to be disabled.

None of these permutations work. In fact, I can't find any SSLProtocol setting which changes protocols at all. In all cases SSL2 + SSL3 are disabled + all TLS versions are enabled.

Settings tried, that fail to disable TLSv1...

# SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
# SSLProtocol -All TLSv1.2
# SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1

# SSLProtocol all -SSLv2 -SSLv3 -TLSv1
# SSLProtocol -all +TLSv1.2
# SSLProtocol TLSv1.2 -TLSv1
# SSLProtocol TLSv1.2
# SLProtocol -All +TLSv1.1 +TLSv1.2

SSLProtocol all -SSLv2 -SSLv3 -TLSv1

[David Favor (davidfavor)]

Upstream bug opened...

https://bz.apache.org/bugzilla/show_bug.cgi?id=60739

[David Favor (davidfavor)]

Setting SSLProtocols to -all produces expected behavior, which is an error about no protocols.

This suggests the problem relates to setting TLSv1.2, which incorrectly seems to also enable TLSv1.1 + TLSv1.0 so maybe this is the real problem.

The following also fail disabling TLSv1.

# SSLProtocol all -SSLv2 -SSLv3 +TLSv1.2 -TLSv1
# SSLProtocol -all +TLSv1.2 -TLSv1

[David Favor (davidfavor)]

The following also works oddly.

SSLProtocol -all +TLSv1

This enables TLS 1.0 + 1.1 + 1.2 rather than just 1.0 as expected.

[Christian Ehrhardt  (paelzer)]

Thanks for your report David, I added the upstream bug to the tracker so that this bug automatically gets updates on its status.

[David Favor (davidfavor)]

You're welcome.

I haven't gone back through the recent patches + I'm guessing this is a fairly recent situation, as I'm fairly sure I was able to change this setting around version 2.4.18 + problem seems to have crept in around version 2.4.23 (best guess).

Thanks for scheduling this for a fix.

[David Favor (davidfavor)]

This seem to have changed somewhere between 2.4.18 + 2.4.23 as setting SSLProtocol use to be honored.

[David Favor (davidfavor)]

https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1665151 - related Ubuntu bug ticket.

[David Favor (davidfavor)]

Be great if someone from Ubuntu could verify this problem + update the upstream bug, so this problem can be resolved.

Thanks.

[Apache-bugzilla (apache-bugzilla)]

I have tested this with Apache 2.4.25 and OpenSSL 1.0.2k, with global settings and also with virtual host settings.

It works for me. For example, with "SSLProtocol -All +TLSv1.1 +TLSv1.2", TLS 1.0 is not possible, TLS 1.1 and TLS 1.2 are possible.

Could you please provide a minimal, stand-alone Apache configuration that shows the problem?

[David Favor (davidfavor)]

The problem seems to be an interaction between the Cipher List + SSLProtocol.

Depending on setting of Cipher List SSLProtocol seems to work or be ignored.

These settings disable TLSv1.0

# support old Android phones
SSLProtocol All -SSLv2 -SSLv3 -TLSv1

# Force using custom cipher list
SSLHonorCipherOrder on

Define sslCiphers -ALL:!ADH:!aNULL:!EXP:!EXPORT40:!EXPORT56:!3DES:!eNULL:!NULL:!RC4:!DES:!MD5:!LOW
Define sslCiphers ${sslCiphers}:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA
SSLCipherSuite ${sslCiphers}

Other sslCiphers settings cause SSLProtocol to be ignored.

I think the fix is either to have SSLProtocol cause a prune of sslCiphers settings or if there's a conflict between SSLProtocol + sslCiphers then have some sort of warning about the conflict.

All in all, the problem is far more complex than it appears on the surface.

For now, I'll resolve my situation by using the above settings.

[Covener-0 (covener-0)]

(In reply to David Favor from comment #6)
> The problem seems to be an interaction between the Cipher List + SSLProtocol.
>
> Depending on setting of Cipher List SSLProtocol seems to work or be ignored.
>
> These settings disable TLSv1.0
>
> # support old Android phones
> SSLProtocol All -SSLv2 -SSLv3 -TLSv1
>
> # Force using custom cipher list
> SSLHonorCipherOrder on
>
> Define sslCiphers
> -ALL:!ADH:!aNULL:!EXP:!EXPORT40:!EXPORT56:!3DES:!eNULL:!NULL:!RC4:!DES:!MD5:!
> LOW
> Define sslCiphers
> ${sslCiphers}:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-
> AES256-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-
> SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA
> SSLCipherSuite ${sslCiphers}
>
> Other sslCiphers settings cause SSLProtocol to be ignored.
>

Can you share a specific pair with unexpected results?

[Martin PANEL (mortin)]

I have similar issue. Whatever I set in SSLProtocol it's ignored.

apache2ctl -v
Server version: Apache/2.4.10 (Debian)
Server built: Feb 24 2017 18:40:28

openssl version
OpenSSL 1.0.1t 3 May 2016

If I use the settings provided by David Favor :

SSLProtocol All -SSLv2 -SSLv3 -TLSv1
SSLCipherSuite ALL:!ADH:!aNULL:!EXP:!EXPORT40:!EXPORT56:!3DES:!eNULL:!NULL:!RC4:!DES:!MD5:!LOW:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA

I got only TLSv1.2 enabled, not TLSv1.1.

I could find a way to activate TLSv1.1, with or without TLSv1. All the time, only TLSv1.2 (I tried a lot of different ciphers suite).

Note that if I try with the openssl s_server command, all is working as expected.

[Martin PANEL (mortin)]

Fix:
> I CANNOT find a way to activate TLSv1.1, with or without TLSv1. All the time, only TLSv1.2 (I tried a lot of different ciphers suite).

[David Favor (davidfavor)]

Per my other comment above, it appears SSLProtocol is strongly effected by SSLCipherSuite list.

This means SSLProtocol may or may not have any effect, based on SSLCipherSuite list.

Likely this is a complex fix, which might be accomplished by...

1) process SSLCipherSuite

2) then removed any SSLCipherSuite ciphers based on SSLProtocol setting

Simple to describe. Complex to implement.

Another solution might be to just deprecate the SSLProtocol setting.

This would mean SSLCipherSuite determines protocol selection, which appears to be what's actually occurring.

This would involve, removing all code related to SSLProtocol processing + updating documentation for SSLCipherSuite saying, protocols set derive from SSLCipherSuite list provided.

[Martin PANEL (mortin)]

The SSLCipherSuite seems has no effect on the protocol my side.
Whatever I put :

SSLCipherSuite ALL:!ADH:!aNULL:!EXP:!EXPORT40:!EXPORT56:!3DES:!eNULL:!NULL:!RC4:!DES:!MD5
or
SSLCipherSuite ALL
or
SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:DES-CBC3-SHA:HIGH:SEED:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!RSAPSK:!aDH:!aECDH:!EDH-DSS-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!SRP

I got no changes in protocol, only TLSv1.2 is enabled.

[Jchampion (jchampion)]

I'm also unable to reproduce. httpd 2.4.25, OpenSSL 1.0.2g -- the protocols are honored correctly with the example ciphersuite lines that have been given in this bug.

For those who can repro: can you please provide the exact set of configuration directives that reproduces the issue?

[Martin PANEL (mortin)]

Well, my bad... After trying to reproduce it on a dockerized version, I found I add a false config hidden.....

I confirm that I can use TLSv1.1 as well as TLSv1.2 with this simple config :
SSLProtocol all -SSLv3 -TLSv1
SSLCipherSuite HIGH:!aNULL

Server version: Apache/2.4.10 (Debian)
Server built: Feb 24 2017 18:40:28
OpenSSL 1.0.1t 3 May 2016

@David Favor : I'm not able to reproduce the issue (having TLS activated depends of ciphers). If you have a ciphers list with which you seen some protocols disabled, share us and I will try.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Brad Lanam (bll)]

The letsencrypt setup process adds the following line, which
includes SSLProtocol and SSLCipherSuite setup.
Quite annoying as a grep for SSLProtocol will not find it.

    Include /etc/letsencrypt/options-ssl-apache.conf

[Wrowe (wrowe)]

The ASF HTTP Server project has nothing to do with letencrypt distributed solutions. Comment #14 does not enhance this report.

(This is distinct from mod_md, which is httpd's response for users to provision letsencrypt certs.)

[Brad Lanam (bll)]

I was not entirely clear.
The letsencrypt configuration that gets installed will override any
SSLProtocol and SSLCipherSuite commands with their config.

I tried to get TLSv1 to turn off for a day before noticing the
additional configuration.

It is likely that other followers of this bug are having issues
configuring TLSv1 due to the letencrypt override.

[A-sklepas (a-sklepas)]

Hi, i can confirm the issue.
I have searched all configs and VHosts no overides are made it should work but
nmap --script ssl-enum-ciphers -p 443 IP | grep TLSv
returns TLS1.0, TLSv1.1

I also investigated the claims about letsencrypt:
Read this topic: https://community.letsencrypt.org/t/how-to-disable-tlsv1/49117/4
On some systems the options-ssl-apache.conf seems to be included in the virtual hosts.
"Include /etc/letsencrypt/options-ssl-apache.conf"

Anyway not in my case plus i have disabled the options in that file to be certain.
PS. Why are we waiting to fix this one? I do see servers that have disabled TLS1 btw...

My info: Apache/2.4.33

[Covener-0 (covener-0)]

(In reply to A.Sklepas from comment #17)
> Hi, i can confirm the issue.
> I have searched all configs and VHosts no overides are made it should work
> but
> nmap --script ssl-enum-ciphers -p 443 IP | grep TLSv
> returns TLS1.0, TLSv1.1
>
> I also investigated the claims about letsencrypt:
> Read this topic:
> https://community.letsencrypt.org/t/how-to-disable-tlsv1/49117/4
> On some systems the options-ssl-apache.conf seems to be included in the
> virtual hosts.
> "Include /etc/letsencrypt/options-ssl-apache.conf"
>
> Anyway not in my case plus i have disabled the options in that file to be
> certain.
> PS. Why are we waiting to fix this one? I do see servers that have disabled
> TLS1 btw...
>
>
> My info: Apache/2.4.33

Show a minimal configuration that does something unexpected if you can.

[A-sklepas (a-sklepas)]

Hi, unfortunately i cannot provide a minimal configuration.

I can give you more info as a run some more test in my two Centos 7 DS.

Server 1:

Apache/2.4.33 (IUS)*
latest Centos: Openssl 1.0.2k
TLS1 & 1.1 cannot be disabled

Server 2:
Server version: Apache/2.4.6 (CentOS)
latest Centos: Openssl 1.0.2k
TLS1 & 1.1 Disabled successfully.

I can understand this means an Apache issue. I am not sure if it is somehow an IUS issue, i will contact them too.
*https://dl.iuscommunity.org/pub/ius/stable/CentOS/7/x86_64/repoview/httpd24u.html

[David Favor (davidfavor)]

Somehow this has been fixed. Maybe a side effect of other fixes.

As of Apache-2.4.34 the following works.

SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1

[Aaronjchamberlain (aaronjchamberlain)]

While not relating to the discussion of certain SSLProtocol and SSLCipherSuite combinations halting desired SSLProtocols, I did want to add that I had an issue where Let's Encrypt was holding my desired changes back.

I was attempting to use the directive:
`SSLProtocols -all +TLSv1.1 +TLSv1.2` but TLSv1 was still being used. Due to this bug report I noticed that one of my upper Virtual Hosts was indeed using a cert from LE, and in that file they had a default of
SSLProtocol all -SSLv2 -SSLv3

If I could make a suggestion, it would be that we work towards getting more explicit control over what SSLProtocol directives get inherited. It seems strange that a file in a single Virtual Host reference would take precedence over global directives in both my ssl.conf and httpd.conf files.

[Steffn (steffn)]

@Aaron C: Let's Encrypt has nothing to do with your server configuration. You probably meant a config addition by an LE client, such as certbot?

[Aaronjchamberlain (aaronjchamberlain)]

@Stefan Yes. I'm using Certbot to manage my LE Certs, and Certbot makes those configuration changes automatically. All I'm saying is it would be really useful to have a command / flag that would simply state what directives are taking precedence for configuration, because situations like this arise where some mysterious configuration I had forgotten about took precedence over a global httpd.conf directive. If I could just run a command and it says "SSLProtocol: Inherited from line 20 in .../httpd.conf" would be the simplest way to be forwardly agnostic about where or how the server get's configured.

[Arne K. Haaje (a-arne)]

I can confirm this behaviour on 2.4.37 on two servers. I'm using these directives, and TLSv1.0 is still available

SSLHonorCipherOrder on
        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 !DES !IDEA !RC2"

SSLProtocol -All +TLSv1.1 +TLSv1.2

nmap --script ssl-enum-ciphers -p 443 xxx.xxx.xxx.xxx | grep TLSv
| TLSv1.0:
| TLSv1.1:
| TLSv1.2:

[Andrew Reis (areis422)]

BUMP.
Seeing this on 2.4.18 on Xenial

ii apache2 2.4.18-2ubuntu3.9 amd64 Apache HTTP Server
ii apache2-bin 2.4.18-2ubuntu3.9 amd64 Apache HTTP Server (modules and other binary files)
ii apache2-data 2.4.18-2ubuntu3.9 all Apache HTTP Server (common files)
ii apache2-utils 2.4.18-2ubuntu3.9 amd64 Apache HTTP Server (utility programs for web servers)

[Steffn (steffn)]

This is not a bucket for all possible improvement ideas about mod_ssl configurations. That is better discussed on the user/dev mailing lists.

As to the original report, I read the history of this as:
- not able to reproduce in a minimal set
- the effect of nested include files, some added maybe by a 3rd party tool, e.g. certbot that were not immediately obvious

We have no reproducible setup for the title of this ticket, " SSLProtocol settings seem to have no effect". Otherwise, it would be helpful to provide a minimum example setup.

Otherwise we will close this ticket. We are open to discussions and improvement proposals for making better server configurations. But those should take place on the mailing lists.

Thank you.

[Steffn (steffn)]

@David: going through this again, this looks like some intermittent issue with changes ported to ubuntu. And it seems to be fixed now?

Can we close this or what shall we look at? Thanks for your help!

[Thomas Knaller (tknaller)]

I have the ame issue on Debian 9.8 with apache2 2.4.25-3+deb9u6

[Dirk+apache (dirk+apache)]

I have a similar problem with Ubuntu 18.04 (Apache 2.4.39 + openssl 1.1.0g) and it maybe sheds some light into this.

Protocol is always

SSLProtocol -All +TLSv1.2

SSLCipherSuite

1) ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-GCM-SHA256

2) ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256

Diff is ECDHE-RSA-AES128-SHA256, ECDHE-RSA-AES128-SHA, DHE-RSA-AES128-GCM-SHA256.

I played a bit around with those three (using testssl.sh) and looked to me when I enable ECDHE-RSA-AES128-SHA I have TLS 1.0 + 1.1. Which seems strange to me but it's is what I found.

What is going on here?

Dirk

[Dirk+apache (dirk+apache)]

... same if I add ECDHE-RSA-AES256-SHA (c014 instead if c013).

[Dirk+apache (dirk+apache)]

... and two more ciphers which "break the TLS 1.2-only" syntax for me:

DHE-RSA-AES128-SHA 0x33
DHE-RSA-AES256-SHA 0x39

[Robie Basak (racb)]

Upstream has closed this bug as Incomplete, so I'm doing the same for Ubuntu. I think part of the problem here is that different people are reporting different underlying causes that lead to similar symptoms. See https://bz.apache.org/bugzilla/show_bug.cgi?id=60739#c25.

This particular bug now seems unfortunately unfixable because it isn't clear what exactly we'd be fixing, and others have chimed in with potentially different issues, muddling the whole affair.

If you'd like to see something specific fixed in Ubuntu, I suggest you file a new bug with *exact* steps to reproduce, including all commands and configuration file edits required to demonstrate the problem in Ubuntu, details of Ubuntu release and package versions used, and so on. Anyone commenting "me too" should also then make it absolutely clear which set of reproduction instructions were used.

[Thomas Knaller (tknaller)]

I found something in /etc/letsencrypt/options-ssl-apache.conf ...

[Thomas Knaller (tknaller)]

I found something in /etc/letsencrypt/options-ssl-apache.conf ...

[Johann (jnbl)]

Many thanks Thomas !
I was searching for hours why apache did not taking into account my SSL config.
It is because the letsencrypt config was applied before my virtualhost config.

[Robin Kluth (commifreak)]

I had the same problem - had!

It turns out, that the SSLCipherSuite list on the default vHopst (as reported of apachectl -D DUMP_VHOSTS) has to be capable of TLSv1.1 ciphers. It is also needed, that the default vHost has TLSv1.1 enabled in order to use that on other vHosts.

So, the default vHost is the key here. I cant believe that this should be correct. If I dont want to enable TLSv1.1 on the default but on the 3rd vHost, this must be working.

[Mattwalsh447 (mattwalsh447)]

I can confirm I also experienced this issue on the same versions as reported using Ubuntu 18.04 Server (Bionic)

In my instance I was using the a single virtual host with pre-defined certificate and there was no level of SSLProtocol setup vs SSLCipherSuite setting combination (described above) that would disable TLSv1 TLSv1.1, which are my (and probably many other peoples) security requirements.

I tried combinations of general SSL settings and down to virtual host level. No settings appeared to be honored regardless

In terms of 'what to fix'. Well I think there is enough information in the comments here to determine there is an issue between SSLProtocol and SSLCipherSuite, particularly as previous versions have been noted as working successfully.

I would also note that this relationship is NOT documented (that I can find) and if this is determined to be configuration related, then clearer documentation and examples need to be provided.

Clearly people are spending time on this issue, a quick google indicates this is a wide issue.

Unfortunately in my case I don't have any more time to spend working out what should be a 15 minute SSL setup on a web servers. I will be switching to using NGINX and this will be my preferred setup until this issue can be resolved either in fix or documentation.

[Tim (timkwh)]

Confirmed, many thanks Robin!

I had the same problem, even when I removed the ciphers above, TLS1.0 was still active.
I added a dummy default page whithout special cipher-suite and SSLProtocol configuration, with a subdomain, which is not registered on public DNS (snakeoil cert).
Now TLS1.0 dissapeared on my other virtualhosts.
I'm using Apache 2.4.38 (Debian 10)

Your post was really helpful to me, thanks a lot!

[Christian Ehrhardt  (paelzer)]

This all sounds interesting.
But since recently the openssl 1.1.1 bump has impacted a lot of things lets re-test with that.
BTW TLSv1.3 might come up in bug 1845263 soon.
I installed apache2 on 18.04 and 20.04 and will test on those which means:

18.04:
apache2: 2.4.29-1ubuntu4.11
openssl: 1.1.1-1ubuntu2.1~18.04.5

20.04:
apache2: 2.4.41-1ubuntu1
openssl: 1.1.1c-1ubuntu4

I used https://github.com/drwetter/testssl.sh to get a full info on the ssl features.

# Basic install of apache2 with SSL
$ apt install apache2
$ a2enmod ssl
$ a2ensite default-ssl
$ systemctl restart apache2
# at this point the default https site should work

Adding other VHosts on extra ports with SSL enabled
$ sed -e 's/443/444/' /etc/apache2/sites-enabled/default-ssl.conf > /etc/apache2/sites-available/custom1-ssl.conf
$ sed -e 's/443/445/' /etc/apache2/sites-enabled/default-ssl.conf > /etc/apache2/sites-available/custom2-ssl.conf
$ a2ensite custom1-ssl
$ a2ensite custom2-ssl
$ sed -i -e '/443/a Listen 444\nListen 445' /etc/apache2/ports.conf
$ systemctl restart apache2
$ apachectl -D DUMP_VHOSTS
VirtualHost configuration:
*:80 f.lxd (/etc/apache2/sites-enabled/000-default.conf:1)
*:444 f.lxd (/etc/apache2/sites-enabled/custom1-ssl.conf:2)
*:445 f.lxd (/etc/apache2/sites-enabled/custom2-ssl.conf:2)
*:443 f.lxd (/etc/apache2/sites-enabled/default-ssl.conf:2)

It is worth to note that with this default setup there only is the default of SSL mod configuring Ciphers and Protocols:

$ grep -Hirn -e '^\s*SSLCipher' -e '^\s*SSLProtocol' /etc/apache2/*
/etc/apache2/mods-available/ssl.conf:59: SSLCipherSuite HIGH:!aNULL
/etc/apache2/mods-available/ssl.conf:73: SSLProtocol all -SSLv3

Check via testssl like:
$ ./testssl.sh --protocols 10.253.194.57:444
 SSLv2 not offered (OK)
 SSLv3 not offered (OK)
 TLS 1 offered (deprecated)
 TLS 1.1 offered (deprecated)
 TLS 1.2 offered (OK)
 TLS 1.3 offered (OK): final
 NPN/SPDY not offered
 ALPN/HTTP2 http/1.1 (offered)

18.04 looks the same except TLSv1.3 not being there yet.

Now with that simple and clean setup in place lets disable TLSv1.0 per vhost.
$ sed -i -e '/SSL Protocol Adjustments/a SSLProtocol -All +TLSv1.2' /etc/apache2/sites-available/custom2-ssl.conf

That works well as expected disabling 1.0 and 1.1.
 SSLv2 not offered (OK)
 SSLv3 not offered (OK)
 TLS 1 not offered
 TLS 1.1 not offered
 TLS 1.2 offered (OK)
 TLS 1.3 not offered and downgraded to a weaker protocol
 NPN/SPDY not offered
 ALPN/HTTP2 http/1.1 (offered)

This works as well +1.3:
SSLProtocol -All +TLSv1.2 +TLSv1.3

I was trying the inverse:
SSLProtocol All -TLSv1 -TLSv1.1

Still working exactly as expected:
 SSLv2 not offered (OK)
 SSLv3 not offered (OK)
 TLS 1 not offered
 TLS 1.1 not offered
 TLS 1.2 offered (OK)
 TLS 1.3 offered (OK): final
 NPN/SPDY not offered
 ALPN/HTTP2 http/1.1 (offered)

Hmm, nothing of that indicates any error yet.
TLS 1.0 and 1.1 could easily be disabled.

Let me go into the further statements ont his bug:
1. "the SSLCipherSuite list on the default vHost (as reported of a...

[Christian Ehrhardt  (paelzer)]

I found that on the Debian bug nmap was used, for the sake of being different I tried like:
$ nmap --script ssl-enum-ciphers -p 444 10.253.194.57 | grep TLSv
But the results match what I have seen with testssl.sh

[Christian Ehrhardt  (paelzer)]

And as asked there this might help as well:
$ a2enmod info
$ systemctl restart apache2
$ apache2ctl -t -D DUMP_CONFIG|grep -i ssl
$ a2dismod info # if it hasn't been enabled before

That is a slightly better info than my Greps above, but still the same result.
Here of my last config trying to falsify the "default has to have TLSv1 to use it in others"

apache2ctl -t -D DUMP_CONFIG|grep -i ssl
# In file: /etc/apache2/mods-enabled/ssl.conf
Syntax OK
SSLRandomSeed startup builtin
SSLRandomSeed startup file:/dev/urandom 512
SSLRandomSeed connect builtin
SSLRandomSeed connect file:/dev/urandom 512
SSLPassPhraseDialog exec:/usr/share/apache2/ask-for-passphrase
SSLSessionCache shmcb:/var/run/apache2/ssl_scache(512000)
SSLSessionCacheTimeout 300
SSLCipherSuite HIGH:!aNULL
SSLProtocol all -SSLv3
# In file: /etc/apache2/sites-enabled/custom1-ssl.conf
  SSLEngine on
  SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
  SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
    SSLOptions +StdEnvVars
    SSLOptions +StdEnvVars
  SSLProtocol All -TLSv1 -TLSv1.1
# In file: /etc/apache2/sites-enabled/custom2-ssl.conf
  SSLEngine on
  SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
  SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
    SSLOptions +StdEnvVars
    SSLOptions +StdEnvVars
# In file: /etc/apache2/sites-enabled/default-ssl.conf
  SSLEngine on
  SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
  SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
    SSLOptions +StdEnvVars
    SSLOptions +StdEnvVars
  SSLProtocol All -TLSv1 -TLSv1.1

[- (imtiara)]

So when will a "solution" come or is there already one? if so, how? I'm just having a hard time to wrap my head around this.
I didnt have this issue before i did a yearly reset on my server ~3 weeks ago.
The support for TLSv1 & TLSv1.1 seems to end in 3 days and i need help get this solved asap.

Running Apache/2.4.6 (CentOS)

[Problem (pbsolver)]

This solved my problem - through SSL Labs I was getting B with all the attempts in putting anything - as soon as I updated the options-ssl-apache.conf file BOOM! we got A+ Rating

Brad you are awesome and I think all the commentators below and above should try this out before disqualifying it... I have Apache 2.18 for anyone interested latest version and still was a problem.

well not anymore.
Thanks again!

[Problem (pbsolver)]

Comment # 20 fixed my problem - people who disqualified it immediately need to pay attention!

[Problem (pbsolver)]

comment # 20 fixed the issue by updating the LetsEncrypt options file.

[Problem (pbsolver)]

Comment # 20 below fixed the issue - review the letsencrypt changes to the ssl.conf file and apache2 startup.

[somekool (somekool)]

I could disable TLS 1.0 and 1.1 and only enable TLS 1.2 + 1.3 by doing this

```
  SSLProtocol +TLSv1.2 +TLSv1.3
  SSLCipherSuite HIGH:!kRSA:!ADH:!eNULL:!LOW:!EXP:!MD5:!3DES
```

[Jonás Ballester (jabmaster)]

Apache + Debian here. I just run grep -rnw '/etc' -e 'SSLCipherSuite' and found that /etc/apache2/mods-available/ssl.conf was overriding even the /etc/letsencrypt/options-ssl-apache.conf file.

So I commented some lines in ssl.conf (of mods-available) and tweaked everything in options-ssl-apache.conf file.

Works like a charm now... Hope it's help you!