HSTS Missing From HTTPS Server

NethServer Version: 7.8.2003
Module: Base

Is there any way to alter the webserver(s) on Neth to enforce HSTS?


Does it work if you set a stricter TLS Policy?

On my gentoo webserver I had to add those lines near the ssl configuration in the apache vhost config of the websites it’s serving, but I have to leave it to the nethserver pros to explain how this can be implemented with some e-smith template because I don’t know. Maybe they also decide to activate this option in the apache config?

Header always set Strict-Transport-Security “max-age=31536000; includeSubDomains”
Header set Content-Secure-Policy “default-src ‘self’;”

1 Like

It works with a custom template:

Create custom template dir:

mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf.d/nethserver.conf

Create file /etc/e-smith/templates-custom/etc/httpd/conf.d/nethserver.conf/20hsts with following content:

Header always set Strict-Transport-Security "max-age=31536000"

Apply configuration:

signal-event nethserver-httpd-update

There’s a feature thread:

1 Like

…and as I noted there, HSTS should not be enabled by default–there’s too much risk of locking visitors out of your site. But yes, Neth should include the option in the server manager.


I’ve got that set and the security fault remains.

Awesome. I’ll set this and keep my ear open in case anyone has problems. Thanks!


Just to confirm: will this fix handle servers on all ports or is it targeted? I receive the security notification on 9090 and 443.

No, the custom template only covers the httpd port 443. For the other services more custom templates are needed.
As regards cockpit port 9090 I did not find a way to enable HSTS.

1 Like

Cockpit is not intended as “public available tool”… As advised into management interface, the IP should be restricted to a defined list for allowing connection.

IMVHO also for every other module which expose a “public applicaton”, like MatterMost o NextCloud.

1 Like

Thank you for trying.


Warning:Once enabled, HSTS disallows the user from overriding an invalid or self-signed certificate message. Your website will be inaccessible without a valid SSL.

This will enable for the whole apache, maybe we could have a solution adapted to each vhost

1 Like

Now i get why it’s not exposed that kind of option on Cockpit…

1 Like

However it brings a lot of good new security layer like the man in the middle

create a file /etc/e-smith/templates/httpd/vhost-extra/20HSTS

    if ($Port == 443) {
        $OUT .= q(
<IfModule mod_headers.c>
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

We can create a checkbox (default disabled) with a warning about selfsigned certificates (who use it nowadays). Obviously this will be only enabled per virtualhost


I think this is a good plan. I’d also add to the warning that if the certificate becomes invalid for any other reason, users will also be unable to connect. The most likely issue here would be that a cert fails to renew, and that problem isn’t recognized in time, HSTS will lock people out.


If that’s the case, documentation to reverse the process, and set to default, from the cli would be helpful.

That’s the problem with HSTS–removing it won’t help you. Every time you connect, it sends the header that tells your browser to not connect insecurely to your FQDN (optionally including subdomains) for the next n seconds (generally for a period of one-two years), no matter what. By design, you can’t just override this in the browser by clicking “visit anyway”. And the fact that the server isn’t sending that header now doesn’t help, when it did send it last time. So disabling it from the command line is only part of the solution; the rest is that you must then visit from a different browser (one that’s never received the HSTS header from your server).


It’s not that bad, you can clear it in the browsers:




1 Like

We talked internally about HSTS feature and we are not sure it is good enough about the user experience. We think that it could bring some good things from a security perspective but also bad behaviors if you are not fully warned about the consequences.

In short for now we would like that people tries it without being exposed in the UI and this can be done simply by a .htaccess in the vhost itself, force obviously the https of your vhost

vim /var/lib/nethserver/vhost/64f1c94a95e24a9/.htaccess

drop in your .htaccess

<IfModule mod_headers.c>
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" env=HTTPS

reload httpd

systemctl reload httpd

test it by https://securityheaders.com/