Ross Helfand

I had previously tried this second option of binding the HSTS options using the 'set ssl vserver' command, but since the WAF was blocking access to "/" the request was never able to get to the SSL vserver (basically, the same behavior as having a rewrite policy bound to the vServer). Binding it to global was a great suggestion! I just tried it out, and I was surprised that it didn't work. Same behavior. If I un-blocked access to "/" via the WAF, I was able to see the headers. I talked to the team and we decided to just un-block access to "/" as we can't see any reason why it's blocked in the first place. But would love to hear other suggestions if anyone has them!

Fair question! This is part of our PCI environment, and we only allow access to very specific URLs. It's been like that for longer than I've been here, so I'll need to see if it's ok to grant access to "/". Thanks for the info!

Hello, I have a bit of a strange issue. I think I understand what is going on, but not how to fix it. If I run my URL though SSLLabs, it tells me that Strict Transport Security (HSTS) is set to "no." However I have enabled HSTS using a rewrite action (and I also tried binding the options to my SSL virtual server). If I run a 'curl' to the root of my application, I don't see the HSTS headers, and I get a "403 Forbidden" response. If I run a 'curl' to a known static image or page behind my Netscaler, I get the image and the expected 'Strict-Transport-Security' headers. I assume what's happening is that my WAF is blocking access to "/" and therefore the rewrite action is never getting hit. Is there a way that I can get SSLLabs to recognize HSTS? Do I just need to set my WAF to allow access to "/"? Thanks!