Nginx 不支持配置中写私钥密码是刻意设计，强制采用无密码私钥+严格文件权限（600、属主限定、tmpfs存储）的安全实践，而非绕过限制的危险变通。
因为 Nginx 根本不支持在配置中写私钥密码——这不是疏忽，而是设计使然。它没有 ssl_certificate_key_pass 这类指令，也不接受类似 ssl_certificate_key /path/key.pem:pass123 的内联写法。所有试图“直接写密码”的做法，本质都是绕过限制的危险变通，反而放大风险。
官方不支持，硬加等于埋雷
Nginx 启动时若遇到加密私钥，会阻塞等待终端输入密码，这是为了防止密码以明文形式暴露在配置、环境变量或进程参数中。它刻意放弃自动化解密能力，把安全责任交还给操作系统和运维流程。
- 任何声称“改源码/打补丁/用 OpenResty 扩展就能内联密码”的方案，都会破坏二进制可信性，且无法通过标准安全审计
- 把密码拼进 shell 脚本再用
echo写入文件，等同于把密码明文固化在部署逻辑里，CI/CD 日志、Git 历史、备份镜像都可能泄露它 - 用
setenv或envsubst注入环境变量，变量本身可能被ps aux、/proc/PID/environ或调试器读取
真正起作用的是系统级防护，不是配置技巧
即便你用某种方式让密码“看起来没写在 nginx.conf 里”，只要它最终以明文落盘、权限宽松、路径可猜，就等于裸奔。
- 密码文件必须设为
600，属主严格限定为 Nginx 运行用户（如nginx），不能是root或其他高权限账户 - 存放目录（如
/etc/nginx/ssl/）权限应为700，禁止组和其他用户进入，避免路径遍历泄露文件名 - 推荐使用
tmpfs（如/dev/shm/nginx-pass/）挂载点：内存存储、重启清空、不落地磁盘
比“怎么存密码”更重要的是“要不要密码”
生产环境中，99% 的场景更适合用无密码私钥 + 严控文件权限的方式，而非费力维护密码加载链。
- 加密私钥在 Nginx 场景下几乎不提供额外保护：一旦服务器失陷，攻击者既能读取私钥文件，也能读取密码文件或内存中的解密结果
- 无密码私钥配合
chmod 600、chown root:nginx、chattr +i锁定，再配合 auditd 监控访问行为，实际防护强度更高 - 若合规要求强制加密，应在可信构建环境（如离线 CI runner）中完成解密，输出无密码私钥后直接分发，原始加密材料绝不上线
安全链条的薄弱点从来不在配置语法里
一个被误提交到 Git 的 ssl_password_file 路径、一个权限为 644 的私钥、一次未清理的临时文件、一段日志中意外打印的 $PASS 变量——这些才是真实攻破 HTTPS 的入口。
- 定期用
find /etc/nginx -name "*.key" -perm /037扫描宽松权限私钥 - 在 CI 流水线中加入检查项：禁止任何含
pass、pwd、secret字样的文件被提交到 nginx 配置仓库 - 用
auditctl -w /etc/nginx/ssl/ -p wa -k nginx-ssl记录所有对该目录的写入与访问
