Nginx 不支持 ssl_password_file 密码加密，必须明文存储且按行与私钥顺序一一对应，安全完全依赖系统权限；推荐预解密私钥、集成 Vault 或使用短周期自动轮换证书。
Nginx 本身不支持对 ssl_password_file 中的密码做加密存储，该文件必须以明文形式存放——每行一个密码，且顺序需与配置中引用的加密私钥一一对应。这意味着密码文件的安全性完全依赖于操作系统级防护，而非 Nginx 自身能力。
ssl_password_file 的工作方式与固有风险
- Nginx 在启动或重载时，会按顺序逐行读取该文件内容，作为解密对应 SSL 私钥的口令；
- 文件路径由
ssl_password_file指令指定，可全局（http 块）或局部（server 块）生效； - 若文件权限宽松（如被其他用户可读）、所在目录可遍历、或被误提交至代码仓库，私钥即等同于裸奔；
- 一旦服务器失陷，攻击者拿到私钥文件 +
ssl_password_file，即可完整还原证书身份，发起中间人攻击或离线解密历史流量。
真实可行的安全加固措施
- 将密码文件权限严格设为
600，属主为运行 Nginx 的用户（如nginx或www-data），禁止组和其他用户访问； - 存放路径避开 Web 可访问目录（如
/etc/nginx/ssl/而非/var/www/下任意位置）； - 使用
chattr +i锁定文件（ext4/xfs 支持），防止被意外或恶意覆盖或删除； - 配合系统审计工具（如
auditd）监控对该文件的读写行为，及时发现异常访问； - 在 CI/CD 流程中动态生成该文件，并在部署完成后立即清理构建机上的临时副本。
更安全的替代路径（推荐用于生产）
-
预解密私钥（可信环境内完成）：在构建阶段用
openssl rsa -in key.enc -out key -passin file:pwd.txt解密，输出无密码私钥，再设权限为600、属主为 Nginx 用户；解密过程不在目标服务器发生，且原始加密私钥和密码文件均不落地到线上机器。 - 密钥管理服务集成（如 HashiCorp Vault）：通过 Vault 的 KV 引擎或 PKI 引擎动态提供密码，配合 Nginx Plus 的键值存储或自研 reload 脚本拉取并注入内存（不落盘）；开源版 Nginx 需借助外部程序（如 systemd exec wrapper 或 init container）实现类似效果。
- 使用短生命周期证书（如 Let’s Encrypt）+ 自动轮换：降低单次私钥泄露影响窗口，配合 ACME 客户端（如 certbot）自动续签与部署，天然规避长期密码管理难题。
不复杂但容易忽略
