私钥安全的核心是操作系统权限控制与路径隔离，必须设为600权限、属主root、存放于/etc/nginx/ssl/等非web可访问路径，并禁用密码保护以保障服务可用性。
配置 ssl_certificate_key 的核心目标不是“配通”，而是守住私钥这道命门。它不依赖 Nginx 自身校验，而完全仰仗操作系统级的权限控制与路径隔离。配错权限或放错位置，等于把房门钥匙挂在门外。
私钥文件权限必须锁死为600
私钥文件不能有丝毫宽松——644、755、666 等权限都是高危信号。Nginx 主进程以 root 运行，能读取 600 权限的文件；工作进程（如 www-data）无需直接读磁盘私钥，主进程加载后会将解密后的密钥保留在内存中供复用。
- 执行命令强制修正：
chmod 600 /etc/nginx/ssl/example.com.key - 属主建议设为
root：chown root:root /etc/nginx/ssl/example.com.key - 禁止用
umask 002或其他方式导致新建文件默认带组/其他可读
存放路径必须脱离 Web 可访问范围
私钥绝不能出现在 /var/www/、/usr/share/nginx/html/ 或任何被 root、alias、location 映射到 HTTP 路径下的目录中。攻击者常通过爬虫尝试访问 https://ip/ssl/private.key 等路径试探泄露。
- 推荐路径：
/etc/nginx/ssl/或/etc/ssl/private/（后者需同步设置目录权限为 700） - 验证是否安全：在浏览器中直接请求该私钥的 URL，应返回 403 或 404，而非 200 + 文件内容
- 若使用 Certbot，默认路径通常合规；但手动迁移证书时务必重新检查路径归属与父目录权限
生产环境禁用私钥密码保护
给私钥加密码看似更安全，实则破坏可用性。Nginx 启动或重载时无法自动输入密码，会导致服务卡死、无法热更新、高可用失效。
- 不要用
openssl rsa -aes256 -in key.pem -out key.enc.pem生产加密 - 真正有效的防护是：操作系统权限 + 目录隔离 + 审计日志（如 auditd 监控私钥读取行为）
- 仅在离线测试或本地开发中可临时加密码，用于防误传、防快照泄露
持续审计与最小化暴露面
私钥安全不是一次配置，而是日常运维习惯。很多泄露源于旧文件残留、CI/CD 流水线误注入、或权限随系统升级被重置。
- 定期扫描宽松权限：
find /etc/nginx -name "*.key" -perm /037 -ls - 禁止提交私钥到 Git/SVN —— 即使是私有仓库也不行；CI 中应通过 Vault、Secrets Manager 等密钥服务注入
- 轮换证书后，立即删除旧私钥；如需归档，须加密打包并限制访问人员范围
