Cannot impact SSL config in apache

chronolith used Ask the Experts™
I have a virtual Debian web server running apache 2.2.22 with an ssl enabled vhost.  I am trying to disable SSLv3 and no matter what I do there seems to be no change when I rescan the website with Comodo or SSL labs.  I have tried editing:


... by either adding or changing the existing parameters for:

SSLHonorCipherOrder on
SSLProtocol all -SSLv3 -SSLv2

And after every change I run service apache2 restart

I also grep'd the /etc/apache2 directory for those ssl variables thinking they were coming from somewhere else but they are not.

Ultimately I am trying to switch the site over to TLS and dump SSLv3 but I just can't make an impact...
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Linux/LXD/WordPress/Hosting Savant
Distinguished Expert 2018
Where to start...

You've mentioned your running Debian + also Apache-2.2 which has reached EOL (End Of Life).

When a product reaches EOL there are no longer any security updates, so Apache will eventually become hackable.

My first suggestion, install latest Ubuntu as keeping software updated is easier because of Ubuntu packaging differences over Debian.

That said, to debug your problem.

First install inotify-tools + do this...

1) In one window run inotifywait -mrq /etc/apache2

2) In another window do service apache2 restart

3) Note all files accessed + make sure the Apache config files you think are being read, really are being read.

4) Do not ever, ever, ever muck about with the files...


Open in new window

This is a recipe for disaster, because these files can be over written by updates.

If you have, reinstall Apache from scratch + start over.

5) Do effect your SSL config by placing your entire SSL config into the VirtualHost stanza for your one site.

Once you've debugged your SSL setup, you can create custom include files for your SSL, never touching any files shipped with Apache.
Top Expert 2004
While running Debian is fine, the advice to upgrade your Apache is sound.

To discover which conf files are loaded by Apache, run "sudo apache2ctl -V".  In the output, you'll see something like this:
Server compiled with....
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D HTTPD_ROOT="/etc/apache2"
 -D SUEXEC_BIN="/usr/lib/apache2/suexec"
 -D DEFAULT_PIDLOG="/var/run/"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="mime.types"
 -D SERVER_CONFIG_FILE="apache2.conf"

Open in new window

The SERVER_CONFIG_FILE setting is the file being loaded, and it's location should be in HTTPD_ROOT.

Chances are you already have the correct conf file.  Instead of issuing a restart, try a full stop/start after making your changes.


Everything is as expected.  I tried to do as much prep as I could before posting the question so I apologize if I missed anything.

- inotifywait -mrq /etc/apache2 does confirm that it is in fact reading ssl.conf
- apachectl -V shows identical to the example posted by Steve Bink for HTTPD_ROOT and SERVER_CONFIG_FILE
- Stop and Start as opposed to restart brought no changes

I intend to upgrade the distribution from Wheezy to Jessie once the new year arrives.  Jessie's repositories standardize on Apache 2.4.  I just can't do anything that drastic right now while the holiday season is in the swing.

Putting all of the special configs in a separate include file is of course great advice and I intend to do that from now on, but all of my research to disable SSLv3 has people blithely editing the files directly and I followed suit.

I do know it is properly reading ssl.conf because I made a mistake by commenting out one of the SSLCipherSuite lines and the site failed saying that no ciphers were available.  Can there be arguments between the ciphers line and the protocols line?

Currently I have the SSLProtocol line calling only for TLSv1 but all of the external scans continue to report the SSLv3 is still supported...
Angular Fundamentals

Learn the fundamentals of Angular 2, a JavaScript framework for developing dynamic single page applications.

Top Expert 2004
Is it possible you have another virtual host still supporting SSLv3, and the scan is reading that one?
David FavorLinux/LXD/WordPress/Hosting Savant
Distinguished Expert 2018
You have the same setup I'm using. My /etc/apache2/global.conf starts out as...

ServerName net11-ubuntu-zesty-php72

SSLProtocol All -SSLv2 -SSLv3

SSLHonorCipherOrder on

Open in new window

Post your real URL, so people can run test tools against it. Maybe someone will turn up a fix.

Also, try this...

find /etc/apache2 -type f -exec egrep -il SSLProtocol {} \;

Open in new window

Then check all files returned to ensure some file isn't over riding your SSLProtocol setting.
David FavorLinux/LXD/WordPress/Hosting Savant
Distinguished Expert 2018
About your question...

Can there be arguments between the ciphers line and the protocols line?

Shouldn't be any problem with this, so long as you have no unintended over rides (multiple files with similar declarations).

And... something else to keep in mind...

Even if you have SSL3 enabled, this shouldn't be a problem if your OpenSSL library is up to date...

Because all modern OpenSSL releases completely disable SSL2 + SSL3 in so if you're seeing SSL3 show up in a tester, this likely means you have way more problems to deal with.

Running an version old enough to still contain SSL3 support means you may have many other bugs to deal with, like HeartBleed.

Best to also update to a recent version of OpenSSL before proceeding.


It's a fairly vanilla setup.  I have two virtual hosts that are being read, one for port 80 and one for port 443.

There are (were) only two files specifying SSL params like SSLProtocol.  I read somewhere that in apache 2.2 you had to add the values to the vhost config file additionally.  I tried adding those same params to the 443 virtual host config but they had no impact so I removed them.  The other is /etc/apache2/mods-available/ssl.conf.  Currently that is the only file with SSLprotocol specified.  Any changes to this file also have no impact on scans, at least in terms of the protocol.

I do not have a global.conf file at the root of apache2.  There is a apache2.conf file.  I tried adding the lines there, but also no change.  They were removed.

I'm not comfortable posting publicly a link to the server that is clearly still vulnerable.  I will be happy to share it individually though.

Thanks very much for your insights so far.


OpenSSL version is 1.0.1t-1+deb7u3


Possible culprit:  The Forefront TMG firewall sitting in front of this web server.  I have added registry values to disable SSLv3 but won't be able to reboot it until off hours.
btanExec Consultant
Distinguished Expert 2018
Probably do a test without the proxy. I have such issue with proxy as it fronts all traffic to Internet. This is beyond my reach since it is not owned by my team.

To check if you have disabled the SSLv3 support, then run the following

openssl s_client -connect -ssl3
(replace the domain with the actual origin web server ip address. Do have firewall rule configured to allow from your test client)

which should produce something like
3073927320:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1258:SSL alert number 40

3073927320:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596:
meaning SSLv3 is disabled on the server. Otherwise the connection will established successfully.

Alternatively, you can use nmap to scan server for supported version:

# nmap --script ssl-enum-ciphers
Starting Nmap 6.47 ( ) at 2014-10-15 03:19 PDT
Nmap scan report for (
Host is up (0.090s latency).
rDNS record for
Not shown: 997 filtered ports
80/tcp  open  http
443/tcp open  https
| ssl-enum-ciphers:
|   **SSLv3: No supported ciphers found**
|   TLSv1.0:


Turns out it was mostly about the ForeFront TMG firewall.  I did have to line up the protocols and ciphers between my apache server and ForeFront but everything fell into place at that point.

In case anyone else comes along needing similar help please have a look at these articles:

Disabling protocols in ForeFront via regedit:

Enforcing cipher suite order:

Richard Hicks' blog is a good resource for this.

Thanks all.
btanExec Consultant
Distinguished Expert 2018
Thanks for sharing.
In fact I also recommend the use of IISCRYPTO tool which is handy for such case of checking and setting the cipher suite or using the best practice template that comes with it to address the vulnerable ciphers in Windows system.
btanExec Consultant
Distinguished Expert 2018

For author advice
btanExec Consultant
Distinguished Expert 2018

For consideration

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start Today