Template /etc/httpd/conf.d/ssl.conf

As I was looking to make some edits to ssl.conf, I realized that it isn’t templated–NS 7.4 just uses the default ssl.conf file from the upstream mod_ssl package. This seems kind of odd, given that pretty much every other configuration file is templated, and it means there’s simply no way to configure any HTTPS-related settings through the config system.

There are a couple of things that really need to be changed, as they compromise the security of a Neth installation:

  • SSLv3 is enabled, which is quite insecure (even TLS 1.0 is questionable, as I understand it).
  • The RC4 cipher is also enabled with some protocols.

Templating would also allow for properties for SSL key/cert/chain, removing the need to, for example, copy the Let’s Encrypt cert from /etc/letsencrypt every time it’s issued.

The particular thing I was looking to do was enable OCSP stapling, which is a straightforward enough setting (and I could, of course, just make the changes to ssl.conf).


IIRC some settings are templated in other drop-in files under /etc/httpd/conf.d/

Like you I’d also prefer a more secure default configuration, as of now it follows upstream defaults. It was discussed in the past:

The developers manual describes how to change the SSLCipherSuite db property.

1 Like

Going by memory, you should start by defining a virtual host with the web server module.

Default Apache host retain upstream SSL settings whilst virtualhosts provide some hardening.

So the SSL.conf template wasn’t needed.

When the upstream defaults are known to be insecure (as they are), that doesn’t really seem like a good idea. And why follow the upstream defaults on this one particular point, when just about everything else (on the system in general, and in the Apache configuration specifically) is customized?

Since ssl.conf isn’t templated at all, I’m curious how that setting would take effect–maybe I’ll have to try it. Looking through some of the links you gave (shame on me for not searching for prior discussion, though my point in this thread is a little different), it sounds like that property affects configured virtual hosts, but not the default. I’m having trouble imagining the rationale here. But really, there are two orthogonal issues:

  • IMO, ssl.conf should be templated just as most of the other system config files are, and for the same reasons. Configuration properties like the SSLCipherSuite should be implemented there for system-wide use. Or, alternatively, manage those settings directly through the httpd.conf templates and get rid of ssl.conf.
  • Whether ssl.conf is templated or not, the current NS7 defaults are insecure and should be changed. SSLv2 and SSLv3 should not be supported, nor should RC4. I don’t see this as an issue of breaking upstream compatibility–we’d be using unmodified upstream packages, but customizing the configuration–as we do for pretty much every other upstream package.
1 Like

Clearly I need to dig into the virtual hosts configuration a bit. But what’s the rationale for treating them differently?

This is not true: it seems they share the same SSLCipherSuite value. To copy it from httpd-admin (which has an hardened default)

config setprop httpd SSLCipherSuite $(config getprop httpd-admin SSLCipherSuite)
signal-event nethserver-httpd-update

You can edit ssl.conf directly (as it’s not a template). Remember to add it to the config backup.

The approach of NS templates is rather overriding the settings by issuing the same configuration directive at a later step (conf.d files are evaluated in alphabetical order), or in a more specific context (global/vhost/directory).


Thanks @davidep and @danb35 , SSLCipherSuite wasn’t set by default in httpd-admin on two of my servers but I could set it now with your instructions:

config setprop httpd SSLCipherSuite 'ALL:+HIGH:!ADH:!EXP:!SSLv2:!SSLv3:!MEDIUM:!LOW:!NULL:!aNULL'
config setprop httpd-admin SSLCipherSuite 'ALL:+HIGH:!ADH:!EXP:!SSLv2:!SSLv3:!MEDIUM:!LOW:!NULL:!aNULL'
signal-event nethserver-httpd-update
signal-event nethserver-httpd-admin-update

Do we also have to change SSLProtocol parameter or is SSLCipherSuite enough?

My sources for SSL/TLS recommendations:


1 Like

Yes, also SSLProtocol.

1 Like

Ah, now I see /etc/httpd/admin-conf/httpd.conf is templated:

[root@server httpd]# cat /etc/e-smith/templates/etc/httpd/admin-conf/httpd.conf/30ssl
# 30ssl

# settings by https://cipherli.st/
SSLProtocol All -SSLv2 -SSLv3
SSLHonorCipherOrder On

For httpd one may just edit /etc/httpd/conf.d/ssl.conf

1 Like

SSLv2 seems no longer available, it could be redundant.

We should add a SSLProtocol prop, because it seems adjusting the cipher suite is not enough to get a good SSL rating :wink:

Edit: add the following template-custom

[root ~]# cat /etc/e-smith/templates-custom/etc/httpd/conf.d/nethserver.conf/10ssl_custom
# 10ssl_custom -- davidep 20180117
# Disable sslv3 protocol
SSLProtocol All -SSLv3

With a letsencrypt cert and following settings I got an A rating at ssllabs and no warnings at symantec:

Create custom template

mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf.d/nethserver.conf/
nano /etc/e-smith/templates-custom/etc/httpd/conf.d/nethserver.conf/10ssl_custom
# 10ssl_custom -- davidep 20180117 
# Disable all protocols except TLSv1.2 
SSLProtocol all -TLSv1.1 -TLSv1 -SSLv2 -SSLv3
SSLHonorCipherOrder on

Change SSLCipherSuite in ssl.conf:

nano /etc/httpd/conf.d/ssl.conf


Apply changes:

signal-event nethserver-httpd-update



The cons of an high rate is loosing compatibility with older clients. I have to trade of between the two.

I think we should go for compatibility. Just disabling SSLv3 would be a good compromise IMO between rating (B) and compatibility. With active SSLv3 we get “C” and some security warnings (poodle…).
People who like it more secure are always able to change SSLCipherSuite and SSLProtocol.

1 Like

I definitely support a more secure default and would not only disable SSLv3
I have been using the following ssl.conf settings since about 2 years for about anything.
Gets me an A+ rating on Qualys and only kicks veeeery old clients, like Android v2, Win XP with IE8 and the like. No matter what application, that conf never failed on me.
As a default, enforcing HSTS might be a little bit too much…

SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLInsecureRenegotiation off
SSLCompression Off
Header always set Strict-Transport-Security “max-age=15768000”



9 posts were split to a new topic: Should we consider Allow enabling of HSTS