I’ve been searching and testing for a couple of days now and have run out of things to try. Here’s my problem. I have an Apache Lounge 2.4.18 (Win32) VC14 web server running on a Microsoft Windows 2008 R2 server using OpenSSL 1.0.2g. Our corporate security team scanned my server and detected that RC4 is being utilized. (They used Nexpose from Rapid7). They recommended configuring the server to disable support for RC4 ciphers and suggested using the cipher configuration shown below. They also recommended not using TLSv1 and only using TLSv1.1 and TLSv1.2. I also ran SSLScan to duplicate the results and can see “TLSv1 128 bits RC4-SHA” was accepted.

No problem I thought and changed my httpd.conf file as shown below then restarted the Apache2.4 service. I then had them re-scan the server and they received the same results. I’ve searched the entire server looking for files that contain “SSLCipherSuite” or “SSLProtocol” and deleted or renamed them all except \Apache24\conf\httpd.conf. I do have an \Apache24\conf\openssl.cnf file but I don’t think it does anything because it’s still the default file that comes with Apache. I also did a massive cleanup and deleted all the old versions of Apache, OpenSSL, and PHP. I upgraded Apache and OpenSSL from Apache 2.2 and OpenSSL 0.9.x about 3 weeks ago and have been running without problems. I don’t have any startup errors in the error.log or windows event viewer.

Is there somewhere else Apache/OpenSSL determines the protocols or cipher suites?

Is there a default somewhere that would ignore my SSL related directives?

Contents of my httpd.conf file (“MYDOMAIN” obviously isn’t my actual domain name):

<VirtualHost *:80>

    DocumentRoot "C:/Apache24/htdocs"
    ServerName www.MYDOMAIN.com

<VirtualHost *:443>
    DocumentRoot "C:/Apache24/htdocs_apps"
    ServerName apps.MYDOMAIN.com

    SSLEngine on
    SSLCertificateFile "C:/Apache24/certs/233afff052190aeb.crt"
    SSLCertificateKeyFile "C:/Apache24/certs/star_MYDOMAIN_com.key"
    # SSLCertificateChainFile "C:/Apache24/certs/gd_bundle-g2-g1.crt"

    SSLProtocol -ALL +TLSv1.1 +TLSv1.2 
    SSLHonorCipherOrder On

    <Location / >
        Options -ExecCGI -FollowSymLinks -Indexes
        Require all granted

Any help is greatly appreciated.

migrated from security.stackexchange.com Mar 30 '16 at 23:25

This question came from our site for information security professionals.

  • I actually recently went through this and this document helped me a LOT. In fact it was fairly similiar to your scenarion: weakdh.org/sysadmin.html – Robert Mennell Mar 30 '16 at 23:19
  • This looks more like a server config question than a pure security question. "Is there somewhere else Apache/OpenSSL determines the protocols or cipher suites?" – schroeder Mar 30 '16 at 23:25
  • Thanks @Robert Mennell but that link doesn't appear to be relevant to my problem. – Ron Mar 30 '16 at 23:30
  • Thanks @schroeder for moving this to a more appropriate location – Ron Mar 30 '16 at 23:31

As to the openssl.conf, does it have an SSLCipherSuite directive in it and, if so, is it commented out? There may be a "merge" issue.

Looking at your SSLCipherSuite directive, I see the following issues (which may or may not be part of the problem here):


  • ECDHE-ECDSAAES256-GCM-SHA384 should probably be ECDHE-ECDSA-AES256-GCM-SHA384
  • although TLSv1.0, DHE-RSAAES256-SHA should probably be DHE-RSA-AES256-SHA

TLSv1.0 protocols:

  • DHE-RSA-AES128-SHA is TLSv1.0
  • DHE-DSS-AES256-SHA is TLSv1.0

In any case, I use:



SSLProtocol all -SSLv2 -SSLv3

and pull an A+ rating out of Qualys SSL Labs' SSL Server Test (including verification of no RC4).

NOTE: Although some people are dropping TLSv1.0, you might have trouble with a fair number of browsers, possibly including Android 5.0.0 and back, IE 8-10 on Win 7, IE 10 on Win Phone 8.0, Safari 5.1.9 on OS X 10.6.8, and Safari 6.0.4 on OS X 10.8.4

  • Thanks for the suggestions, I tried them all without success unfortunately. There wasn't a SSLCipherSuite directive in the openssl.cnf file. Thanks for pointing out the typos, that's what I get for copy/paste from corporate. I took it a step further and looked for other typos by breaking out my ciphers into an excel spreadsheet and then exporting the supported ciphers from openssl -v and did a vlookup between the two. I found "kEDH+AESGCM" in addition to the two you pointed out. I also changed my SSLProtocol to match yours and still accept "TLSv1 128 bits RC4-SHA". – Ron Mar 31 '16 at 14:41
  • I just ran an experiment with interesting results. I have a development server with nearly identical setup. The only difference I can think of is the fact that Apache24 was setup over a year ago before I got involved. I copied the httpd.conf from my production server to the dev server and changed the server name directives. After rebooting the dev Apache the RC4 ciphers are not accepted. This tells me I have something different between the setups between dev and prod and something on the Prod server is causing the SSL related directives to be ignored even though SSL is running. – Ron Mar 31 '16 at 15:24
  • I think I've been chasing my tail. I copied all my production files to the dev server and the dev server works great. Then I decided to scan the prod server again using the internal IP address instead of the public address and it passed with flying colors. No weak ciphers! Now I have to start looking in a completely different direction! – Ron Mar 31 '16 at 18:06

Ahhh success! It turns out our network uses an "F5" appliance which makes the SSL connection and then proxies the connection back to my server. It looks like they need to work on THEIR ciphers! My server is extra secure now thanks to this little exercise. I also use CloudFlare so the connection goes Cloudflare->F5->OpenSSL using TLSv1.1 and TLSv1.2.

Time for lunch. I wonder if we still have that 2 drink lunch policy...


It sounds like the F5 setup might be as "inbound enterprise" instead of "inbound SSL pass through." It looks like the difference is that in the former traffic from user to F5 is encrpypted via F5 SSL setup, then decrypted at F5 and finally reencrypted using your SSL setup for only communication between F5 and your server, while in the latter the traffic is encrypted between user and your server entirely using your SSL setup (and is just passed along by the F5 without decryption/reencryption). If this is the case, it may be that your traffic is only "secure" (no RC4) between you and the F5 and is at the mercy of the F5 setup while on the public network. Might at least be worth asking some questions of your netwrok people before assuming that you have a secure setup.

  • @Ron Yes, seems like it would be good to know! Aside from the security issue (weakest link), the decrypt/reencrypt setup seems like it would also be very inefficient as there is alot of overhead associated with setting up the encryption, which usually (depending on other settings) happens for every file sent. Having to do this TWICE for every file does not seem like a good thing. – Colt Apr 1 '16 at 17:20

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.