I've implemented an HSTS policy for our site. I have the header being served on our main domain and it's sent on the very first response that serves the 304 Redirect from the server. (According to this article the header must be on this response.). We have includeSubDomains directive on as well as preload and have preloaded our site. It is listed on the chromium json config file.

The problem is sometimes the policy is being enforced for subdomains, and sometime it is not, and I can't figure out why.

Here what an initial GET request and response from our domain looks like (I've replaced our domain name with REDACTED):


GET http://www.REDACTED.com/ HTTP/1.1
Host: www.REDACTED.com
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.71 Safari/537.36
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
Cookie: user_segment=Prospect; _ga=GA1.2.992855402.1446138879; ASPSESSIONIDCQBCRBQD=EIAMMLLAAHBGBIPLEDPCPEFF


HTTP/1.1 302 Object moved
Cache-Control: private
Content-Length: 149
Content-Type: text/html; Charset=utf-8
Expires: Wed, 28 Oct 2015 17:31:02 GMT
Location: https://www1.REDACTED.com/
Server: Microsoft-IIS/8.0
X-Powered-By: ASP.NET
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Date: Thu, 29 Oct 2015 17:32:01 GMT

<head><title>Object moved</title></head>
<body><h1>Object Moved</h1>This object may be found <a HREF="https://www1.REDACTED.com/">here</a>.</body>

I know HSTS works by having the browser cache the policy, but it just seems arbitrary when the UA's (Chrome/Firefox) decide to actually enforce it. Sometimes its being enforced, and others not at all even after I've visited the main domain to "refresh" the policy.

  • 1
    What does the SSL Labs Test have to say about the STS status? (Screenshot here) Oct 29, 2015 at 19:37
  • @StackzOfZtuff great advice. The first time I ran the test it said No. I cleared the cache and re-ran and it said Yes. I think this means there is one server where the header isn't being server from and its a load balancing issue. Oct 29, 2015 at 19:56
  • @StackzOfZtuff as it turns out there was a single server not serving the header. However, after correcting this, the behavior is the same. The browsers don't seem to be enforcing the policy for the subdomains. Querying the chrome://net-internals#hsts says that our site is "not found" in the set. Any other ideas? Oct 29, 2015 at 20:33
  • @StackzOfZtuff sorry for the spam, I think I know the problem. the reply in which the header is being sent is HTTP not HTTPS.. Oct 29, 2015 at 20:35

1 Answer 1


Source: RFC 6797.

The HSTS header is only valid when it is set over HTTPS.

An HSTS Host MUST NOT include the STS header field in HTTP responses
conveyed over non-secure transport.

This is because agents only respond to the HSTS header when a resource is served over TLS/SSL:

If an HTTP response , received over a secure transport, includes an STS header field... [snip] Note the host as a Known HSTS Host

The plain HTTP response should return an HTTP 301 permanent redirect to the HTTPS resource. The HTTPS resource then contacted should set the HSTS header. You may as well set all HTTPS resources to return the header and to renew the expiry (max-age).

  • 1
    Yeah, I figured this out not long after making the post. Thanks though, I think this sheds a lot of light on the issue. Nov 3, 2015 at 17:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .