用于在多家公司部署的 Intranet 应用程序的 SSL答案

【问题标题】：SSL For Intranet Applications Deployed at Multiple Companies用于在多家公司部署的 Intranet 应用程序的 SSL
【发布时间】：2020-09-01 06:28:05
【问题描述】：

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

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

SSL 密钥很痛苦。我希望对通信进行加密，但由于我自己生成 SSL 密钥，因此用户必须先通过一些可怕的浏览器警告，然后才能开始使用该应用程序。

如果我希望这些警告消失，我是否必须为应用运行的每个 Intranet 购买单独的 SSL 密钥以防止用户看到这些警告？我可以使这些密钥的到期时间为 3000 年（因此它们实际上永远不会过期）吗？我喜欢https，但我鄙视为官方密钥付费。原因如下：

使用自行生成的密钥，通信加密与购买的密钥一样安全。然而，如果用户接受我生成的证书，浏览器会让用户认为他会感染病毒。当有时您有其他加密原因时，浏览器会将所有内容都视为网上银行。好吧，抱怨够了。

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

加密不如网上银行重要，但我想拥有它。因此，理想情况下，我想要一个我可以自己生成的密钥（以避免费用），或者我购买 一个密钥，但我希望该密钥几乎永不过期，并且我希望它可以服务于多个我的应用程序的安装（在不同的公司）。我想要不关心域名的关键。我想要加密通信，但验证我是我所说的那个人对我来说根本不重要。

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

请指教。

【问题讨论】：

你不能以用户友好的方式做你想做的事，因为你的 SSL 客户端是一个标准的网络浏览器。即使您愿意付费，我也不知道 CA 是否可能支持 Intranet 证书，但我不是专家。
@PresidentJamesK.Polk - 我想知道是否可以通过Electron 部署应用程序而不是标准网络浏览器来避免 SSL 证书警告？问题是，这些 URL 在应用程序中实际上非常有用。它们允许人们与公司内的其他人分享他们（现在）正在查看的内容。因此，完全摆脱浏览器地址栏并不理想。
这可行，但我对电子不熟悉，所以我不确定 SSL 系统的可配置性如何。但是，一般来说，如果您编写客户端应用程序或至少可以自定义它，那么您可以决定谁的证书是可信的。
您可以简单地将根证书或 CA 证书分发到公司计算机网络。在 Windows 中，您可以使用域服务器使用组策略来执行此操作。在 Linux 中，问题有点复杂，尽管那里也有集中的证书存储，例如in Fedora。然而，这不是一个编程问题，它更多的是例如。超级用户。
我自己也有一段时间没做过了，只知道在公司里是怎么做的。我去过的网络。

标签： node.js ssl encryption https intranet

【解决方案1】：

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

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

请注意，在安全方面，这实际上与仅在 Internet 上运行应用程序相同。试图将您的应用程序隐藏在某个非标准端口上被称为“通过默默无闻的安全”，这是一种错误的安全感。

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

您的应用程序需要一个证书，并且您需要访问者信任您的证书。您可以通过两种方式做到这一点：

从 CA 获取开箱即用的受信任证书。
制作您自己的证书并分发它们
- 手动
- 通过一些集中方式实现自动化

your other question 中更详细地回答了这些选项。

我可以让这些密钥在 3000 年到期（这样它们实际上永远不会过期）吗？

如果您制作自己的证书，则可以。但你不应该。证书背后的密码学年代久远，攻击者变得更强大，机器被入侵，密钥被盗。理论上，我们对此有撤销权，实际上它是……毛茸茸的。这假设您知道存在问题。让证书在一段时间后自然过期可以稍微缓解这些问题。因此，强烈建议不要持有 3000 年的证书。

如果您从 CA 获得证书，则不能，因为他们不会给您证书，原因如上所述。证书的典型有效期为一年。事实上，浏览器是moving 到block 的长寿命证书。

我喜欢https，但我讨厌花钱买官方密钥。

然后使用免费证书。它们由多方提供。 I like Let's Encrypt.

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

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

只有在证书可以信任的情况下，通道的加密才是安全的。如果您使用自签名证书，浏览器将无法信任该证书（因此会出现警告），这意味着中间人攻击可能与普通 HTTP 一样。攻击者可以简单地替换他们自己的证书；您的客户无法知道证书已被伪造。

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

您可以通过自己分发自签名证书来避免此问题；如果您正确执行此操作，则连接将非常安全。但这需要更多的工作，而且扩展性很差，这就是为什么我们在重要的情况下使用 CA。

然而，如果用户接受我生成的证书，浏览器会让用户认为他会感染病毒。当有时您有其他加密原因时，浏览器会将所有内容都视为网上银行。好吧，抱怨够了。

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

因此，理想情况下，我想要一把我可以自己生成的钥匙（以避免费用），或者我购买一把钥匙

您总是自己生成密钥；我认为您的意思是证书；）

无论如何，使用 CA。有免费的。

但我希望该密钥几乎永不过期

不会发生的。

并且我希望它为我的应用程序提供多个安装（在不同公司）。

坏主意；您希望尽可能地将您的客户与其他客户的妥协隔离开来，尤其是在您要分发自己的证书时。

我想要不关心域名的关键。

同上。

我想要加密通信，但验证我是我所说的那个人对我来说根本不重要。

验证是加密通信的组成部分；这不是可选的。

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

your other question 已回答。

【讨论】：

所有这些繁文缛节都是我在客户端应用程序中使用浏览器造成的。如果我通过桌面应用程序提供我的客户端应用程序，我可以加密客户端和服务器之间的数据传输，而无需忍受任何重复的证书管理。一个几乎永不过期的自签名 SSL 证书将服务于所有公司的所有安装，并且最终用户不会受到任何警告的困扰。您明智地指出的漏洞对我来说是完全可以接受的。中间的人会对我传输的数据感到非常失望。
不过，我很感激你指出的一切。我只是想弄清楚如何自动化管理负担，以便在部署软件更新时所有安装都始终具有未过期的官方证书。这不好玩。
我喜欢编写程序（在我安装它们之后），它们可以无限期地工作，而不需要太多的维护或维护。我的代码的每个其他方面都是这样，但是您的建议，关于证书在一年后到期，将需要每年对我的应用程序的每一次安装（在每家公司）进行维护。我希望我能找到一种方法来自动化这个可怕的负担。我想避免因证书过期而导致的任何停机或混乱。
这是另一个idea，我正在玩弄。