How to fix an HSTS max-age that is too short
The hsts_short advisory fires when your endpoint sends a Strict-Transport-Security header, but its max-age value is shorter than the threshold your company has configured in Administration → Alert Addresses → Manage Advisory Alerts.
What triggers the advisory
CertTracker parses the max-age=N directive out of your HSTS header. If N is below the threshold your company chose, the advisory fires. The default company threshold is 6 months (15768000 seconds). You can raise or lower it; common alternative values are 1 year (31536000) or 2 years (63072000).
(If the header is missing entirely, the separate hsts_missing advisory fires instead.)
Why it matters
The whole point of HSTS is duration. A header that says max-age=60 (one minute) provides essentially no protection — the browser forgets it almost immediately and the next session is vulnerable to downgrade again. Common reasons to see a short max-age in production:
- Inherited from staging — someone set max-age to 60 seconds while testing the deployment of HSTS and forgot to ratchet it up.
- Misread documentation — the value is in seconds. 86400 looks long but is only 1 day.
- Cargo-culted starter value — a 2017 tutorial recommended starting at
max-age=3600and never raising it.
Fix
This is purely a configuration change — same files as for adding a missing HSTS header, but updating the value instead of adding the line. Recommended target value:
max-age=63072000
That's 2 years in seconds. Long enough to be meaningful, short enough that you can recover if you ever need to disable HTTPS on a sub-resource.
Apache
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
Nginx
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
IIS
Edit the existing Strict-Transport-Security custom header in IIS Manager → site → HTTP Response Headers. Change the value to max-age=63072000; includeSubDomains.
HAProxy
http-response set-header Strict-Transport-Security "max-age=63072000; includeSubDomains"
For the full per-server context and reload commands, see the missing HSTS article.
Ratchet-up strategy
If you've never had HSTS on the site, jumping directly from no header to a 2-year max-age can feel risky. A safer ratchet:
- Day 0: set
max-age=300(5 minutes). Confirm nothing breaks and the header appears in responses. - Day 1: raise to
max-age=86400(1 day). - Day 7: raise to
max-age=2592000(30 days). - Day 30: raise to
max-age=31536000(1 year). - Day 60: raise to
max-age=63072000(2 years).
Each step gives you a window to roll back if any internal tool, redirect, or webhook breaks because it was implicitly relying on HTTP being accessible.
If you've already had HSTS enabled with a short max-age for weeks and nothing has broken, you can jump straight to the final value.
Verify the fix
curl -sI https://your-host.example.com/ | grep -i strict-transport-security
Confirm the max-age= value is at or above your company's threshold.
Trigger a re-scan from the CertTracker UI. The fastest path: open the monitor's detail modal (click the monitor row on the Monitors page), scroll to the Active Advisories section, and click the orange ⟳ Re-scan button on the right side of the section header. The status line below the header will confirm the cert re-poll and TLS audit are queued; the next 5-minute poller tick (within ~5 minutes) runs both, and the advisory clears if your fix took. See Where to find these buttons in the UI for visual landmarks. The advisory clears as soon as the next successful poll sees the new value.
Adjusting the threshold instead
If your business genuinely uses short HSTS durations on purpose (rare but legitimate for some development or staging environments), the right move may be to lower the company threshold rather than chase the header upward. Go to Administration → Alert Addresses → Manage Advisory Alerts and set the HSTS minimum to a value that matches your policy.
Related advisories
- HSTS header missing — fires when no header is sent at all.
Back to the TLS hardening hub.