Nginx 原生不支持 ssl_password_file 指令，配置后会报错“unknown directive”；其加载带密码私钥的唯一原生方式是启动时交互式输入密码，自动化需预解密或借助外部工具链。
直接说结论：Nginx 原生不支持 ssl_password_file 指令，加了会报错 unknown directive "ssl_password_file"。所谓“用该指令加载带密码私钥”是常见误解，实际并不存在。
为什么你看到的 ssl_password_file 配置会失败
Nginx 源码和所有稳定版文档中均无 ssl_password_file 这一指令。它不是 Nginx 的功能，也不是 OpenResty 默认启用的扩展。如果你在某份配置里看到它：
- 可能是误抄了其他项目（如某些定制 Nginx 补丁、旧版第三方模块或错误博客）
- 可能是把
openssl命令里的-passin file:xxx语法错当成 Nginx 配置项 - 运行时必然触发解析错误，Nginx 启动失败，日志中明确提示该 directive 未定义
带密码私钥在 Nginx 中的真实加载行为
Nginx 启动时若遇到加密私钥（如用 openssl genrsa -aes256 生成的 .key），会阻塞并等待终端输入密码——这是它的默认且唯一原生行为。它不会自动读文件、不查环境变量、不支持任何内联密码语法。
-
ssl_certificate_key /etc/nginx/ssl/key.pem—— 若该文件被密码保护，Nginx 主进程启动时将卡在 stdin 等待输入 -
ssl_certificate_key /path/key.pem:pass123—— 此写法非法，直接报错，Nginx 官方从未支持 - 没有“跳过输入”的内置开关；所谓“自动化”，必须由外部流程完成
真正可行的自动化方案：预解密 + 权限硬化
生产环境中最常用、最可控的方式，是在 Nginx 启动前，用 openssl rsa 解密私钥为无密码版本，并严格控制其生命周期与权限：
- 在可信构建环境（如 CI runner）执行：
openssl rsa -in key.enc -out key -passin file:pwd.txt - 解密后输出的
key文件权限设为600，属主为root或 Nginx 运行用户（如nginx） - 线上服务器上不存放原始加密私钥和密码文件，避免磁盘残留风险
- 配合
chattr +i /etc/nginx/ssl/key防止运行时被覆盖或删除（需 root 权限修改）
更高级但需额外组件的替代路径
若必须保留私钥加密状态且拒绝落盘密码，需引入外部工具链，Nginx 本身不参与密码管理：
- 用
systemd的ExecStartPre脚本，在/run（tmpfs）中动态生成临时密码文件，仅对 Nginx 主进程可见 - 集成 HashiCorp Vault：通过 Vault Agent 注入口令，再由 wrapper 脚本写入内存文件系统，Nginx 从该路径读取
- 使用 NGINX Plus 的键值存储（
keyval模块）+ Vault API，让私钥口令只存在于内存，不触碰磁盘
这些方案有效，但复杂度陡增；多数团队低估了运维负担，最终回归预解密模式。真正容易被忽略的，是解密操作必须脱离目标服务器——一旦在生产机上执行 openssl rsa -passin file:...，密码文件就已暴露。
