Our servers are running Windows Server 2016 with IIS 1607. From what I can tell, this means the IIS 10 on the system is prior-to version 1709 where apparently Microsoft added the HSTS element under the SITES element which allows an easier mechanism for setting up HSTS.
Yes, we may very well upgrade our severs to Windows Sever 2019 or 2022 in the somewhat near future, but for now, I need to consider the Windows Server 2016 scenario.
As a result, I'm finding this information (https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-10-version-1709/iis-10-version-1709-hsts) that shows how to implement HSTS on a version of IIS that's prior-to 1709.
To be fair, I have not tested any of this. My local IIS that I can test on is Windows 10 with IIS version 1889 or so, and there is a wonderful magical checkbox I can click that allows me to easily implement HSTS from the HSTS... link that's under the Configure section of my site in IIS Manager.
However, I dare not touch our other environments where Windows Server 2016 rules, because, while I do have admin access, I fear massively screwing up if I make unauthorized changes. Hence, this question so I can understand what I'm doing before I break anything.
But, I'm confused by what the information site I reference above notes. Do I have to implement all three of the suggested changes in the first suggested solution (Solution 1) or will just one of the changes work?
As, according to the information site:
Before IIS 10.0 version 1709, enabling HSTS on an IIS server requires complex configuration.
Under Solution 1, there are three different sections to the web.config mentioned. I'm confused as to whether just one of these sections is required or all three.
Solution 1: HTTP Redirect Module + Custom Headers
<sites>
<site name="Contoso-http" id="1" serverAutoStart="true">
<application path="/" applicationPool="Contoso-http">
<virtualDirectory path="/" physicalPath="C:\inetpub\Contoso-http" />
</application>
<bindings>
<binding protocol="http" bindingInformation="*:80:contoso.com" />
</bindings>
</site>
<site name="Contoso-https" id="2" serverAutoStart="true">
<application path="/" applicationPool="Contoso-https">
<virtualDirectory path="/" physicalPath="C:\inetpub\Contoso-https" />
</application>
<bindings>
<binding protocol="https" bindingInformation="*:443:contoso.com" sslFlags="0" />
</bindings>
</site>
<siteDefaults>
<logFile logFormat="W3C" directory="%SystemDrive%\inetpub\logs\LogFiles" />
<traceFailedRequestsLogging directory="%SystemDrive%\inetpub\logs\FailedReqLogFiles" />
</siteDefaults>
<applicationDefaults applicationPool="DefaultAppPool" />
<virtualDirectoryDefaults allowSubDirConfig="true" />
</sites>
Followed by:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<httpRedirect enabled="true" destination="https://contoso.com" httpResponseStatus="Permanent" />
</system.webServer>
</configuration>
and then:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Strict-Transport-Security" value="max-age=31536000" />
</customHeaders>
</httpProtocol>
</system.webServer>
</configuration>
My initial guess is that, yes, yes indeed, I do need to implement all three of these changes to the web.config file if I want to get the HSTS working using solution 1 for an IIS install that's prior to 1709.
I see there is a Solution 2 for prior IIS installs as well, but I'm interested in Solution 1 to understand it more thoroughly. Part of my confusion is that I've seen a similar problem solved by someone else using just implementing the one configuration change to the Custom Headers and nothing else. I'm curious if that is all I need to do.
Edit: With regard to the suggested solution (Enable HTTP Strict Transport Security (HSTS) in IIS 7), the answer to the question there is essentially Solution 2.
One of the reasons I'm asking this question is because I've seen a change to a system that only used part of Solution 1 (just the custom headers part), so I'm wondering if anyone else has used either solution and has experience with the implementation.
I have seen that the URL Rewrite module is installed on my server's IIS, so I'll just go with Solution 2, I think, since it's the answer for the previously asked question and seems a lot simpler than Solution 1.
