Node.js 用于部署在多家公司的Intranet应用程序的SSL

我有一个通过https提供服务的节点应用程序。该应用程序通过互联网提供。我记得在Linux命令行上生成了SSL密钥，它们已经过期了

我渴望在多家公司安装此应用程序。它将在每家公司的intranet上运行，但我确实希望该应用程序能够远程访问（通过在公司防火墙上设置一些端口转发器）

SSL密钥是令人痛苦的。我希望对通信进行加密，但因为我自己生成SSL密钥，用户必须在开始使用应用程序之前通过一些可怕的浏览器警告

如果我希望这些警告消失，我是否必须为应用程序运行的每个intranet购买单独的SSL密钥，以防止用户看到这些警告？我可以将这些密钥的有效期设为3000年吗（这样它们就永远不会过期）？我喜欢https，但我鄙视花钱购买官方密钥。原因如下：

使用自行生成的密钥，通信的加密与购买的密钥一样安全。然而，如果用户接受我生成的证书，浏览器会让用户认为他会感染病毒。浏览器对待一切都像网上银行一样，有时你还有其他加密的理由。好了，抱怨够了

如果您有一个主要是intranet应用程序的应用程序，但确实希望允许远程访问，并且该应用程序将在许多公司安装，并且您希望该应用程序通过HTTPS运行，那么您如何减轻SSL密钥管理的负担

加密不如网上银行重要，但我想拥有它。因此，理想情况下，我想要一个我可以自己生成的密钥（以避免费用），或者我购买的一个密钥，但我希望该密钥实际上永远不会过期，并且我希望它能够为我的应用程序提供多个安装（在不同的公司）。我想要一把不在乎域名的钥匙。我想要加密通信，但验证我是我所说的那个人对我来说一点都不重要

我如何以避免浏览器警告的方式部署这样的应用程序

---

请告知。

我已经在上发布了一个答案，但我在这里看到了一些我认为值得解决的误解

我渴望在多家公司安装此应用程序。它将在每个公司的内部网上运行，但我确实希望该应用程序能够远程访问（通过在公司防火墙上设置一些端口转发器）

请注意，从安全角度来看，这实际上等同于在internet上运行应用程序。试图依靠你的应用程序被隐藏在一些非标准的端口上被称为“隐蔽的安全”，这是一种错误的安全感

如果我希望这些警告消失，我是否必须为应用程序运行的每个intranet购买单独的SSL密钥，以防止用户看到这些警告

你的申请需要一个证书，你需要访问者信任你的证书。您可以通过两种方式执行此操作：

• 从CA获取证书，这些证书是现成的受信任证书
• 制作自己的证书并分发
  • 人工
  • 通过某种集中手段实现自动化

这些选项在中有更详细的回答

我可以将这些密钥的有效期设为3000年吗（这样它们就永远不会过期）

如果你自己制作证书，你可以。但你不应该。证书背后的密码学过时了，攻击者变得更强大，机器被入侵，密钥被盗。在理论上，我们对此有撤销权，但在实践中它是。。。毛茸茸的。假设你知道有个问题。证书在一段时间后自然过期会稍微缓解这些问题。因此，持有3000年证书是非常不鼓励的

如果您从CA获得证书，则无法获得，因为出于上述原因，CA不会给您证书。证书的典型使用期限为一年。事实上，浏览器是一种长寿命的证书

我喜欢https，但我鄙视花钱购买官方密钥

然后使用免费证书。它们由几方提供

原因如下：使用自行生成的密钥，通信的加密与购买的密钥一样安全

不，不是。至少，如果浏览器抱怨，就不会

只有当证书可以信任时，通道的加密才是安全的。如果使用自签名证书，浏览器将无法信任该证书（因此会发出警告），这意味着可能会发生中间人攻击，就像普通HTTP一样。攻击者只需替换自己的证书即可；您的客户无法知道证书是伪造的

这是我们进来的时候；它们为浏览器提供了一种合理信任证书的方法

您可以通过自己分发自签名证书来避免此问题；如果操作正确，连接将非常安全。但这是更多的工作，而且伸缩性很差，这就是为什么我们在非平凡情况下使用CAs的原因

然而，如果用户接受我生成的证书，浏览器会让用户认为他会感染病毒。浏览器对待一切都像网上银行一样，有时你还有其他加密的理由。好了，抱怨够了

浏览器对此发表意见是非常正确的；盲目接受不受信任的证书会产生虚假的安全感；它几乎不比普通的HTTP好。这很少是正确的做法，而且几乎总是表明存在严重问题。吓跑用户是最好的选择

所以，理想情况下，我想要一个我可以自己生成的密钥（以避免费用），或者可能是一个我购买的密钥

你总是自己生成密钥；我想你指的是证书；）

无论如何，使用