真正安全的做法是让 nginx 从 hashicorp vault 动态获取解密后的私钥：开源版需脚本+curl拉取写入/dev/shm并设600权限；nginx plus支持secret://语法；高合规场景应采用keyless ssl或hsm直连。
直接把私钥文件路径写死在 Nginx 配置里（如 ssl_certificate_key /etc/nginx/ssl/example.com.key）已不满足现代安全要求。真正安全的做法是让 Nginx 从 HashiCorp Vault 动态获取解密后的私钥，避免私钥以明文形式落盘或长期驻留内存。
私钥不落地：Vault 分发 + Nginx 运行时加载
核心思路是：Vault 存储加密的私钥（或通过 Vault 的 PKI 引擎动态签发），Nginx 启动或重载时通过 Vault API 拉取并注入内存。需注意：
- Nginx 开源版本身不支持直接调用 Vault API，必须借助外部工具（如 shell 脚本 +
curl）在 reload 前将私钥写入临时内存文件（如/dev/shm/ssl_key.pem），再由ssl_certificate_key指向该路径 - Nginx Plus 用户可直接使用
ssl_certificate_key的secret://语法（如secret://vault:kv-v2/ssl/example.com/key），配合 Vault Agent 或内置 Vault 集成自动刷新 - 无论哪种方式，该临时文件权限必须设为
600，属主为nginx或运行 Nginx worker 的用户，且不能位于可被普通用户读取的目录（如/tmp）
配置 Vault 策略与密钥路径
确保 Vault 中私钥存储路径受严格控制：
- 创建专用策略（如
nginx-ssl-read），仅允许对kv-v2/data/ssl/*的read权限，禁止list或delete - 启用 Vault KV v2（带版本历史），写入私钥时使用
vault kv put kv-v2/ssl/example.com key=@/path/to/private.key - 为每个 Nginx 实例分配唯一 Token，并绑定上述策略；Token 过期时间建议设为 24 小时，配合定期 reload 实现轮换
自动化 reload 流程示例
避免手动操作引入风险，推荐用 systemd timer 或 CI/CD 触发以下流程：
- 执行脚本：用当前 Token 请求 Vault 获取私钥内容 → 写入
/dev/shm/nginx_ssl_key_example.com.pem→chmod 600→chown nginx:nginx - 校验私钥格式：
openssl rsa -noout -check -in /dev/shm/nginx_ssl_key_example.com.pem，失败则中止 reload - 执行
nginx -t && nginx -s reload，确保配置语法正确且新私钥生效 - （可选）旧私钥文件在 reload 成功后自动清理，或保留 5 分钟供回滚
进阶防护：结合 Keyless SSL 或 HSM
若合规要求极高（如金融、政务场景），仅靠 Vault 分发仍存在私钥短暂解密的风险。此时应升级为：
- Keyless SSL 架构：Nginx 不持有私钥，只作为边缘节点转发 TLS 握手签名请求至 KeyServer（其后端可对接 Vault 或 HSM）
- HSM 直连模式：Vault 后端挂载 AWS CloudHSM 或 HashiCorp HCP HSM，所有私钥运算在硬件模块内完成，Vault 仅返回签名结果
- 这两种方式下，
ssl_certificate_key在 Nginx 配置中实际指向一个空占位符或自签名证书，真正的私钥永不出 HSM 或 KeyServer
