5

I have an odd issue. The SSLProtocol config is getting applied in my ssl.conf file but the SSLCipherSuite config is not. I have tested this by changing each option and running scan with Qualys SSL Labs.

After several hours of banging my head against the wall, I decided to try putting the SSLCipherSuite directly in one of my vHosts and instantly got an A+ rating. So, I have the same ciphers in the ssl.conf and inside one of my vHosts in httpd.conf. When running scan against my vHost with the SSLCipherSuite, I get an A+, when I run the scan against one of my other vHosts (hoping the global ssl.conf will apply) I get a B.

I have 17 vHosts and I would prefer to figure this out with the global 'VirtualHost default:443' so I don't have to add this to every vHost individually.

- UPDATE 6/14 -

I am using Apache + Centos 6.5.

I have checked my httpd.conf and it does have Include conf.d/*.conf enabled by default which is the location of the ssl.conf file (./conf.d/ssl.conf)

With my version of Apache + CentOS it does not have available and enabled directories. Only a single conf.d directory where all .conf files reside.

I have checked the enabled vHosts with the command below and it does show my ssl.conf is loaded and the default vhost defined in that file is enabled.

# httpd -S
VirtualHost configuration:
wildcard NameVirtualHosts and _default_ servers:
*:443                  is a NameVirtualHost
         default server localhost (/etc/httpd/conf.d/ssl.conf:75)
         port 443 namevhost localhost (/etc/httpd/conf.d/ssl.conf:75)
         port 443 namevhost {mydomain}.com (/etc/httpd/conf/httpd.conf:1023)
         port 443 namevhost .......
         .......
         .......(x60)

I have also performed a graceful reload

# apachectl configtest && apachectl -k graceful
Syntax OK

4 Answers 4

3

Just hit a possibly similar or identical issue though with me it was to update a clients SSL to drop TLSv1 and TLSv1.1 support.

The default way is edit ssl.conf and set:

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1

This didn't work, but the answer wasn't in ssl.conf or the vhost configuration but rather in Let's Encrypt which has its own Include in (vhost)-le-ssl.conf

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

Editing that file to change the SSLProtocol line to exclude the protocols as needed was my answer.

Mentioning this in case similar searches which led me to this answer are for the same reason.

So basically just check something isn't getting Included elsewhere later that overrides your default settings.

1

You are definitely taking the correct approach, so let's test a couple things. I will assume current stable Apache + Ubuntu 16.04 for your server since that's very common, but adjust the commands / paths for your environment if different. You might have tried these already but it's usually something simple.

First, check that your main Apache config file at /etc/apache2/apache2.conf contains IncludeOptional conf-enabled/*.conf (near the bottom, should be present and un-commented by default).

Next, check that the config you wish to use is enabled. The fact that it exists is not good enough, it must also be enabled. Use the command a2enconf ssl if the configuration file you want to use is named ssl.conf and is present in /etc/apache2/conf-available/. If it's not there, or if you prefer to create a custom version, create a new file and enable it by name (e.g. nano /etc/apache2/conf-available/custom-ssl.conf && a2enconf custom-ssl)

Lastly, do a quick configtest and then a 'graceful' restart before you re-test with the third-party service (SSL Labs probably?). The graceful restart will wait until there are no active users and then restart, instead of terminating while people are still browsing your site(s).

apachectl configtest && apachectl -k graceful

3
  • I have updated my question for 6/14
    – JT Fair
    Jun 14, 2017 at 15:31
  • I'm afraid I am out of ideas then. The only other thing I would try is a custom conf, but that doesn't solve the original problem with ssl.conf changes not being applied. Hopefully someone with CentOS experience can help. Jun 15, 2017 at 13:38
  • ^^ Another thing to watch out for is duplicate directives, ie specifying a 2nd SSLCipherSuite line further down the chain (in a subdomain's vhost block, for e.g.) will choke init. Apache will not start and it is difficult to debug. Jan 28, 2022 at 19:13
1

I had the same issue under CentOS 7 and Apache 2.4.6, and the fix was to move the SSLCipherSuite directive outside of the <VirtualHost _default_:443> in my SSL configuration file that I include in all of my virtual hosts:

Listen 443 https
SSLCipherSuite <list of ciphers>

<VirtualHost _default_:443>
[...]
</VirtualHost>
1
  • Thanks good to know. I have since moved all my apps to docker and run on debian containers which do not seem to have the VirtualHost _default section in the ssl.conf and this directive is working fine. Next time I am deploying an app on CentOS I will check your solution.
    – JT Fair
    Oct 29, 2018 at 18:47
1

Just had the very same issue with my Apache 2.4 configuration on CentOS version 8.

We are all mistaken on the meaning of the _default_:443 host: this section does not contain the default settings for all the virtual hosts defined additionally. It's merely a fallback virtual host when no other hostnames are defined or an undefined hostname is called.

So in order to define SSLProtocol, SSLProxyProtocol, SSLCipherSuite, SSLProxyCipherSuite and maybe some other over-all default settings for SSL/TLS, place them right above the VirtualHost definition.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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