我们有一位客户声称他的网站（我们托管的）在 HSTS 下，但我们无法证实这一点。我告诉他打开那个 chrome 页面chrome://net-internals/#hsts并查询他的域，实际上他得到了一条记录，其中一条dynamic_sts_observed是14662335822016-06-18 07:06:22 UTC。实际上，此时客户搬到了我们这里，他很可能以前有过 HSTS。
我想没有真正的理由来清除“为网络”，但至少，有没有办法查看 HSTS 什么时候应该到期？
我只能希望它不是在2021年......
HSTS数据由每个 Web 浏览器保存。
当向实现 HSTS 的域发出请求时，响应标头将包含一个Strict-Transport-Security标头，该标头记录记录的最大年龄以及可选的其他一些与 HSTS 相关的值。
这个最大年龄有效地给出了从收到响应时开始的生存时间。
RFC 6797 第 11.2 节（非规范）说明了这一点，尽管没有明确说明，其中指出：
“未来的恒定值”方法可以通过不断地向 UA 发送相同的 max-age 值来实现。
和
“固定时间点”方法可以通过发送表示在所需到期时间之前的剩余时间的 max-age 值来完成。这将要求 HSTS 主机在每个 HTTP 响应中发送一个新计算的 max-age 值。
因此，如果一个域过去使用过 HSTS，那么在之前没有更改 HSTS max-age 的情况下，可以预期没有客户端依赖旧 HSTS 数据的最早时间是最后一次请求的时间返回 HSTS 数据，加上当时 HSTS 数据中所述的时间。如果 HSTS max-age 已降低，则这些时间段形成滑动窗口；最后结束的时间是预计没有客户端依赖旧的 HSTS 数据的最早时间。这是第 8.1.1 节（规范性）中要求之一的结果：
如果一个已知的 HSTS 主机的缓存条目在过去有一个过期日期，那么它就是“过期的”。如果在任何时候缓存中存在过期的已知 HSTS 主机，UA 必须从其缓存中驱逐所有过期的已知 HSTS 主机。
在任何请求中，如果响应通过安全传输接收并包含 HSTS 数据，则如第 8.1 节所述，客户端 UA必须更新其已知 HSTS 主机列表（规范）：
如果 /.../ UA 必须 [要么]: /.../
如果 max-age 和 includeSubDomains 标头字段值令牌中的一个或两个正在传达与 UA 已经维护的信息不同的信息，则更新 UA 的 Known HSTS Host 缓存信息。
max-age 值本质上是相对于 STS 头字段的接收时间的“生存时间”值。
因此，打开 HSTS 实际上是一个承诺，即在不短于 max-age HSTS 参数的持续时间（从响应的那一刻开始计算）内继续提供有效的 HTTPS。
作为进一步的结果，HSTS 数据没有固定的“到期”日期和时间，除非服务器使用RFC中非规范描述的“固定时间点”方法。
HSTS是通过使用 HEADER 设置的，即Strict-Transport-Security: max-age=31536000max-age 定义了浏览器将记住 HSTS 设置的时间，因为它上次第一次看到这个 HEADER。（至少我是这么理解的）。当 Max-Age 结束时，只有当请求头再次出现在请求中时，浏览器才会重做 HSTS。
通常的做法是将 Max-Age 设置为 1 年（以秒为单位）。任何 TLS 网页都包含这个具有较长 Max-age 的标头被认为是一种很好的做法，因此客户端知道该站点应该是 TLS 并且甚至会记住它，因此中间人攻击具有较少的开放攻击向量。
编辑：由于 HTST 网站列表是浏览器特定的东西，它的设置位置、设置时间以及如何找出到期时间是特定于浏览器的。并且由于缺少信息（例如什么兄弟）而没有进一步的细节超出范围。在很多情况下，将它们全部列出会有点冗长且版本特定。
如果您正在寻找特定 Chrome 实例上网站的 HSTS 或 HPKP 到期日期/时间，几个月前我也有同样的需求，发现Pin Patrol扩展对此很有帮助。（源代码在这里；它是 LGPL-2.1。）
（为了充分披露，我与 Pin Patrol 的作者没有任何关系。）