# HSTS preload broke the staging subdomain

## TL;DR
Preloading applies HSTS to the whole domain including every subdomain, so a staging host without a valid cert becomes unreachable in modern browsers. Short term, serve staging over proper HTTPS. Long term, either accept preloading everywhere or request removal and wait months.

```text
HSTS preload broke the staging subdomain
```

## Use this when
- A staging subdomain stops loading in browsers after the parent domain was preloaded
- There's no click-through past the certificate warning
- The same staging host works in curl with -k but not in any browser
- A new subdomain is unreachable from day one

## Not for this skill when
- The domain was never preloaded (that's a plain HSTS header issue, removable instantly)
- The problem is local dev HSTS cache (clear the browser's HSTS entry)
- The cert error is on a non-preloaded domain

## Steps
1. Confirm preload status:
```
curl -s "https://hstspreload.org/api/v2/status?domain=example.com"
```
Expected: a status of preloaded. If it's preloaded, every subdomain inherits the policy.

2. Check what staging serves:
```
curl -sI https://staging.example.com | head -3
```
Expected: if the TLS handshake fails, browsers will hard-fail too; there is no click-through on preloaded HSTS.

3. Immediate fix: give staging a valid certificate (a real one from your CA, or the same wildcard as production) and serve it over HTTPS with a redirect from http.
Expected: staging loads in Chrome, Firefox, and Safari with no warnings.

4. If you truly need a non-HTTPS staging host, submit a removal request at the preload list's removal page. Then wait: removal propagates via browser preload lists, which update on browser release cycles, so budget months, not days.
Expected: the status API eventually shows removed; browsers pick it up on their own schedule.

5. Decide the durable policy: either every subdomain gets HTTPS always (recommended; keep preload) or keep staging off the preloaded domain entirely (staging-example.com instead of staging.example.com).
Expected: a written call so the next staging host doesn't repeat this.

### Variant: HSTS broke local dev
That's not preload; clear the browser's HSTS cache for the domain, or use a dev domain that was never preloaded.

### Variant: preload inherited from a parent company's domain
You can't fix the parent. Move your hosts to a domain you control or serve them all over HTTPS.

### Variant: includeSubDomains set without preload
Same breakage, but removable instantly by changing the header. Preload is the one-way door; the header alone is not.

## Why this happens
The preload list bakes your HSTS policy into the browser itself, with includeSubDomains semantics. It's a one-way door by design: easy to enter, slow to leave, because the security property depends on browsers remembering it.

## Edge cases and pitfalls
- Removal requests need to be deliberate; browsers won't fast-track you.
- Test staging in a fresh browser profile to rule out cached HSTS confusing the diagnosis.
- Don't fix this by telling the team to bypass the warning with a flag; the flag doesn't scale and the habit leaks into production thinking.
- Wildcard certs plus preload are a fine combination; the cert just has to actually cover staging.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_IhE0BDqiNMgIG7lCuFHvHQ