Support

Please use words to describe your issues. Using pictures bumps your ticket to the bottom of the queue. The issue you should have described is "I have enabled the HSTS feature in the .htaccess Maker on my site, gpce.fr. When I use a third party service to check for the HSTS headers it tells me they are not set".

The problem here is that your site's domain name is www.gpce.fr, not gpce.fr. You have chosen to redirect from the non-www to the www domain.

When you try to access gpce.fr it simply redirects to www.gpce.fr and the redirection does not, of course, have any HSTS headers. Hostname-based redirections have precedence over any other rules. This is deliberate. In most cases you only issue an SSL certificate for a specific domain name and subdomain. Redirections have to happen in plain HTTP mode to avoid browsers displaying a warning about an insecure site.

When you access www.gpce.fr the HSTS header (Strict-Transport-Security) is set correctly.

Solution: test the correct domain name of your site.

I don't think that tool is very well thought out. Please read the reference in MDN https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security and the normative RFC 6797 https://www.rfc-editor.org/rfc/rfc6797#page-13.

It complains that you have a subdomain. This is nonsense. There is no such restriction in RFC 6797. The tool has invented a problem which does not exist.

It complains that you do not include the includeSubDomains directive. Again, this is nonsense. As you can read, you ONLY need to send this directive IF AND ONLY IF you want to enforce HSTS on ALL subdomains under the subdomain which returned the HSTS header. Otherwise you simply do not include this directive and let each subdomain provide its own Strict-Transport-Security header. Including this directive only makes sense for large organisations where each subdomain is managed by a different team and the IT department wants to enforce HSTS to prevent SSL stripping attacks across the entire (and often largely unknown) subdomain tree. Again, the tool is inventing a non-existent problem. 

It complains that you do not include a preload directive. This is nonsense, too. The preload directive IS NOT part of the specification. You only need this and the previous directive, along with an expiration over one year, if you want to add your domain to https://hstspreload.org/ so that your domain ends up in the HSTS preload list that ships with browsers. This only makes sense if you have a very well-trafficked site which warrants this kind of inclusion. Once again, the tool is inventing a non-existent problem.

Finally, it complains that there is no redirect from plain HTTP. THIS IS FALSE! When I access http://www.gpce.fr/ I do see a redirection to https://www.gpce.fr (see below, in bold type):

$ wget "http://www.gpce.fr" -O /dev/null
--2022-12-23 14:29:10--  http://www.gpce.fr/
Resolving www.gpce.fr (www.gpce.fr)... 109.234.164.82
Connecting to www.gpce.fr (www.gpce.fr)|109.234.164.82|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://www.gpce.fr/ [following]
--2022-12-23 14:29:10--  https://www.gpce.fr/
Connecting to www.gpce.fr (www.gpce.fr)|109.234.164.82|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘/dev/null’

/dev/null               [ <=>                ]  30,39K  --.-KB/s    in 0,07s   

2022-12-23 14:29:10 (427 KB/s) - ‘/dev/null’ saved [31119]

Therefore, this tool is misreporting a non-existent problem.

Four out of four issues reported are non-issues. I've seen broken tools, but this one takes the cake.

The most trusted tool for all things TLS–related is SSL Labs by Qualsys. As you can see in the results page for your site (https://www.ssllabs.com/ssltest/analyze.html?d=www.gpce.fr&hideResults=on) it correctly reports: “HTTP Strict Transport Security (HSTS) with long duration deployed on this server”. This tells you that, yes, HSTS is correctly configured on your site.