nginx 不支持 ssl_password_file 指令，该指令不存在于开源版源码和官方文档中；配置会报错“unknown directive”，实际需通过 systemd 的 execstartpre 调用 openssl 在启动前解密私钥，并以无密码形式供 nginx 加载。
nginx 不支持 ssl_password_file 指令 —— 它根本不存在于开源版 Nginx 中。 你看到的配置会直接报错：unknown directive "ssl_password_file"。所谓“在加密文件系统中存放并自动加载”，前提是误以为这个指令合法，而实际要解决的问题是：如何让带密码的私钥在 Nginx 启动时无交互解密。
为什么 ssl_password_file 不是 Nginx 的原生命令
Nginx 源码里没有该指令的解析逻辑，官方文档也从未收录。它常被混淆为 OpenResty 的扩展、某些定制编译版本的 patch，或是社区误传的伪配置。Nginx 加载加密私钥时的行为是确定的：启动阻塞 + 终端等待输入。它不读文件、不认环境变量、不接受 stdin 流——只等你敲回车。
- 运行
nginx -t时若配置含ssl_password_file，必然失败 - 试图用
openssl rsa -in key.enc -passin file:xxx解密是可行的，但那是 OpenSSL 的能力，不是 Nginx 的 - 所有“Nginx 自动读取密码文件”的说法，本质都是外部脚本在 Nginx 启动前完成解密，并把无密码私钥喂给它
真正能落地的自动化解密流程（systemd 场景）
核心思路：不让 Nginx 碰密码，只让它读已解密的私钥。解密动作由 systemd 在启动前完成，且全程不落盘明文密码。
Cn Password Generator
下载
安全的随机密码生成器。支持自定义长度、字符类型（大写/小写字母、数字、特殊符号），排除相似字符，批量生成。纯 Python 标准库，无需 API 密钥。
- 把加密私钥
/etc/nginx/ssl/example.com.key.enc和密码文件/etc/nginx/secrets/key.pass（600 权限，属主 root）放在常规路径下 - 在
/etc/systemd/system/nginx.service.d/override.conf中添加：ExecStartPre=/usr/bin/openssl rsa -in /etc/nginx/ssl/example.com.key.enc -out /etc/nginx/ssl/example.com.key -passin file:/etc/nginx/secrets/key.pass
- 确保
/etc/nginx/ssl/example.com.key权限为600，属主为 Nginx 运行用户（如nginx） - 配置中仍写
ssl_certificate_key /etc/nginx/ssl/example.com.key，即指向解密后的文件
加密文件系统（如 LUKS）在这里起什么作用
它不用于“存放 ssl_password_file”，而是用来保护原始加密私钥和密码文件本身——即 .key.enc 和 .pass。LUKS 卷挂载后，这些敏感文件才可见；未挂载时，整个目录是密文块设备。
- LUKS 卷挂载点建议设为
/safe/ssl/，挂载选项必须含noexec,nosuid,nodev - 挂载脚本中禁止出现
echo "mypass" > /safe/ssl/key.pass这类动态生成逻辑 - 密码文件应预置在加密卷内，仅在轮换时通过受控流程更新（如 Vault Agent 写入 tmpfs 后 cp 进去）
- systemd service 需加
RequiresMountsFor=/safe/ssl，否则 Nginx 可能抢在挂载前启动
最容易被忽略的权限链断裂点
即使用了 LUKS，只要以下任一环节出错，安全就归零：
- 父目录
/safe权限不是700或属主不是 root，导致非 root 用户可遍历 -
/safe/ssl/key.pass属主是 root，但 Nginx worker 进程以www-data身份运行，且没做setgid或 ACL 授权，导致ExecStartPre解密失败 - SELinux/AppArmor 策略未放行 OpenSSL 访问加密卷路径，
nginx -t看似成功，但 reload 时解密静默失败 - 日志中开启
debug级别后，OpenSSL 错误可能泄露密码文件路径甚至部分内容到error_log
