在本地开发和生产模式下使用版本控制系统跟踪 SSL 密钥和证书是否安全？

如您所知，带有环境变量的文件（通常具有带或不带文件名的扩展名.env）通常不会被版本控制系统跟踪，以防止数据库密码等数据泄露。SLL 密钥和证书文件怎么样？我请你分别考虑本地开发、分期和制作的情况。

关于这个话题的思考过程

本土化发展模式

如果在本地开发模式下您使用自行颁发的（例如，使用mkcert）SSL 密钥和证书，那么通常我认为没有理由将它们排除在版本控制系统的跟踪之外。它似乎不包含任何敏感数据。

强制每个团队成员自己颁发证书的唯一可能原因是 mkcert 中可能缺少强制浏览器信任已颁发证书的命令。如果确实没有这样的命令，那么每个参与者都必须自己运行该命令mkcert，这不仅会颁发密钥和证书，而且浏览器也会信任它们。在 Windows 上没有 mkcert 的情况下执行此操作并不容易（在我提出问题时我无法做到这一点）。

根据评论更新

正如@andreymal 评论的那样，

如果您将自行颁发的证书添加到受信任的浏览器中，那么泄露其私钥将允许攻击者发起中间人攻击，因此非常危险

我希望这不会成为在本地开发模式下仅使用 HTTP 协议（​​而不是 HTTPS）的理由。

生产

我不确定，但我认为生产模式的 SSL 密钥和证书是不应泄露的秘密信息。有一定的可能性，它们也可以使用浏览器开发者模式作为 CSS 或 JS 文件进行一般查看，但这又是一个假设。

与本地开发模式下每个团队成员都可以拥有自己的自行颁发的 SSL 密钥和证书不同，在生产模式下，每个人都会有一个密钥和一个证书（很可能由授权组织以可报销的方式颁发）。如果是这样，它们将不得不被排除在版本控制之外，并以其他方式在团队成员之间转移。

根据评论更新

有人提出这样的问题：如果理论上一两个生产服务器管理员知道就足够了，为什么团队成员应该了解生产 SSL？我的答案是：根据项目组装和部署的自动化的组织方式，有时在源代码文件中拥有 SLL 密钥和证书会很方便。

首先值得警惕的是，只有生产服务器的管理员才应该知道 SSL 密钥。我并不是说这是错误的，但在这种情况下，当只有一两个团队成员拥有 SSL 密钥和证书时，可能会出现问题。例如，管理员没有上班，但需要发布应用程序修补程序。或者应用程序运行所需的文件分散在团队成员中而不是组织在一起。

再说一次，我并不是说每个人都应该这样做，但我将项目收集在一个文件夹中，该文件夹中放置了应用程序在服务器上工作所需的所有内容，特别是 ssl 密钥、证书和环境变量文件：

因此，构建项目后，剩下的就是以一种或另一种方式将文件发送到 VPS 并docker compose build在 VPS 上重新启动它。

我知道有各种各样的高级部署方法，特别是 GitHub 上的 CI/CD 或各种 AWS 工具。例如，您可以使用 AWS 组织环境变量的注入，而无需使用 .env 文件 - SSL 可能有类似的东西。但所有这些都将开发商与特定的供应商联系在一起。有时这是合理的，但当最初只有一个使用裸 Ubuntu 的 VPS 时，仍然必须有某种方法来有效地组织部署。