我了解 HSTS 的原理，以及 max-age 的选择限制了如果站点以某种方式丢失其证书并且不得不暂时返回 HTTP-only 时访问者可能被锁定多长时间。在设置 HSTS 时，大多数来源推荐相当长的 max-age 值——大约 180 到 365 天。一些“SSL 测试”网站（Qualys、ImmuniWeb...）甚至发出警告，将 HSTS 最大年龄设置为低于 180 天的值。
另外，虽然大多数付费证书的有效期为一年，但 LetsEncrypt 的证书有效期仅为 90 天。这引出了我的问题： HSTS max-age 是否应该设置为与证书的有效期相匹配？（即 90 天的 LetsEncrypt 证书的最大期限为 90 天，一年的 ExpensiveCA 证书的最大期限为 365 天。）
这是两个不同的东西。LetsEncrypt 将他们的证书设置为短期的，因为他们希望他们的用户不断更新它们，短期证书限制了丢失私钥的暴露时间。
出于实际原因，付费证书通常是手动颁发的，因此寿命会更长一些（当有人必须单击按钮并填写表格时，每 90 天颁发一次证书会更加困难）。
另一方面，HSTS 旨在确保浏览器“记住”站点的状态，并在访问它时使用 HTTPs。这有明显的安全优势，但也有轻微的性能改进——浏览器本身将执行 307 重定向，甚至不会尝试纯 http 请求。这为用户节省了整个站点的往返行程。
但是，主要好处显然是安全性。一旦用户访问您的合法网站，并设置了他们的 HSTS - 攻击者就很难在他们的浏览器上欺骗您的网站，因为现在被欺骗的网站需要一个有效的证书！
简而言之，您希望将 HSTS 设置为尽可能长，以享受安全和性能优势——同时您希望将 TLS 证书设置为尽可能短，以减少丢失密钥的威胁。
鉴于此，将 HSTS 设置为等于您的证书的最大年龄完全没有意义。毕竟，即使您的证书设置为 90 天，在第 81 天访问您的网站的客户也会将其 HSTS 设置为 90 天——即使您的证书将在 9 天后到期（希望您很快会续订！ )
我理解周围人的一些担忧，“如果我不能再提供 https 会发生什么”。这是我 5-6 年前开始使用 HSTS 时的担忧，但现在这是一个非常非常小的问题。
LetsEncrypt 是完全免费的，所有的网络服务器都可以很容易地为它配置。如果您的网站发生灾难性故障，重建它的时间将远远大于添加 https 的小增量步骤。如果一切都失败了——您也可以随时使用 Cloudflare 或任何其他 CDN 为您提供 https。