HSTS Max-Age Calculator for Rollouts

Sysadmins wonder what HSTS is. It’s just a configuration flag for enabling HTTPS. It is no big deal until you actualy set it and run into trouble.

Everything works as expected: Your primary website loads over HTTPS, great! Everyone are happy for a while. A week later, however, a user tries to visit your stats dashboard (on `stats.example.com`) using the wrong protocol: HTTP. And your browser say nope. Your users can’t reach a vital system because that one subdomain happens to still contain some legacy code which doesn’t speak TLS.

Why You Need to Plan Before Using HSTS

Browsers aggressively cache the HSTS header, they remember their decision for the duration specified in your max-age header. This is great for security, it’s why we like HSTS, but it also locks you into a corner if your infrastructure isn’t prepared. How long does the lock last? Can all of your system handle the enforcement? Work out those numbers.

That’s where the calculator comes in: it models out this risk prior to deployment. It doesn’t just do the math between days and seconds for your server config; it also makes you think about the consequences of your actions. How long is that max-age going to be? What happens when that period elapses? Thirty days without a fallback…what if something goes wrong with your cert renewals on day twenty nine? Users gets hard errors until either they refresh their cache or someone else (you) steps in manually to help. The tool takes all of this into account and gives an estimate of how long it would of take to roll back.

Disabling HSTS in production won’t remove previously cached copies from browsers, they’ll need to forget. When used incorrectly, the includeSubDomains directive can get you into trouble. This directive applies your policy to all hostname within your domain, even those you may have forgotten about. Shadow IT is rife with old staging environments, vendor portals, IoT dashboards, etc. If one of these do not serve valid HTTPS, then your entire domain falls victim to this.

Based off how many subdomains you report and what percentage is covered by HTTPS, our calculator will rate your readiness. Anything below a score of ninety indicates that you’ve got some inventory holes. Don’t let that number slip by. That’s telling you to leave your initial max-age low as you track down those rogue hosts.

But there’s one more level of finality: preloading. Submitting your domain to the browser preload list bakes your HSTS policy into the browser binary itself. No HTTP request ever gets made by users; they just know they need HTTPS. It is great for security but more horrible than flexibility. Once you’re on a preload list, removing yourself is a slow, manual process. Only do this once you’ve run a staged rollout with a long max-age (e.g., one year) and confirmed no failures. The calculator checks if you has enough time and the necessary includeSubDomains flag to qualify for preload submission. These are the technical requirements for being listed.

Begin with baby steps. Use the max-age as your safety net when starting out, setting it to five minutes or maybe just one day. This proves that your redirects work and that certificates is valid without trapping users for weeks. Once you’re confident, gradually increase the period of time. A month is an industry-standard sweet spot for sites nearing stability. For more mature estates preloaded for the long haul, a six-month-to-one-year window are the norm. The tool includes a table of reference periods so you can check how yours measures up against industry standards.

In the end, it boils down to planning for uncertainty (and time). For how long do you think you’ll have control over your infrastructure? How long does your infrastucture need to stay secure? That’s a judgement call, but the math is provided by the calculator. Check your certificate rotation jobs. Audit your subdomains. Make sure all your API endpoint speak TLS. Do that work first. Then set the header. Don’t leave it until after someone complains that they couldn’t log into their account for a month because of an expired cert on a forgotten test server. Better to err on the side of caution now.