hpkp 已被主流浏览器弃用且 nginx 不再推荐部署，因其配置失误会导致用户长期无法访问；现由 certificate transparency、caa 记录、hsts 等更安全机制替代。
HTTP 公钥固定（HPKP）在 Nginx 中曾可通过 add_header Public-Key-Pins 指令配置，但如今它已被主流浏览器彻底弃用，Nginx 也不再推荐部署。根本原因不是它不够强，而是太危险——一次配置失误，就可能让用户数月无法访问网站。
HPKP 的设计目标很明确
它想解决的是 HTTPS 最底层的信任风险：万一某个受信任的证书颁发机构（CA）被攻破或误发证书，攻击者就能伪造合法证书实施中间人攻击。HPKP 让网站告诉浏览器：“只认这几个公钥，其他一概拒绝”。这确实曾在 DigiNotar 事件中帮谷歌快速发现异常。
- 通过
Public-Key-Pins响应头传递至少两个 SHA-256 哈希值（主密钥 + 备用密钥） -
max-age设为数月甚至一年，浏览器会严格缓存并强制执行 -
includeSubDomains和report-uri可扩展策略范围与监控能力
但它把运维变成了高危操作
HPKP 不像开个开关，而像给网站装了一枚延时引信。Nginx 配置一旦上线，错误就很难挽回：
- 备用密钥丢失、过期或未提前部署，证书轮换后用户直接看到“此网站无法访问”硬错误
- 攻击者劫持域名或服务器后注入恶意 HPKP 头，恢复服务后用户仍被锁定数月（RansomPKP 攻击）
- CDN 或反向代理（如 Cloudflare）通常不支持透传或生成 HPKP 头，导致策略失效或冲突
- Chrome 自 v67（2018 年）、Firefox 自 v70（2019 年）起完全移除 HPKP 支持
替代方案更轻量、更可靠
现代安全实践已转向更稳健的组合机制，不再依赖客户端强制绑定密钥：
- Certificate Transparency（CT）：要求所有公开信任的证书必须记录在可审计的公共日志中，网站可实时监控异常签发
- CAA 记录：在 DNS 中声明仅允许指定 CA 为域名签发证书，从源头限制滥用可能
- HSTS：强制浏览器始终使用 HTTPS，配合预加载列表可规避首次 HTTP 请求风险
- 密钥轮换自动化 + 短有效期证书（如 Let’s Encrypt 90 天证书）降低单点泄露影响
对 Nginx 运维者的实际建议
如果你在旧配置里还看到 Public-Key-Pins，请立即删除。它不仅无效，还可能干扰现代安全头解析。当前应专注以下几项：
- 启用
Strict-Transport-Security（HSTS），设置max-age=31536000; includeSubDomains; preload - 配置
Content-Security-Policy防止混合内容与 XSS 衍生攻击 - 确保 TLS 使用 1.2+，禁用 SSLv3/TLS 1.0/1.1，并优先协商前向保密套件（如 ECDHE）
- 配合 CT 日志监控工具（如 crt.sh、Facebook Certificate Transparency Monitor）主动发现异常证书
